No, the specification definitely can, and should, specify behaviours that
are unenforcable.
When there are preferred or recommended ways of doing something, we should
absolutely put that in writing.
On Thursday, 12 December 2024 21:07:03 CET, Christian Huitema wrote:
I like keeping as they are. Disallowing only makes sense if
that prohibition can be enforced, and one of the peer refuses
the connection if it detects key reuse. Would we want to do
that? And, even if we wanted to accept the cost of refusing
connections, could individual nodes actually detect reuse by a
peer?
-- Christian Huitema
On Dec 12, 2024, at 10:11 AM, Andrei Popov
<Andrei.Popov=40microsoft....@dmarc.ietf.org> wrote:
+1 in favor of option1.
Cheers,
Andrei
From: Russ Housley <hous...@vigilsec.com>
Sent: Thursday, December 12, 2024 9:43 AM
To: Joe Salowey <j...@salowey.net>
Cc: IETF TLS <tls@ietf.org>
Subject: [EXTERNAL] [TLS] Re: Disallowing reuse of ephemeral keys
I prefer option 1.
Russ
On Dec 12, 2024, at 12:35 PM, Joseph Salowey <j...@salowey.net> wrote:
Currently RFC 8446 (and RFC8446bis) do not forbid the reuse of
ephemeral keys. This was the consensus of the working group
during the development of TLS 1.3. There has been more recent
discussion on the list to forbid reuse for ML-KEM/hybrid key
exchange. There are several possible options here:
Keep things as they are (ie. say nothing, as was done in
previous TLS versions, to forbid the reuse of ephemeral keys) -
this is the default action if there is no consensus
Disallow reuse for specific ciphersuites. It doesn’t appear
that there is any real difference in this matter between
MLKEM/hybrids and ECDH here except that there are many more ECDH
implementations (some of which may reuse a keyshare)
Update 8446 to disallow reuse of ephemeral keyshares in
general. This could be done by revising RFC 8446bis or with a
separate document that updates RFC 8446/bis
We would like to know if there are folks who think the reuse of
keyshares is important for HTTP or non-HTTP use cases.
Thanks,
Joe, Deirdre and Sean
--
Regards,
Alicja (nee 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
To unsubscribe send an email to tls-le...@ietf.org
