Re: [TLS] (draft) WG adoption call: draft-bmoeller-tls-falsestart

[Brian Smith <[e-mail]>]

Martin Thomson <[e-mail]> wrote:
> On 31 March 2015 at 19:33, Brian Smith <[e-mail]> wrote:
>>
>> 4. The references to (FF-)DHE key exchange being acceptable for False
>> Start are removed. Although it may be possible to safely implement
>> False start for FF-DHE, the current draft isn't a good starting point
>> for specifying how that might be done. It's better to remove the
>> references until an adequate description of doing False Start for
>> FF-DHE key exchange is available, if ever.
>
> I agree with most of what Brian says, particularly with respect to
> only accepting the "best" profile of TLS here.  However, I am
> generally leery of making specific recommendations regarding cipher
> suite choice.  With the explicit groups, this might be OK.  Without
> explicit groups, I think that Brian's point is completely valid.

Implementing the negotiated FF-DHE mechanism as specified definitely
isn't sufficient and may not be necessary for doing False Start with
FF-DHE cipher suites:

1 The negotiated FF-DHE spec still allows the client to use FF-DHE
parameters that it didn't send, in order to interop with
implementations, as long as it has some "policy" for handling that
case. For False Start, such a policy would have to be defined.

2. As I noted in the Firefox bug, even if the client only does False
Start with parameters it advertised in its FF-DHE extension, there is
still potential for material downgrade if the weakest FF-DHE
parameters it advertises are weaker than the ECDHE curves it supports.

3. Even if the client doesn't implement ECDHE at all, the weakest
FF-DHE key it offers during FF-DHE parameter negotiation may not be
strong enough to do False Start. Given the research I did for Firefox
that showed that any reasonably definition of "strong enough" is
practically equivalent to disabling False Start for FF-DHE, it seems
not to be worthwhile to bother trying to define "strong enough."

Cheers,
Brian