I see two possibilities:
1. Nobody in the real world employs static DH anymore – in which case this
draft is useless/pointless; or
2. On private networks people employ static DH to implicitly authenticate
their peers (a-lá MQV) – in which case this draft is harmful.
Overall, I’m amazed by drafts like this one. Is nothing constructive remains
out there to spend time and efforts on?
--
V/R,
Uri
There are two ways to design a system. One is to make it so simple there are
obviously no deficiencies.
The other is to make it so complex there are no obvious deficiencies.
- C. A. R. Hoare
From: TLS <[email protected]> on behalf of Viktor Dukhovni
<[email protected]>
Date: Sunday, April 21, 2024 at 14:07
To: [email protected] <[email protected]>
Subject: [EXT] Re: [TLS] Deprecating Static DH certificates in the obsolete key
exchange document
!-------------------------------------------------------------------|
This Message Is From an External Sender
This message came from outside the Laboratory.
|-------------------------------------------------------------------!
On Sat, Apr 20, 2024 at 04:12:48AM +0000, 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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
