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. 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.
The other question I have is with the assertion that cut and paste of the same EKTCiphertext across senders is harmless. 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
