2024-04-21 23:26 GMT+02:00 Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu>:
> 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?

As an implementer, these drafts help me avoid annoying conversations about why 
I don't support X or Y, and it looks like there are other implementations that 
aim (explicitly or implicitly) to implement anything that's not deprecated.

In my experience, most of the time these drafts take is due to procedural or 
"shouldn't we spend time on other things" concerns. Which is unfortunate.

> --
> 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 <tls-boun...@ietf.org> on behalf of Viktor Dukhovni 
> <ietf-d...@dukhovni.org>
> *Date: *Sunday, April 21, 2024 at 14:07
> *To: *tls@ietf.org <tls@ietf.org>
> *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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> 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

Reply via email to