Unfortunately, I haven’t had time to review the document, but +1 for interesting problem, and +1 for anything Richard writes as a good starting point, even if I haven’t read it.
-Tim From: TLS <tls-boun...@ietf.org> On Behalf Of Hugo Krawczyk Sent: Wednesday, July 18, 2018 7:13 PM To: Richard Barnes <r...@ipv.sx> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt +1 for this work. If you are one of those that think, as I did 20 years ago, that password authentication is dying and practical replacements are just around the corner, do not support this document. Otherwise, please do. Asymmetric or augmented PAKE (aPAKE) protocols provide secure password authentication in the common client-server case (where the server stores a one-way mapping of the password) without relying on PKI - except during user/password registration. Passwords remain secure regardless of which middleboxes or endpoints spy into your decrypted TLS streams. The server never sees the password, not even during password registration. To see real deployment of such protocols, they need to be integrated with TLS which is what Barnes's draft facilitates. Not only this improve significantly the protection of passwords and password authentication, but aPAKE protocols also provide an hedge against PKI failures by enabling mutual client-server authentication without relying on regular server certificates. Hugo On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes <r...@ipv.sx <mailto:r...@ipv.sx> > wrote: Hey TLS WG, In response to some of the list discussion since the last IETF, Owen and I revised our TLS PAKE draft. In the current version, instead of binding to a single PAKE (SPAKE2+), it defines a general container that can carry messages for any PAKE that has the right shape. And we think that "right shape" covers several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, .... The chairs have graciously allotted us 5min on the agenda for Thursday, where I'd like to ask for the WG to adopt the document. So please speak up if you think this is an interesting problem for the TLS WG to work on, and if you think the approach in this document is a good starting point. Happy for comments here or at the microphone on Thursday! Thanks, --Richard ---------- Forwarded message --------- From: <internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> > Date: Mon, Jul 16, 2018 at 3:25 PM Subject: New Version Notification for draft-barnes-tls-pake-04.txt To: Richard Barnes <r...@ipv.sx <mailto:r...@ipv.sx> >, Owen Friel <ofr...@cisco.com <mailto:ofr...@cisco.com> > A new version of I-D, draft-barnes-tls-pake-04.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 04 Title: Usage of PAKE with TLS 1.3 Document date: 2018-07-16 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04 Abstract: The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> . The IETF Secretariat _______________________________________________ TLS mailing list TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
