On Sunday, 21 April 2024 23:26:56 CEST, Blumenthal, Uri - 0553 - MITLL
wrote:
I see two possibilities:
1. Nobody in the real world employs static DH anymore – in
which case this draft is useless/pointless; or
even if everybody agreed, making official, public statement on a
particular topic as a group is still worthwhile, even if for no
other reason than making it clear that is the position of the group
Especially as the view of the group changed over time.
2. On private networks people employ static DH to implicitly
authenticate their peers (a-lá MQV) – in which case this draft
is harmful.
Don't see how: just because the attack is harder to perform, lack of
forward secrecy and higher vulnerability to side-channel attacks is
an issue there too.
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 <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". ...
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.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
