Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet

[Watson Ladd <[e-mail]>]

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.