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

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
>>>>>
>>>>
>>>