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.


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.


On Mon, Apr 16, 2018 at 7:52 AM, Jonathan Hoyland <
jonathan.hoyl...@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.put...@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:r...@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
TLS mailing list

Reply via email to