Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt

[Yaron Sheffer <[e-mail]>]

I strongly support this work.

Also, having made this mistake myself in the past: please make sure that 
we have one fully specified PAKE in this document, and not only a 
generic envelope. This will ensure that TLS libraries have at least one 
working, and interoperable, PAKE,

Thanks,
	Yaron

On 19/07/18 10:10, Tim Hollebeek wrote:
> 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 <[e-mail]> *On Behalf Of *Hugo Krawczyk
> *Sent:* Wednesday, July 18, 2018 7:13 PM
> *To:* Richard Barnes <[e-mail]>
> *Cc:* <[e-mail]> <[e-mail]>
> *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 <[e-mail] 
> <mailto:[e-mail]>> 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: <[e-mail] <mailto:[e-mail]>>
>     Date: Mon, Jul 16, 2018 at 3:25 PM
>     Subject: New Version Notification for draft-barnes-tls-pake-04.txt
>     To: Richard Barnes <[e-mail] <mailto:[e-mail]>>, Owen Friel
>     <[e-mail] <mailto:[e-mail]>>
> 
> 
> 
> 
>     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
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>