Re: [TLS] AD review of draft-ietf-tls-negotiated-ff-dhe-08

[Stephen Farrell <[e-mail]>]

On 02/04/15 03:05, Martin Rex wrote:
> Stephen Farrell wrote:
>> Martin Rex wrote:
>>>
>>> I think Stephen might have meant something else.
>>>
>>> RFC4492 contains the following explicit prohibition (Section 4, 4th paragr.):
>>>
>>>    https://tools.ietf.org/html/rfc4492#section-4
>>>
>>>
>>>    The client MUST NOT include these extensions in the ClientHello
>>>    message if it does not propose any ECC cipher suites. 
>>
>> Ooh - good catch, I hadn't spotted that. This draft is updating 4492
>> though so we can validly change that, but if we're doing so (and I
>> guess we are) then it'd be better to be very explicit about it, e.g.
>> by adding a sentence saying that we're changing that specific MUST NOT.
> 
> I believe that this is *NOT* an option here (more below).
> 
> 
>>
>>> and the above requirement seems to prohibit a non-ECC client from
>>> using the named FFDHE parameters through the ECC named curve extension
>>> _without_ accompanying ECC cipher suites.
>>
>> Right. That's the kind of thing I was wondering about.
>>
>> I'll happily accept the wg's word on this, but to what extent have
>> we checked that we're not breaking something with this change in
>> semantics. (It's a small, but real, change.)
> 
> 
> The problem with the quoted requirement in rfc4492 is (similar to several
> highly bogus and/or overbroad requirements in other TLS-related RFCs),
> that it does not distinguish PDU content from communication peer behaviour,
> and does not declare whether that requirement applies only to sender
> or also to recipient.
> 
> 
> The result is, that there may easily exist server implementation of rfc4492
> which abort the TLS handshake when they receive a TLS ClientHello with
> the TLS ECC named_curve extension (and only ffdhe named curves in it)
> but no accompanying ECC cipher suites in the ClientHello cipher_suites_list,
> and that interoperability failure OUGHT to be avoided.  REALLY.

Right, it is a possible interop break. It seems the browser folks
are confident it won't bite them (did they test yet without any ECC
ciphersuites?) but that (so far) we've not heard from others. I'd like
to hear more myself, but this is something the WG could choose to do
and, if done carefully, that can be fine. OTOH, it could also be a
mistake, if not done sufficiently carefully, which is why I'm asking
about it. (Right now, I think I need more input still, but it could
also be that that's already in the list archive, I'm not sure.)

Cheers,
S.


> 
> 
> -Martin
>