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

[[e-mail] (Martin Rex)]

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.


-Martin