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

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Jul 2018 13:18:33 -0400

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: <[email-masked]>
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes <[email-masked]>, Owen Friel <[email-masked]>

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.

The IETF Secretariat

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 18 Jul 2018 19:12:53 -0400

+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 <[email-masked]> wrote:

> URL:            https://www.ietf.org/internet-
> drafts/draft-barnes-tls-pake-04.txt
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Tim Hollebeek <[email-masked]>
Date: Thu, 19 Jul 2018 14:10:08 +0000

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 <[email-masked]> On Behalf Of Hugo Krawczyk
Sent: Wednesday, July 18, 2018 7:13 PM
To: Richard Barnes <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
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 <[email-masked] <mailto:[email-masked]> > 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: <[email-masked] <mailto:[email-masked]> >
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Barnes <[email-masked] <mailto:[email-masked]> >, Owen Friel <[email-masked] <mailto:[email-masked]> >

URL:            https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt

Abstract:

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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/tls

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 19 Jul 2018 22:55:48 -0400

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 <[email-masked]> *On Behalf Of *Hugo Krawczyk
> *Sent:* Wednesday, July 18, 2018 7:13 PM
> *To:* Richard Barnes <[email-masked]>
> *Cc:* <[email-masked]> <[email-masked]>
> *Subject:* Re: [TLS] Fwd: New Version Notification for 
> draft-barnes-tls-pake-04.txt
> 
> +1 for this work.
> 
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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
> 
>     From: <[email-masked] <mailto:[email-masked]>>
>     To: Richard Barnes <[email-masked] <mailto:[email-masked]>>, Owen Friel
>     <[email-masked] <mailto:[email-masked]>>
> 
> 
> 
> 
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://tools.ietf.org>.
> 
>     The IETF Secretariat
> 
>