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