Re: [TLS] signature algorithm ID re-use

[Nikos Mavrogiannopoulos <[e-mail]>]

On Wed, Jul 5, 2017 at 12:50 AM, Martin Thomson <[e-mail]>
wrote:

> On 4 July 2017 at 07:43, Nikos Mavrogiannopoulos <[e-mail]> wrote:
> > 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?
>
>
> 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).
>

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