On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrote: > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > Right, there is a risk of interop failures if two implementations disagree > on whether the algorithms exist in 1.2. Since getting these algorithms into > 1.2 is not that important, I want everyone to standardize on the easier > option (that is, they do *not* exist in 1.2). Otherwise we risk some > implementations backporting (because the spec says to) and some not > (because it is easier not to).
Unfortunately, the way things are, it is both easier and way safer to say that they *do* exist in TLS 1.2, at least for server signatures (one can leave the crazy mess that is client signatures[1]). And here RSA-PSS is even worse hazard than EdDSA. EdDSA at least requires its own EE certs, RSA-PSS works with standard RSA EE certs that are widespread. Have a TLS 1.3-capable server that doesn't check versions (easy enough[2]) and have it capped to TLS 1.2 by something (either misconfig or API issues, no end of those kind of servers) and there you go... That is, if client advertises EdDSA or RSA-PSS, it MUST be able to verify those, even after downnegotiation to TLS 1.2. If it doesn't, it MUST NOT advertise them, even in TLS 1.3 ClientHello. [1] How many borked/buggy servers there are that say they support X, but fail if you try to use X? Outside known trouble like mixing and matching curves and hashes in ECDSA? [2] There is actually very simple way to implement things that seems to work, only it blows up when client that claims it supports something it doesn't comes along... -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
