On Tuesday, 20 September 2016 15:56:01 CEST David Benjamin wrote: > On Tue, Sep 20, 2016 at 11:33 AM Ilari Liusvaara <ilariliusva...@welho.com> > > wrote: > > On Tue, Sep 20, 2016 at 03:07:51PM +0000, David Benjamin wrote: > > > 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. > > > > 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). > > 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.)
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
