Oh, sure. In a similar vein, an attacker can also probe for which identities are known to the server.
https://github.com/bifurcation/tls-pake/commit/0e72bd5244e89970fe61e5434ca7df3d769d057c On Mon, Apr 16, 2018 at 3:06 PM, Jonathan Hoyland < jonathan.hoyl...@gmail.com> wrote: > 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
