Hi,
I thought the old version was a quite good starting point. This new version
seems significantly worse. I think it has three major problems:
1. It uses the application layer and therefore requires changes in the
application layer. For many uses of TLS, it is not acceptable to change the
application layer. I also don't think it makes sense to do the TLS key exchange
on the application layer. As Dennis Jacksson writes: " This seems rather
complex and likely to go wrong. The original version of this draft where the
key exchange was carried in the extended key update message seems much simpler
to implement and easier to analyse". I would add that I would not want my keys
to leave the TLS library. Authentication on the application layer makes sense
for web applications using HTTP/2 and QUIC where the endpoints might need to
correlate the certificate request with the application-level event that
triggered it. For infrastructure use of TLS/DTLS/QUIC I think reauthentication
on the transport layer is a must.
2. As pointed out by Dennis Jacksson, it uses static-ephemeral key exchange
instead of ephemeral-ephemeral key exchange, which does not at all give the
same security properties. I think all requests have been for
ephemeral-ephemeral key exchange.
3. I don't see the need for HPKE. All discussions, specifications, and
deployments of PQC KEMs in TLS 1.3 and DTLS 1.3 uses the ordinary
"KeyShareEntry". Replacing the existing key exchange mechanism in TLS with the
public key encryption mechanism HPKE. This seems to add a lot of code to an TLS
implementation already doing quantum-resistant key exchange in the initial
handshake.
I think a solution to do post-handshake ephemeral-ephemeral key exchange as
well as mutual post-handshake authentication on the TLS/DTLS/QUIC layer would
be very welcome. I think ephemeral-ephemeral key exchange as well as not using
the application layer should be requirements.
I think frequent rekeying with ephemeral-ephemeral key exchange is a must for
long-lived interfaces. This has for a long time been an established
requirement. Typical requirements are 1 hour of 100 GB in IPsec and 1 hour or 1
GB in SSH. Note that there is no problem with TLS 1.3 when you can frequently
setup new connection with psk_dhe_ke. Discussing with Eric Rescorla and Martin
Thomson in the past, they suggested that this was the way forward. It would be
interesting to hear if there are more use cases than RFC 6083 where frequently
setting up a new connection with psk_dhe_ke is problematic. I expect there is.
Long-term, I think QUIC is much more important than TLS and DTLS. The telecom
sector work in 10-year generation (4G, 5G, 6G). In 6G, expected to be
standardized in 2029, I expect most use of TCP, SCTP, TLS, and DTLS to be
replaced by QUIC.
The citation (R13) from ANSSI only talks about rekeying. Equally important is
R12 which says that
"If available, one shall activate the PFS property in IKEv2 second phase"
(a.k.a “quick mode”) using a Diffie-Hellman key exchange or its elliptic curve
variant."
Cheers,
John Preuß Mattsson
From: TLS <tls-boun...@ietf.org> on behalf of Dennis Jackson
<ietf=40dennis-jackson...@dmarc.ietf.org>
Date: Tuesday, 19 March 2024 at 02:38
To: TLS List <tls@ietf.org>
Subject: [TLS] Feedback on draft-tschofenig-tls-extended-key-update-01
A new version of this draft was published a few weeks ago with an
entirely new design. Unless I missed it, the new version hasn't yet been
discussed on the TLS list and I was unaware of the changes until I came
to prepare for the meeting. I have quite a few concerns - I'm sorry to
bring them up so close to the meeting.
Firstly, the draft as specified does not achieve the claimed security goal:
> Security Considerations:
>
> To perform public key encryption the sender needs to have access to
> the public key of the recipient. This document makes the assumption
> that the public key in the exchanged end-entity certificate can be
> used with the HPKE KEM. The use of HPKE, and the recipients long-term
> public key, in the ephemeral-static Diffie-Hellman exchange provides
> perfect forward secrecy of the ongoing connection and demonstrates
> possession of the long-term secret key.
An ephemeral-static Diffie-Hellman exchange does not provide forward
secrecy. If the attacker can compromise the endpoint with the static
public key, they can decrypt all previously transmitted ciphertexts to
this peer and so recover all past keys, violating forward secrecy. This
wasn't an issue in the old draft where ephemeral-ephemeral DH exchanges
were used.
Secondly, I think there is some confusion about what forward secrecy is.
Forward secrecy means that compromise in the future will not enable the
decryption of past messages. The existing KeyUpdate mechanism in TLS1.3
achieves forward secrecy by ratcheting forwards the used keys and
throwing away the old ones. So no changes are required to TLS1.3 to
enjoy forward secrecy in long-lived connections, just do the existing
key update and be sure to throw away the old keys correctly.
> Introduction:
>
> If a traffic secret (referred as application_traffic_secret_N) has
> been compromised, an attacker can passively eavesdrop on all future
> data sent on the connection, including data encrypted with
> application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
This is not forward secrecy but post-compromise security (PCS) [1]
(sometimes called Backwards Secrecy as it is the complement of Forward
Secrecy). As the draft identifies, a fresh key exchange is needed to
ensure PCS. However, as mentioned earlier in the PFS case, this key
exchange needs to be with freshly generated ephemeral keys. It does no
good to use an existing static key since the attacker might have already
compromised it.
Finally, I'm really not sure about the decision to mix the TLS and
Application layers by having the application carry the HPKE ciphertexts.
This seems rather complex and likely to go wrong. The original version
of this draft where the key exchange was carried in the extended key
update message seems much simpler to implement and easier to analyse.
If the authors do want to go with some kind of application specific key
exchange, I would suggest rethinking this draft as purely a way to bring
entropy into the TLS1.3 key exchange, a TLS1.3 Key Importer if you will.
This would work by having the application to signal to the TLS1.3 layer
that a key was ready to be imported (with a particular key-id and key
material). The TLS library would communicate this to the peer with a
message similar to the one currently defined in the draft carrying the
key-id. The new key material would be mixed to the current secret in
when the peer confirmed it had also been passed the key id and material
by its application. The details about some kind of application layer key
exchange would then need to go in a different document and use
ephemeral-ephemeral exchange as highlighted.
Given the complexities around the use of middleboxes which may not be
available to the peers, it might be necessary to use an exported
authenticator so the applications could confirm they were sharing a
single TLS connection and not two duct-taped together (which would be
unable to successfully import new keys). This seems like a like of
complexity compared to the initial draft.
Best,
Dennis
[1]
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Feprint.iacr.org%2F2016%2F221.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd34fe02fd206413710bb08dc4769c3e5%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638463766908929331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wYsW%2FmGtBpzGYOi5InysvjXrnBDzoVgw%2Fxol5iGsXxI%3D&reserved=0<https://eprint.iacr.org/2016/221.pdf>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cd34fe02fd206413710bb08dc4769c3e5%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638463766908936322%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Kp2B%2BSDnRYjO2bNFM0fLUL4o4NOazx0PaCYCMCKasY0%3D&reserved=0<https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
