On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd <watsonbl...@gmail.com> wrote:
> I wish I understood the analysis of TLS 1.3 better, but a core feature > of the protocol is compositionality: the keys from the handshake are > fresh, unlike in TLS 1.2 where they were used to encrypt the Finished > thus posing an obstacle to analysis. Here the handshake key gets used > to encrypt a message that has nothing at all to do with the handshake: > probably fine, but not obviously fine. Minor clarification (which agrees with your text below): THe EKTKey message is not encrypted with the handshake traffic key, but with the application traffic keys, just like other post-handshake handshake messages (e.g., KeyUpdate). What's more of a problem is > that the application level keys are now used multiple times: first to > encrypt part of the handshake (the EKTKey message) and then > potentially other data (RFC 5764 doesn't say you close the channel and > only do SRTP). That breaks compositionality. Safer would be to derive > separate keys for everything. > Isn't this already the case with DTLS? The application-level keys are used to encrypt both application messages and post-handshake handshake messages. > The other question I have is with the assertion that cut and paste of > the same EKTCiphertext across senders is harmless. Just for clarity: This is not related to the TLS HandshakeType request; it's about the part of EKT that happens in the SRTP stream. The data obtained > will not be random. In some cases (say if unauthenticated counter mode > is being used) it will have a very predictable relation to the > original data, and the resulting errors may leak information. These > sorts of attacks have a long history of happening: it may be more of > an issue for other parts of this whole effort, but I don't think it's > as harmless as the draft says. > If it would help make people more comfortable, I think restricting EKT to be used only with AEAD transforms would be tolerable. What you would really like here is a committing encryption scheme [1], but unfortunately there aren't any of those readily available. And although neither GCM nor ChaCha/Poly is committing [2], it's not clear that that matters here, because the attacks listed in [2] require that the attacker know both keys involved in the collision (whereas here the attacker would know neither). --Richard [1] https://eprint.iacr.org/2003/254 [2] https://eprint.iacr.org/2017/664.pdf
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
