On Mon, Feb 29, 2016 at 05:16:44PM +0000, David Benjamin wrote:
> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <e...@rtfm.com> wrote:
> >
> > 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.
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
