Re: [Cfrg] Adoption call for draft-harkins-pkex-05
Dan Brown <danibrown@blackberry.com> Wed, 11 April 2018 15:25 UTC
Return-Path: <danibrown@blackberry.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A937312702E for <cfrg@ietfa.amsl.com>; Wed, 11 Apr 2018 08:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYKavT-BgsnN for <cfrg@ietfa.amsl.com>; Wed, 11 Apr 2018 08:25:24 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B20127010 for <cfrg@irtf.org>; Wed, 11 Apr 2018 08:25:24 -0700 (PDT)
X-Spoof:
Received: from xct104cnc.rim.net ([10.65.161.204]) by mhs215cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Apr 2018 11:25:22 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Wed, 11 Apr 2018 11:25:22 -0400
From: Dan Brown <danibrown@blackberry.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] Adoption call for draft-harkins-pkex-05
Thread-Index: AQHTzy6h+ZIAj7eEGk6ocsI5c3vFGqP6SGhggAAslsCAAS8pEA==
Date: Wed, 11 Apr 2018 15:25:22 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501C51B18@XMB116CNC.rim.net>
References: <5ACA0006.4020809@isode.com> <810C31990B57ED40B2062BA10D43FBF501C515B8@XMB116CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF501C5168A@XMB116CNC.rim.net>
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501C5168A@XMB116CNC.rim.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.251]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_00CD_01D3D187.C70BB620"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/rLE1W_WuKoADpxDgoDw9r5lLtS4>
Subject: Re: [Cfrg] Adoption call for draft-harkins-pkex-05
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Apr 2018 15:25:28 -0000
A 4th issue/question, not really about terminology, but more definitional, also a bit uncertain (I'm tiring out on this one): The authentication phase of PKEX is basically just SPAKE2, and goes from a weak password to a strong symmetric key z. I'm still fine with this phase, modulo (1) subtle differences in PAKEs that I do not yet understand and (2) questions whether passwords are properly in scope of IETF, since they don't scale well globally, etc. The reveal phase does not seem to add obvious value. It seems to be almost the opposite of static Diffie-Hellman. We can switch back and forth between a secret symmetric key z and authenticated asymmetric keys A,B. What can Alice and Bob with A and B that they could not already do with z. Authenticate messages? They can use HMAC with z - instead of (repudiable) signatures or OTR with A and B. Send each other secret messages? They can use AES, etc, with z, - instead of ECIES with A or B? Generate yet more symmetric keys? They can use KDFs, PRFs, wrapped keys, etc., - instead of Diffie-Hellman or MQV. If some IETF protocols use public keys but lack any means for Alice and Bob to leverage their pre-shared secret (password, etc.), then I guess could PKEX retro-fit or shoe-horn it in. But then one could also, maybe just as modularly, run a tunnel based on SPAKE2 and z inside (or outside) such an inflexible IETF protocol to get the same effect. For example, an online bank could run a CA-authenticated TLS tunnel, and then run, at a higher layer, a SPAKE2-protected connection inside the TLS tunnel, etc. Please note, although I am deliberately trying to be extra-critical here, I am also trying not to be contrarian. -----Original Message----- From: Dan Brown Sent: Tuesday, April 10, 2018 4:47 PM To: Dan Brown <danibrown@blackberry.com>; Alexey Melnikov <alexey.melnikov@isode.com>; cfrg@irtf.org Subject: RE: [Cfrg] Adoption call for draft-harkins-pkex-05 A third very minor issue (again terminology, and arguably more pedantic): 3. The PKEX I-D uses the word "trust" often. It seems to me that is not an equivalent in strength trust to a more conventional public-key certificate (or a distributed web of trust either). I think this needs clarification in the draft. I expand on the difference below, in two closely related sub-issues. 3a. First, if Bob lost his secret password, or has a bad RNG, then Eve may be able to impersonate Alice to Bob, even if Alice system's is entirely uncompromised. In regular authenticated key exchange, this type of attack is called key-compromise impersonation (KCI). I guess KCI applies to every PAKE, which is fair enough. But PKEX has farther aims than a just PAKE, kind of a sub-PKI. (Is PKEX a play on PKIX?) But in a PKI, relying parties can "trust" public keys, such as code signing keys, without having any secrets at all to guard. So, in some sense there is lesser degree of trust provided by a PKI. 3b. Second, and this issue is an extension of the first (not independent of it), I would argue that part of "trust" in a public key includes an ability to trust its use in non-repudiable signed transaction. Because of the KCI threat, Alice could do PKEX with Bob, sign a message with her key A, then try to repudiate. Bob will not be able to prove to anybody A is Alice's key, because he could have generated A himself, as if Bob did a KCI attack on himself. So, Bob will not be able to trust Alice as much as usual in a PKI. At the moment I don't have a concrete suggestion to correct this terminology. Also, I forget if PKI spec use the word "trust" or something else. -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Dan Brown Sent: Tuesday, April 10, 2018 2:00 PM To: Alexey Melnikov <alexey.melnikov@isode.com>; cfrg@irtf.org Subject: Re: [Cfrg] Adoption call for draft-harkins-pkex-05 I'm seeing two minor issues to be resolved before adoption: 1. "Public key exchange" is a totally non-specific name, so much so, that I oppose adoption under this name. Public key exchange could mean Diffie-Hellman key agreement, for example. If PKEX has been deployed in some places, the name should be updated retroactively. (Sorry that this is merely a terminology issue (as in the color of bikeshed, not the bikeshed itself.) 2. What is the problem being solved here? For example, I think that TLS will or does offer PSK authentication. So, why not just do an out-of-band PAKE to establish a PSK, then use PSK-authenticated TLS. So, to rephrase my question: is there some security defect with PSK-authenticated TLS that PKEX solves? Maybe this was discussed already, sorry if I missed it (and am out of order). Otherwise, I do not have much of an opinion in either direction. -----Original Message----- From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of Alexey Melnikov Sent: Sunday, April 8, 2018 7:42 AM To: cfrg@irtf.org Subject: [Cfrg] Adoption call for draft-harkins-pkex-05 Dear CFRG participants, This message is starting a 2 weeks adoption call for draft-harkins-pkex-05 (Public Key Exchange). From the document's Introduction: [RFC7250] further states that "the main security challenge [to using 'raw' public keys] is how to associate the public key with a specific entity. Without a secure binding between identifier and key, the protocol will be vulnerable to man-in-the- middle attacks." The Public Key Exchange (PKEX) is designed to fill that gap: it establishes a secure binding between exchanged public keys and identifiers, it provides proof-of-possession of the exchanged public keys to each peer, and it enables the establishment of trust in public keys that can subsequently be used to facilitate authentication in other authentication and key exchange protocols. At the end of a successful run of PKEX the two peers will have trust in each others exchanged public keys and also share an authenticated symmetric key which may be discarded or used for another purpose. The adoption call will last for 2 weeks and will end on April 22nd. Thank you, Kenny and Alexey _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg
- [Cfrg] Adoption call for draft-harkins-pkex-05 Alexey Melnikov
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Greg Rose
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Stanislav V. Smyshlyaev
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Brown
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Greg Rose
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Brown
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Benjamin Kaduk
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Brown
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Harkins
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Harkins
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Richard Barnes
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Harkins
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Richard Barnes
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Harkins
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Richard Barnes
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Richard Barnes
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Dan Harkins
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Richard Barnes
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Martin Thomson
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Eric Rescorla
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Daniel Harkins
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Christopher Wood
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Eric Rescorla
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Salz, Rich
- Re: [Cfrg] Adoption call for draft-harkins-pkex-05 Greg Rose