On Tue, Jul 12, 2016 at 4:17 PM Ilari Liusvaara <[email protected]> wrote:
> On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrote: > > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara < > [email protected]> > > 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's fair. If you do the backport version, then you do have to go out of your way to do the version check. I guess the question is what other implementors intend then? We've actually done the backport on our end. Perhaps my guess that not everyone will do this is wrong. 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. > Well, we could define that EdDSA/RSA-PSS in TLS 1.2 doesn't exist and then spec-wise we're fine. The question is just which we think will cause fewer interop issues. Either way, worst case, we'd just end up in an awkward state where, when signing, one does not pick RSA-PSS in 1.2 but when verifying, one should accept it. Not the end of the world. I might just go ahead and do that anyway so I don't have to care about this issue... > > [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 [email protected] https://www.ietf.org/mailman/listinfo/tls
