Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
On Sat, Apr 20, 2024 at 04:12:48AM +, Peter Gutmann wrote: > I realise that absence of evidence != evidence of absence, but in response to > my previous request for anyone who has such a thing to comment on it, and even > better to send me a sample so I can see one, no-one has mentioned, or > produced, even one example of "a legitimate CA-issued [static-epmeheral DH > certificate] rather than something someone ran up in their basement for fun". > > So is the draft busy deprecating unicorns and jackalopes? Nothing against > that, but it's probably worth adding a note that such certificates are > currently not known to exist so you probably don't have to worry about it too > much. Can't say I've seen any static DH certificates in the wild, but I have seen code to support these, and perhaps the point is to bless deprecating/disabling/removing such code? In any case, this feels like cosmetic cleanup, rather than an effort to migrate a significant population of existing users to better practice. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
I realise that absence of evidence != evidence of absence, but in response to my previous request for anyone who has such a thing to comment on it, and even better to send me a sample so I can see one, no-one has mentioned, or produced, even one example of "a legitimate CA-issued [static-epmeheral DH certificate] rather than something someone ran up in their basement for fun". So is the draft busy deprecating unicorns and jackalopes? Nothing against that, but it's probably worth adding a note that such certificates are currently not known to exist so you probably don't have to worry about it too much. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
On Mon, 15 Apr 2024 at 22:14, Joseph Salowey wrote: > > At IETF 119 we had discussion that static DH certificates lead to static key > exchange which is undesirable. Although the current draft deprecates static > DH ciphersuites, it seems that RFC 5246 allows the client to provide a > certificate with a static DH keypair to provide static parameters in (EC)DHE > in TLS 1.2 (I don't know of any implementations that do this). > > Should the draft deprecate these ClientCertificateTypes and mark the entries > (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' > discouraged? > > Please respond with any comments on this proposal by April 30,2024. > Yes. > Thanks, > > Sean, Deirdre and Joe > ___ > 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] Deprecating Static DH certificates in the obsolete key exchange document
Yes. (Draft coauthor here. FWIW, I'm not sure how much bandwidth I'll have to continue moving the draft forward. Regardless, this sounds like a good idea to me.) On Mon, 15 Apr 2024 at 21:14, Joseph Salowey wrote: > At IETF 119 we had discussion that static DH certificates lead to static > key exchange which is undesirable. Although the current draft deprecates > static DH ciphersuites, it seems that RFC 5246 allows the client to provide > a certificate with a static DH keypair to provide static parameters in > (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). > > Should the draft deprecate these ClientCertificateTypes and mark the > entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as > 'D' discouraged? > > Please respond with any comments on this proposal by April 30,2024. > > Thanks, > > Sean, Deirdre and Joe > ___ > 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] Deprecating Static DH certificates in the obsolete key exchange document
Joseph Salowey writes: >At IETF 119 we had discussion that static DH certificates lead to static key >exchange which is undesirable. Has anyone every seen one of these things, meaning a legitimate CA-issued one rather than something someone ran up in their basement for fun? If you have, can I have a copy for the archives? The only time I've ever seen one was some custom-created ones for S/MIME when the RSA patent was still in force and we were supposed to pretend to use static-ephemeral DH for key transport instead of RSA. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
2024-04-15 20:14 GMT+02:00 Joseph Salowey : > Should the draft deprecate these ClientCertificateTypes and mark the entries > (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' > discouraged? Oh, yes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
On Tue, Apr 16, 2024, at 04:14, Joseph Salowey wrote: > Should the draft deprecate these ClientCertificateTypes and mark the > entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) > as 'D' discouraged? Yes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
At IETF 119 we had discussion that static DH certificates lead to static key exchange which is undesirable. Although the current draft deprecates static DH ciphersuites, it seems that RFC 5246 allows the client to provide a certificate with a static DH keypair to provide static parameters in (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). Yes. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Deprecating Static DH certificates in the obsolete key exchange document
Yes. -Ekr On Mon, Apr 15, 2024 at 11:14 AM Joseph Salowey wrote: > At IETF 119 we had discussion that static DH certificates lead to static > key exchange which is undesirable. Although the current draft deprecates > static DH ciphersuites, it seems that RFC 5246 allows the client to provide > a certificate with a static DH keypair to provide static parameters in > (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). > > Should the draft deprecate these ClientCertificateTypes and mark the > entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as > 'D' discouraged? > > Please respond with any comments on this proposal by April 30,2024. > > Thanks, > > Sean, Deirdre and Joe > ___ > 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
[TLS] Deprecating Static DH certificates in the obsolete key exchange document
At IETF 119 we had discussion that static DH certificates lead to static key exchange which is undesirable. Although the current draft deprecates static DH ciphersuites, it seems that RFC 5246 allows the client to provide a certificate with a static DH keypair to provide static parameters in (EC)DHE in TLS 1.2 (I don't know of any implementations that do this). Should the draft deprecate these ClientCertificateTypes and mark the entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as 'D' discouraged? Please respond with any comments on this proposal by April 30,2024. Thanks, Sean, Deirdre and Joe ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
