Hi Richard, That's correct, however if I have a guess of the password can I not just try and connect using that password? If my guess is correct then the connection will succeed, whereas if my guess is incorrect then the connection will fail. I'm assuming here that the salt is public, because salts in general do not have confidentiality guarantees (otherwise they stretch the metaphor and become pepper). (I also assume that the client identity can be derived from observing a previous session, and that the server identity can be identified through probing.)
Regards, Jonathan On Mon, 16 Apr 2018 at 19:43 Richard Barnes <r...@ipv.sx> wrote: > 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
