I'll add that if we're wrong and someone *does* need these, it is all the more important that we communicate our intentions! The current situation is that we have effectively deprecated this by not adding a way to use those certificates in TLS 1.3, but we forgot to say so. A hypothetical deployment relying on these certificates would be unable to migrate to TLS 1.3, but may not realize it yet if they're slow to upgrade.
That conflict is there whether we fix the registrations or not. Fixing the registrations makes the conflict visible, so folks who need these can show up and provide input. On Tue, Apr 23, 2024 at 11:31 AM David Benjamin <david...@chromium.org> wrote: > Having worked on a TLS implementation and removed code for this, I can > tell you that is *not* simply a natural side-effect of supporting DH > certificates. These modes interact with the TLS handshake logic a fair bit. > They omit the ServerKeyExchange message and change the ClientKeyExchange > message. The latter is extra fun because it's not determined by the cipher > suite, but by what client certificate you got. (This is why TLS 1.2's > message order needs to be a somewhat funny Certificate, ClientKeyExchange, > CertificateVerify.) It's just code, and it's implementable, but as it is > unused, there is no point in expending anyone's complexity budget on it. > > I support removing these and would echo everything Filippo said. > > Not every TLS implementor follows IETF discussions carefully, or is as > well-connected as we are to the TLS ecosystem. We owe it to them to > communicate our understanding and intentions with the protocol as clearly > as we can. That includes marking things as a dead end when we believe them > to be. If someone were to use one of these today, they would be in for a > headache, between security issues, inability to upgrade to TLS 1.3, and > interop failures with other stacks. At best, they waste their time. It is > thus worth our time to document this, even if, yes, it means we have to do > this kind of spring cleaning work. I'd like to thank the folks driving this > for being willing to put time into this. > > We could make that work less time-consuming if we stopped repeating this > same discussion every time we do this necessary and responsible task. It > needn't be so much fuss to deprecate a thing that no one uses, and that we > have already tacitly disavowed by not carrying forward to TLS 1.3. > > On Tue, Apr 23, 2024 at 6:08 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> > wrote: > >> Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> writes: >> >> >Nobody in the real world employs static DH anymore – in which case this >> draft >> >is useless/pointless >> >> It's not "any more", AFAICT from my inability to find any evidence of the >> certificates needed for it in 25-odd years it's "nobody has ever used >> static >> DH" (with the absence-of-evidence caveat). >> >> >I’m amazed by drafts like this one. Is nothing constructive remains out >> there >> >to spend time and efforts on? >> >> Slow news day? End-of-financial-year clearout? Quota to fill? Someone >> lost >> a bet? Could be all sorts of things. >> >> Someone else commented on having seen code to support this, that's just a >> natural side-effect of having code that supports DH and code that supports >> certificates, you end up with code that probably supports DH certificates, >> probably because without ever having seen one to test your code with you >> can't >> be 100% sure there isn't some glitch somewhere. For example my code >> happens >> to support Elgamal certificates because there's Elgamal code in there for >> PGP >> support and so if you use an Elgamal key in a certificate you'll get an >> Elgamal certificate. As with the DH-cert code it's never been tested >> because >> I don't think such a thing as an Elgamal X.509 certificate exists, but in >> theory there's support for them in there. >> >> Peter. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
