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

[Brian Smith <[e-mail]>]

Antoine Delignat-Lavaud <[e-mail]> wrote:
> The current draft of TLS 1.3 relies exclusively on signatures to prove
> ownership of private keys in certificates

How would your proposal change if signature-less authentication
mechanisms were added (later)? How would we indicate support for the
signature-less authentication?

> 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?

> The tensions between cipher suite and signature algorithm negotiation
> already existed in 1.2 and it led to oddities in the protocol, such as the
> inability to use FF-DHE authenticated by ECDSA, even though there isn't
> anything inherently wrong with this combination.

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.

> The following paragraph,
> taken from the current 1.3 draft, is another instance of this awkwardness:
>
> "If the client has offered the "signature_algorithms" extension, the
> signature algorithm and hash algorithm MUST be a pair listed in that
> extension. Note that there is a possibility for inconsistencies here. For
> instance, the client might offer DHE_DSS key exchange but omit any DSA pairs
> from its "signature_algorithms" extension. In order to negotiate correctly,
> the server MUST check any candidate cipher suites against the
> "signature_algorithms" extension before selecting them. This is somewhat
> inelegant but is a compromise designed to minimize changes to the original
> cipher suite design."

In other words, the client might offer DHE_DSS cipher suites that are
only to be used by older servers that do not understand TLS 1.2 and
the signature_algorithms extension, while TLS 1.2 implementations
should choose ECDSA. That's pretty reasonable/desirable behavior.

> - 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.

> current cipher suite negotiation). All certificates in a chain MUST also be
> signed with signature algorithms supported by the client. The same
> requirements apply even if a pre-1.3 cipher suite (such as
> ECDHE_RSA_AES256_GCM_SHA384) was selected: the algorithm in the cipher suite
> name is ignored.

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.

> 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.

Cheers,
Brian