Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

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.hoyland@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 <rlb@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 <rlb@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.hoyland@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.Putman@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:rlb@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
>>>>>>
>>>>>
>>>>