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

[Peter Gutmann]

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

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

[David Benjamin]

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 
wrote:

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

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

[David Benjamin]

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 
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 
> wrote:
>
>> Blumenthal, Uri - 0553 - MITLL  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

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

[Rob Sayre]

On Tue, Apr 23, 2024 at 8:35 AM David Benjamin 
wrote:

> 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.
>

It's not hypothetical. I found relatively recent manuals describing how to
configure them. I didn't read the source code, it was right there in the
web page documentation.

I agree with what David says, and I can't really see why anyone would
object if someone wants to do the work.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] WG Adoption for TLS Trust Expressions

[Devon O'Brien]

After sharing our first draft of TLS Trust Expressions
 and
several discussions across a couple  IETFs, we’d like to proceed with a
call for working group adoption of this draft. We are currently prototyping
trust expressions in BoringSSL & Chromium and will share more details when
implementation is complete.

As we mentioned in our message to the mailing list from January, our
primary goal is to produce a mechanism for supporting multiple subscriber
certificates

and efficiently negotiating which to serve on a given TLS connection, even
if that ends up requiring significant changes to the draft in its current
state.

To that end, we’re interested in learning whether wg members support
adoption of this deployment model and the currently-described certificate
negotiation mechanism or if they oppose adoption (and why!).

Thanks!

David, Devon, and Bob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls