Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

[Rob Stradling <[e-mail]>]

On 22/01/14 23:44, Manuel Pégourié-Gonnard wrote:
> On 22/01/2014 19:07, Rob Stradling wrote:
>> Simon, Section 2.1 says:
>>     "Since Curve25519 are not designed to be used in signatures, clients
>>      who offer ECDHE_ECDSA ciphersuites and advertise support for
>>      Curve25519 in the elliptic_curves ClientHello extension SHOULD also
>>      advertise support for at least one other curve, suitable for ECDSA.
>>      Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common
>>      curve is Curve25519."
>>
>> Why is that "SHOULD" not a MUST?
>>
> The idea is that, if a client offers ECDHE_ECDSA ciphersuites but no
> ECDSA-capable curve, the handshake can still be completed if non-ECDSA
> ciphersuites are offered too: the server will select one of these suites. In
> this case, offering ECDHE_ECDSA suite is just a waste of bytes, but does not
> harm interoperability.
>
> Making it a SHOULD may simplify client-side implementations in which the user
> can select the list of supported curves and ciphersuites, by allowing the
> implementation not to filter the list of ciphersuites based on the selected curves.
>
> Manuel.

OK, that makes sense.

BTW, since other NamedCurves may be defined in the future that "are not 
designed to be used in signatures", how about changing...

   "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if the only common
    curve is Curve25519."

...to...

   "Servers MUST NOT select an ECDHE_ECDSA ciphersuite if there are no
    common curves suitable for ECDSA."

?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online