Subject: Re: [TLS] Simplifying signature algorithm negotiation

From: David Benjamin <[email-masked]>
Date: Mon, 29 Feb 2016 17:16:44 +0000

On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <[email-masked]> wrote:

> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <[email-masked]>
> wrote:
>
>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <[email-masked]>
>> wrote:
>>
>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
>>> TLS
>>> > 1.2, signature algorithms are spread across the handshake.
>>> [...]
>>> > I propose we fold the negotiable parameters under one name.
>>> [...]
>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm
>>> as
>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate
>>> that
>>> > instead.
>>>
>>> I previously proposed this here:
>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html
>>>
>>> ekr was against it, though it hasn't been discussed that throughly.
>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html
>>
>>
>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and
>> forgot.
>>
>> ekr, are you still against this sort of thing? I think the new CFRG
>> signature algorithms tying decisions together is a good argument for why
>> we'd want this. If we believe this trend is to continue (and I hope it
>> does. Ed25519 is a nice and simple interface), trying to decompose it all
>> seems poor.
>>
>
> I'm not sure. I agree that the CFRG thing seems to be a new development.
> I'll
> try to confirm my previous opinion or develop a new one over the weekend :)
>

ekr, did you have confirmed or new thoughts on this change?

>From elsewhere in the thread, I put together a draft PR if you wanted
something to look at in that form.
https://github.com/tlswg/tls13-spec/pull/404
It incorporated some of the suggestions in the thread (not mentioning the
really legacy values, pairing NIST curves with hashes, etc.), but that's
not the important part. The meat of the proposal is unifying signature
algorithms under one number and a shared interface, which I think is a
valuable simplification.

David

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 29 Feb 2016 20:42:32 +0200

> algorithms under one number and a shared interface, which I think is a

I think that changing the algorithm negotiation would make it both
simpler and more reliable.

Current TLS signature negotiation is not able to express real-world
constraints (matching of curve and hash[1]).

Also, I think the ranging should be as follows:
- 01xx:   Avoid (would be insecure)
- 02xx:   Avoid (would be insecure)
- 03xx:   Avoid (who uses this hash?)
- 04xx:   Schemes that sign SHA-256 hash
- 05xx:   Schemes that sign SHA-384 hash
- 06xx:   Schemes that sign SHA-512 hash
- xx00:   Avoid ("Anonymous" looks like a mistake)
- xx01:   Avoid (RSA-PKCS1-v1.5 is obsolete)
- xx02:   Avoid (DSA is obsolete)
- xx03:   ECDSA with new hashes
- Others: Other schemes

Which would allocate the new things as follows (from what I understand
RSA-PSS works):

- 0404: RSA-PSS/SHA256
- 0504: RSA-PSS/SHA384
- 0604: RSA-PSS/SHA512
- 0004: Ed25519
- 0005: Ed448 

Valid for TLS 1.2 and up.

[1] This isn't about algorithm strength matching, it is about
interop.

-Ilari