Subject: [TLS] Renumbering the new SignatureSchemes

From: David Benjamin <[email-masked]>
Date: Tue, 20 Sep 2016 15:07:51 +0000

Hi folks,

I've just uploaded this PR to slightly tweak SignatureScheme numbering:
https://github.com/tlswg/tls13-spec/pull/641

In principle, we should only have needed to burn values starting with known
HashAlgorithms, but TLS 1.2 said:

   signature
      This field indicates the signature algorithm that may be used.
      The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
      [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively.  The
      "anonymous" value is meaningless in this context but used in
      Section 7.4.3.  It MUST NOT appear in this extension.

We'd started RSA-PSS along the train to get shipped in Chrome to get early
warning on any interoperability issues. We ran into an implementation which
enforced this MUST NOT. It's a MUST NOT in 1.2, so it seems prudent to
allocate around it and avoid ending in known SignatureAlgorithms. Thus,
rather than only burning {0x00-0x06, *}, we also burn {*, 0x00-0x03}. This
has the added benefit that TLS 1.2 dissector tools don't get confused.

(I'm not sure how to express it in the enum syntax or IANA registry, so I
left it a TODO in the PR.)

David

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 20 Sep 2016 18:33:27 +0300

> has the added benefit that TLS 1.2 dissector tools don't get confused.

Heck, I think one could put the RSA-PSS ones as 0404, 0504 and 0604,
as those do have the indicated "prehashes".

And one could probably also stick Ed25519/Ed448 in 00xx, as those have
no prehash, which is exactly what "hash #0" is about.

(Of course, this all is pretty pointless bikeshedding).

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Tue, 20 Sep 2016 15:56:01 +0000

> (Of course, this all is pretty pointless bikeshedding).

The ecdsa_p256_sha256 business means that the old scheme isn't quite
accurate. And if we are to drop the old scheme, it was intentional on my
part that RSA-PSS did not look like it, even though it still fit. I think
that paid off. No one's going to implement Ed25519 for a while, so RSA-PSS
is our smoke test that this SignatureScheme idea is sane. (Both for interop
and for making sure removing the hash/sig decomposition in implementations
internally is sound.)

David

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 20 Sep 2016 09:14:00 -0700

This seems like a good change. I'll merge it before -16 unless someone
objects.

On Tue, Sep 20, 2016 at 8:56 AM, David Benjamin <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Hubert Kario <[email-masked]>
Date: Tue, 20 Sep 2016 20:14:27 +0200

On Tuesday, 20 September 2016 15:56:01 CEST David Benjamin wrote:
> > > In principle, we should only have needed to burn values starting with
> > 
> > known
> > 
> > > We'd started RSA-PSS along the train to get shipped in Chrome to get
> > 
> > early
> > 
> > > warning on any interoperability issues. We ran into an implementation
> > 
> > which
> > 
> > > rather than only burning {0x00-0x06, *}, we also burn {*, 0x00-0x03}.
> > 
> > This
> > 

I'll be running test looking for intolerances like this over the Alexa top 1 
million next month.

For now I have a probe that adds values 0x0003, 0x0004, 0x0700, 0x0703 and 
0x0704 at the end of the list of algorithms.

Would you suggest doing something more with it?

(I will be looking for key_share extension intolerance as a whole too)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Tue, 20 Sep 2016 18:24:42 +0000

> I'll be running test looking for intolerances like this over the Alexa top

(I've already done this, by the way. It's where the numbers in the version
negotiation thread came from.)

> 0x0704 at the end of the list of algorithms.

At the front is probably more realistic. There is even a MUST-level
requirement in the current TLS 1.3 spec for SHA-1 sigalgs to be at the end,
so the new ones can't be (unless you take SHA-1 out, which is, sadly,
unrealistic today... an upsetting number of 1.2 servers only sign SHA-1).

I was able to find a few instances of an NSS bug (
https://bugzilla.mozilla.org/show_bug.cgi?id=1119983), but nothing else.

The offending implementation for this thread was actually a WebRTC stack
(DTLS), not an HTTPS server. We hit it via Chrome's Dev channel. But since
this intolerance comes from a MUST-level requirement in TLS 1.2, I think
it's prudent to renumber.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 21 Sep 2016 12:20:54 +0200

> negotiation thread came from.)

even if there is no glory in it, reproducibility studies are important in 
scientific approach :)

> At the front is probably more realistic. 

good point

> There is even a MUST-level

yes, I see around 5% of servers doing that
 
> it's prudent to renumber.

True, but then we should check if we don't hit even bigger problems.