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

[Richard Barnes <[e-mail]>]

On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd <[e-mail]> 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