Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt

[Watson Ladd <[e-mail]>]

On Fri, Mar 28, 2014 at 8:07 PM, Dan Harkins <[e-mail]> wrote:
>
> On Fri, March 28, 2014 4:35 pm, Watson Ladd wrote:
>> On Fri, Mar 28, 2014 at 6:55 PM, Dan Harkins <[e-mail]> wrote:
>>>
>>> On Fri, March 28, 2014 2:49 pm, Watson Ladd wrote:
>>>> On Fri, Mar 28, 2014 at 3:53 PM,  <[e-mail]> wrote:
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>> directories.
>>>>>  This draft is a work item of the Transport Layer Security Working
>>>>> Group
>>>>> of the IETF.
>>>>>
>>>>>         Title           : Secure Password Ciphersuites for Transport
>>>>> Layer Security (TLS)
>>>>>         Authors         : Dan Harkins
>>>>>                           Dave Halasz
>>>>>         Filename        : draft-ietf-tls-pwd-04.txt
>>>>>         Pages           : 35
>>>>>         Date            : 2014-03-28
>>>>
>>>> Why should we trust this PAKE? I've got only partial results in this
>>>> direction, but they are not sufficient for me to adopt it when better
>>>> validated alternatives exist like those based on distrustful MPC.
>>>
>>>   I'm not sure what you mean by "we" but it got quite a bit of review
>>> in CFRG and that resulted in fixing the only real technical issue
>>> brought
>>> up: potential for a side-channel attack. Scott Fluhrer came up with a
>>> way to do a random blinding of a value when checking whether its a
>>> quadratic residue that effectively addresses that concern.
>>
>> "We didn't break it in the four months we've looked at it" is not a
>> good enough reason.
>> Given that the experts you have consulted have expressed doubts about
>> ever determining its security, I'm inclined to be rather more
>> suspicious of it.
>
>   It's been more like 2 years, but nevertheless, your complaint is a
> lack of formal security proof. But that has never been a requirement
> for a draft in a WG in the Security Area, or any area for that matter,
> of the IETF.

So because I didn't complain when the Security Area was founded, I
don't get to complain now?
This takes estoppel to a bizarre extreme.

>
>> During the last half of those two months I was trying to show it would
>> work. The best I can do is reduce it to the two person case, but I
>> can't get it to anything computational.
>
>   What a drag, I was hoping you'd come up with something.
>
>>>   These ciphersuites are drop-in replacements for things like PSK
>>> ciphersuites, not for popular ones used in browsers. In fact, I agree
>>> with several on this list who are pointing out that using a PAKE in a
>>> browser is not a good idea.
>>
>> Why is a multi-party computation ala Socialist Millionaire's protocol
>> in OTR not feasible? That establishes a secure channel based on a
>> password shared on both ends in a way that is provably secure.
>> Aug-PAKE can easily be made to work symmetrically: why can't you use
>> that?
>
>   There is no draft specifying a multi-party computation ala the
> Socialist Millionaire's protocol in TLS, much less one that is as
> mature as TLS-pwd. Aug-PAKE doesn't work in TLS, as shown
> by draft-shin-tls-augpake-- what's conveyed in the ClientKeyExchange
> structure since the client's contribution has been overloaded into
> the ClientHello? Basically, the client must initiate in Aug-PAKE and
> that forces a square peg into a round hole, or introduces extra
> rounds.

Write one. It's your problem, not mine.

As for AugPAKE, that might be ugly, but it works. I'm not seeing a
barrier to implementation here. Furthermore, we could reverse the
roles of client and server if we wanted a symmetric version in which
the client talks first.

>
>   We have gone over this before, but it takes years to get a draft
> in the state necessary to become an RFC. You said it took more
> like 30 minutes, but I'm sure you'd like to reevaluate that after
> your experience with the CFRG I-D you have been writing. In
> any event, the only draft _right now_ that satisfies the requirements
> is TLS-pwd.

The concerns I have with Dragonfly cannot be fixed by fiddling with
verbiage. They are fundamental problems with the protocol presented
compared to the state of the art.

>
>> There are standard models for PAKE security. Does Dragonfly work in
>> them? It clearly requires the ROM: is that enough?
>>
>> You're asking this WG to approve adding a new cryptographic protocol
>> to TLS with dubious justifications, in fact nonexistent, of security,
>> when a well-studied body of knowledge on this problem exists. There is
>> a compelling case for a PAKE: there is not a compelling case for
>> Dragonfly.
>
>   The same WG that approved of RFC 4279, a Standards Track RFC that
> did not have a proof in the ROM because it has no security. Yes, that same
> WG. I'm proposing a set of robust and misuse-resistant replacements for
> the RFC 4279 ciphersuites.

PSK has no security? That's ridiculous: if high-entropy keys are used
it is fairly easy to see it is secure.

Dragonfly's "robustness" and "misuse-resistence" are nothing but
rhetoric, absent some reason to believe it actually has these
properties.

Sincerely,
Watson Ladd

>
>   regards,
>
>   Dan.
>
>> Sincerely,
>> Watson Ladd
>>>
>>>   If you're happy doing cert-based TLS, or happy with HTTP Digest
>>> authentication (or whatever) then these are not for you. But the
>>> entirety
>>> of networking  is not "the web" and these ciphersuites work well with
>>> some specific use cases (see the draft).
>>>
>>>   regards,
>>>
>>>   Dan.
>>>
>>>
>>
>>
>>
>> --
>> "Those who would give up Essential Liberty to purchase a little
>> Temporary Safety deserve neither  Liberty nor Safety."
>> -- Benjamin Franklin
>>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin