Re: [TLS] FFDHE and SHOULDs on usage

[Daniel Kahn Gillmor <[e-mail]>]

On Wed 2015-04-15 15:05:26 -0400, Martin Thomson wrote:
> On 15 April 2015 at 11:22, Daniel Kahn Gillmor <[e-mail]> wrote:
>> -      <t>A client that offers any of these values in the elliptic_curves
>> -      extension SHOULD ALSO include at least one FFDHE ciphersuite in
>> -      the Client Hello.</t>
>> +      <t>A client that offers a "Supported Groups" extension
>> +      containing an FFDHE group should also include at least one FFDHE
>> +      ciphersuite in the Client Hello.</t>
>
> I apologize for not completing the

:)

> It's been a while, so I went back and re-read this little bit,
> prompted largely by your choice to move to a lowercase should:
>
>    The compatible client that wants to be able to negotiate strong FFDHE
>    SHOULD send a "Supported Groups" extension (identified by type
>    elliptic_curves(10) in [RFC4492]) in the ClientHello, and include a
>    list of known FFDHE groups in the extension data, ordered from most
>    preferred to least preferred.  If the client also supports and wants
>    to offer ECDHE key exchange, it MUST use a single "Supported Groups"
>    extension to include all supported groups (both ECDHE and FFDHE
>    groups).  The ordering SHOULD be based on client preference, but see
>    Section 6.1 for more nuance.
>
>    A client that offers any of these values in the elliptic_curves
>    extension SHOULD ALSO include at least one FFDHE ciphersuite in the
>    Client Hello.
>
> This is a little over-2119-y for me.  How about:
>
> """
> A client that wants to negotiatiate strong FFDHE sends a ClientHello
> containing a cipher suite that uses DHE key exchange and a "Supported
> Groups" extension (identified by ...).  The "Supported Groups"
> extension contains the FFDHE groups the client will accept.  If the
> client also intends to accept ECDHE key exchange, the same "Supported
> Groups" extension is used for both FFDHE and ECDHE groups.
>
> Groups are ordered based on client preference, noting the additional
> ordering considerations in Section 6.1.
> """

I'm willing to drop the 2119 language in this section if other people
think that it is inappropriate.  Some of it seems relevant for interop
to me (e.g. 'MUST use a single "Supported Groups" extension' just echoes
5246's restriction 'There MUST NOT be more than one extension of the
same type.')

What do others think here?

Also, this rewrite says "ordered based on client preferences" but
doesn't indicate which order based on client preferences: most preferred
to least preferred or the other way around.  It may be pedantic, but
this is exactly the sort of pedantry that RFCs should include.

     --dkg