Re: [TLS] Remove signature algorithms from cipher suites in 1.3

[Antoine Delignat-Lavaud <[e-mail]>]

Le 12/23/2014 7:07 AM, Brian Smith a écrit :
> How would your proposal change if signature-less authentication
> mechanisms were added (later)? How would we indicate support for the
> signature-less authentication?

Such schemes would either require an extension or a custom cipher suite 
because of their different state machine.

>
>> In this design, keeping the legacy of including the signature algorithm to
>> be used in the ServerCertificateVerify message within the selected cipher
>> suite name can be a burden to the modularity and extensibility of the
>> protocol, since adding support for new signature algorithms comes at the
>> cost of an exponential increase in the length of the list of cipher suites
>> sent by the client, even though the security guarantees of the handshake are
>> now fully modular w.r.t authentication goals achieved by certificate and
>> signatures.
> In theory, that sounds like a problem. Is it really a problem in
> practice, if we're not concerned about the specific case of RSA-PSS? On the other hand, nobody has ever seemed to want TLS_DHE_ECDSA_* cipher suites, so it doesn't seem like it caused any problem.

Right now, it isn't a problem in practice, but it is not clear either 
that DSA (maybe in danger of being removed?), ECDSA and PKCS#1v1.5 are a 
good set of signature algorithms to commit to for the long run. Even in 
the short term, a MAC-based signature scheme may be useful for PSK and 
resumption.

>
>> - For compatibility with previous protocol versions, existing cipher suite
>> names are preserved; however, servers MUST NOT select any cipher suite that
>> includes a signature algorithm other than RSA in a 1.3 handshake;
> What is the practical advantage of having this restriction? I would be
> concerned that there might be an interoperability loss if servers
> choose TLS_ECDHE_RSA_* but use an ECDSA certificate. It would be good
> to see some measurement of the effects of doing that, but it is
> difficult to do such measurement. I think there should be a clear
> benefit to the restriction in order to justify the effort to measure
> if it would work.

An alternative would be to allow any pre-1.3 cipher suite to be used, 
while allowing the signature algorithm used to authenticate the server 
may be different from the one included in the cipher suite name (e.g. 
server picks TLS_DHE_RSA_* but signs CertificateVerify with PSS).

> Many (most?) clients already work this way, so I don't think this
> would be too controversial. But, it seems better for the server to
> choose the cipher suite that best identifies the signature algorithm
> that it actually uses (e.g. TLS_x_ECDSA_* for a ECDSA certificate),
> instead of always using the RSA one.

Indeed, even miTLS works like this in TLS 1.2 even though this behavior 
is not permitted by current specification. As I said, I am not 
particularly set on the specifics of how to make the transition from 
pre-1.3 cipher suite names, and I'm fine with what you suggest.

>
>> The main motivation for proposing these changes is to introduce support for
>> PSS signatures in TLS and in certificates.
> Why should anybody add any new RSA-based signature scheme now?
> Shouldn't we let the RSA algorithm die off with Windows XP and other
> ancient stuff? If we're not happy with ECDSA because of the
> requirement for a perfect PRNG for randomized signatures, why not just
> specify that ServerKeyExchange in TLS 1.3 MUST use deterministic ECDSA
> signatures when an ECDSA certificate is used, or something similar
> that has similar server-side efficiency as ECDSA? There's got to be
> better alternatives to spending time tweaking support for RSA.

It is currently impossible to get a non-RSA certificate signed by any 
public CA (I know because I tried hard to get one). Only Google can 
concretely deploy EC certs today. Hence, there's is currently NO 
alternative to RSA signatures for authentication.

By the way, it may be a good idea to recommend or mandate RFC6979-style 
deterministic ECDSA signatures in TLS to prevent entropy-exhaustion 
attacks against clients and servers. Off-topic though.

Best,

Antoine