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

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