Re: [Cfrg] Adoption call for draft-harkins-pkex-05

Dan Brown <danibrown@blackberry.com> Tue, 10 April 2018 18:00 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 223C312DA3E for <cfrg@ietfa.amsl.com>; Tue, 10 Apr 2018 11:00:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 l8RSteDi9z-h for <cfrg@ietfa.amsl.com>; Tue, 10 Apr 2018 10:59:58 -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 BD0B412DA29 for <cfrg@irtf.org>; Tue, 10 Apr 2018 10:59:57 -0700 (PDT)
X-Spoof:
Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Apr 2018 13:59:46 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0319.002; Tue, 10 Apr 2018 13:59:45 -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+ZIAj7eEGk6ocsI5c3vFGqP6SGhg
Date: Tue, 10 Apr 2018 17:59:45 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF501C515B8@XMB116CNC.rim.net>
References: <5ACA0006.4020809@isode.com>
In-Reply-To: <5ACA0006.4020809@isode.com>
Accept-Language: en-US, en-CA
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_008E_01D3D0D4.2DC97D20"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/AqTZaF3mzYjmz6yX0o7v1JeXMak>
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: Tue, 10 Apr 2018 18:00:00 -0000

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