Re: [TLS] [EXT] Re: Deprecating Static DH certificates in the obsolete key exchange document

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 <pgut001@cs.auckland.ac.nz>
wrote:

> Blumenthal, Uri - 0553 - MITLL <uri@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
>