[TLS] Feedback on draft-tschofenig-tls-extended-key-update-01

[Dennis Jackson <[e-mail]>]

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://eprint.iacr.org/2016/221.pdf