On 6 Mar 2023, at 8:13 pm, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Not really sure how to fix this, although at the moment "stay with TLS
> classic" seems to be the preferred option.
There are three stages of fixes:
1. Update the protocol specification.
2. Fix the implementations.
3. Keep using TLS 1.2 until the fixed implementations are broadly adopted.
Keeping in mind that LTS enterprise editions of Linux are lately supported
for ~13 years, step 3 may take a while. Which is not to say that we should
not start doing 1. and 2., but it is like planting an olive tree, the fruit
will be enjoyed by future generations.
The protocol specification needs to say something along the lines of:
- Implementations MUST support both psk_ke and psk_dhe_ke.
- Server operators SHOULD leave both modes enabled.
- In closed environments, or specific applications where *all*
clients are expected to and required to support psk_dhe_ke
the required to enable psk_ke is relaxed to MAY.
- Conversely, where no clients are expected to support psk_dhe_ke,
the requirement to leave it enabled changes to MAY.
- psk_dhe_ke is negotiated when supported by both sides, otherwise
psk_ke is negotiated.
- Clients SHOULD generally offer both modes in the client HELLO.
- Clients MAY offer just one or the other when appropriate for the
application in question, and can expect to interoperate with a
"general purpose" server.
Basically, one way or another, PSK key exchange mode negotiation needs
to be interoperable by default.
As for implementations, the code changes are not that difficult, but will
take time to release, and then there's step 3...
Meanwhile, when there's no other choice, keep using TLS 1.2.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
