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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
