Subject: [TLS] signature algorithm ID re-use

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 04 Jul 2017 16:43:28 +0200

Hi,
 The latest TLS 1.3 draft re-uses the sha256(4), sha384(5), sha512(6)
with ecdsa(3) signature algorithms IDs for the following signature
algorithms:
    /* ECDSA algorithms */
    ecdsa_secp256r1_sha256(0x0403),
    ecdsa_secp384r1_sha384(0x0503),
    ecdsa_secp521r1_sha512(0x0603),

These are similar but have different semantics; as indicated by their
name they can be used with a single curve. That makes the handshake
conversation something like:

Client: Use ecdsa_secp256r1_sha256 under TLS 1.3 or ecdsa with
whichever curve and sha256 if under TLS 1.2.

That apart from being confusing, means that a client which is willing
to fallback to TLS 1.2 cannot restrict its options to
ecdsa_secp256r1_sha256 (i.e., require the secp256r1 curve for
signatures).

One could work-around it, by utilizing the elliptic curves extension,
but that has also different semantics under TLS 1.3.

So my question is why not go for the simpler approach and create new
identifiers for the new signature algorithms? (similarly to RSA-PSS).
Is there an advantage of re-using the ECDSA signature algorithm
identifiers to mean something different in TLS 1.3? Was there some
discussion on the topic on the list?

[0]. https://github.com/tlswg/tls13-spec/issues/1035

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Jul 2017 15:50:28 -0700

> discussion on the topic on the list?

This was fairly extensively litigated.  I remember Hannes asking
exactly the same question, but I forget which in-person meeting it
was.  It might have been IETF 97.

Unfortunately, any search I do on this subject turns up the hundreds
of emails on using signature algorithms for selecting certificates.

What I've found is that this isn't that difficult to implement
correctly, even across versions.  As David Benjamin suggested in
earlier emails, you can change to using a 16-bit codepoint in your
code.  Then you add a curve-matching restriction if the selected
version is TLS 1.3 (or greater).

The only issues we had was with the functions it uses to configure the
stack, but those are internal issues.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 7 Jul 2017 10:40:19 +0200

> version is TLS 1.3 (or greater).

Well, it depends on the definition of correctly :) You can certainly have
interoperation following something similar to what you describe, however
the question is what about semantics. How do you translate that to the
user? If one is careful with semantics and would like to let the user
specify a policy of allowed operations/signature algorithms, he would have
to specify two different signature algorithms, one for ecdsa with any
curve, and another for the restricted to secp256r1, and then make sure that
what is sent over the wire will be interpreted according to the policy by a
TLS 1.2 or a TLS 1.3 server (which I find it quite impossible for any
policy which requires anything else than a single curve and signature
algorithm).

That's why my question is on what is the advantage of the code point
re-use, because I see only disadvantages.

regards,
Nikos