Also, it isn't too difficult to implement a PAKE. But there isn't a
(known?) way to do it without adding rounds, if you want to protect the
username. This is because the server needs the username before it can
do anything with the password. Unless it has 0-RTT information the
client can't encrypt the username before receiving the server's
ephemeral share. So you need at least
ClientHello ->
<- ServerKeyshare
PakeStuff ->
<- PasswordVerify
PasswordVerify, Finished ->
(With other messages in there too of course, but these ones limit the
round count with PAKE.)
-- Mike
On 7/19/2015 3:42 AM, Thijs van Dijk wrote:
Hi Manuel,
On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard <m...@elzevir.fr
<mailto:m...@elzevir.fr>> wrote:
I'm probably wrong since I only thought about it for a few
minutes, but it seems to me that the PasswordVerify message would
be encrypted with (keys derived from) the handshake master secret,
which would prevent offline attacks.
What am I missing?
The key observation is the following: (I mentioned this off-list a few
weeks ago, but I guess I'll post it here as well for posterity.)
[T]he master secret will be derived from the client's and server's
respective KeyShare messages, and will therefore be known at the
time the server's PasswordVerify is sent. A malicious client could
therefore perform half a handshake (just enough to get the server
to give up its PV message), abort, and proceed with an offline
attack in its own time.
I thought about switching the order in which server and client
send their PV, but in much the same manner this won't protect
clients from malicious servers.
-Thijs
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
