> 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. >
Sure, but aren't you going to have that with any password-authenticated protocol? --Richard > 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
