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

Hey Jonathan,

Thanks for the comments.  I've implemented them in my working copy of the
draft, and in my implementation in mint.  I have also changed it over to
use SPAKE2+; I agree with Tony that this is necessary to guard against
server compromise.

https://github.com/bifurcation/tls-pake/commit/a9f097c3bfe43cf50001e1a340c7e2e693850d4b
https://github.com/bifurcation/mint/pull/193

With regard to security properties: I don't think it's correct that an
active attacker can do online password guessing.  Everything that is
revealed on the wire is blinded with fresh, per-connection entropy, and
thus doesn't reveal anything about the password.

--Richard

On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
jonathan.hoyland@gmail.com> wrote:

> Hi Richard,
>
> A few nits.
>
> * In the introduction you have the sentence
> > DISCLAIMER: This is a work-in-progress draft of MLS and has not yet
>
>    seen significant security analysis.
>
> Iiuc this draft has no connection to MLS, and this is a typo.
>
>  * In the setup you define
>
> > o  A DH group "G" of order "p*h", with "p" a large prime
>
> and
>
> > o  A password "p"
>
>
> The variable "p" has two different meanings, which is a bit confusing,
> especially later on.
>
>  * The document doesn't explicitly state that X and Y need to be non-zero.
>
> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the
> warning was carried through.
>
> * In terms of security properties, iiuc an active adversary can do online
> password guessing attacks, but a passive adversary cannot derive the
> password from observing the messages. If that is the case perhaps a warning
> about rate-limiting connection attempts is appropriate.
>
> Regards,
>
> Jonathan
>
> On Mon, 16 Apr 2018 at 10:50 Tony Putman <Tony.Putman@dyson.com> wrote:
>
>> Hi Richard,
>>
>> I don't think that you can protect against server compromise with SPAKE2.
>> The server can store w*N as you suggest, but it also has to store w*M
>> because it must calculate y*(T-w*M). An attacker that learns w*M and w*N
>> from a compromised server can then impersonate a client.
>>
>> The rest of your comments I agree with (though they are not all addressed
>> in the updated draft).
>>
>> Tony
>>
>> > From: Richard Barnes [mailto:rlb@ipv.sx]
>> > Sent: 13 April 2018 19:50
>> >
>> > Hey Tony,
>> >
>> > Thanks for the comments.  Hopefully we can adapt this document to tick
>> more boxes for you :)
>> > Since I had noticed some other errors in the document (e.g., figures
>> not rendering properly),
>> > I went ahead and submitted a new version that takes these comments into
>> account.
>> >
>> > https://tools.ietf.org/html/draft-barnes-tls-pake-01
>> >
>> > Some responses inline below.
>>
>> Dyson Technology Limited, company number 01959090, Tetbury Hill,
>> Malmesbury, SN16 0RP, UK.
>> This message is intended solely for the addressee and may contain
>> confidential information. If you have received this message in error,
>> please immediately and permanently delete it, and do not use, copy or
>> disclose the information contained in this message or in any attachment.
>> Dyson may monitor email traffic data and content for security & training.
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>