You are, but it's not mentioned in the security section. As it's a security consideration that you don't get in vanilla TLS I feel that it should be mentioned.
Regards, Jonathan On Mon, 16 Apr 2018 at 20:01 Richard Barnes <r...@ipv.sx> wrote: > 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
