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
