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.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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
