MIME-Version: 1.0
References: <20190830222401.GR84368@kduck.mit.edu>
 <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie>
 <20190901235840.GN27269@kduck.mit.edu>
 <CABcZeBNuTcLSrvrhxmpOPKBxPab1UZPs4t5jc-ie8GzMqmUkLA@mail.gmail.com>
 <CAL02cgQbQNPBxJ68Qos300JAiwubtc6an2+6Ud6Y3H6y_fG4AA@mail.gmail.com>
 <6d625160-0cb4-fc62-2529-7ff1abf16b3a@cs.tcd.ie>
 <CACsn0ckpkUnZBcDcAUtEOc50hto7U_yLUdWbOCUi3aMXiA4vVg@mail.gmail.com>
In-Reply-To: <CACsn0ckpkUnZBcDcAUtEOc50hto7U_yLUdWbOCUi3aMXiA4vVg@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 5 Sep 2019 17:36:39 -0400
Message-ID: <CAL02cgTd2TdCUUp7_Ctyq1bKQZyp6yfWV8g2=nUsBpN7TCpKZA@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Eric Rescorla <ekr@rtfm.com>, 
 Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b63c980591d51e53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/0R7rs-omJzUZT-5bdfY_3RxbrDw>
Subject: Re: [TLS] FYI: new TLS HandshakeType allocation,
 from draft-ietf-perc-srtp-ekt-diet
Precedence: list

--000000000000b63c980591d51e53
Content-Type: text/plain; charset="UTF-8"

On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd <watsonbladd@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

--000000000000b63c980591d51e53
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Thu, Sep 5, 2019 at 2:38 AM Watson Ladd &lt;<a hre=
f=3D"mailto:watsonbladd@gmail.com">watsonbladd@gmail.com</a>&gt; wrote:<br>=
</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">I wish I understood the analysis of TLS 1.3 better, but a core feat=
ure<br>
of the protocol is compositionality: the keys from the handshake are<br>
fresh, unlike in TLS 1.2 where they were used to encrypt the Finished<br>
thus posing an obstacle to analysis. Here the handshake key gets used<br>
to encrypt a message that has nothing at all to do with the handshake:<br>
probably fine, but not obviously fine. </blockquote><div><br></div><div>Min=
or clarification (which agrees with your text below): THe EKTKey message is=
 not encrypted with the handshake traffic key, but with the application tra=
ffic keys, just like other post-handshake handshake messages (e.g., KeyUpda=
te).<br></div><div><br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">What&#39;s more of a problem is<br>
that the application level keys are now used multiple times: first to<br>
encrypt part of the handshake (the EKTKey message) and then<br>
potentially other data (RFC 5764 doesn&#39;t say you close the channel and<=
br>
only do SRTP). That breaks compositionality. Safer would be to derive<br>
separate keys for everything.<br></blockquote><div><br></div><div>Isn&#39;t=
 this already the case with DTLS?=C2=A0 The application-level keys are used=
 to encrypt both application messages and post-handshake handshake messages=
.</div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">
The other question I have is with the assertion that cut and paste of<br>
the same EKTCiphertext across senders is harmless. </blockquote><div><br></=
div><div>Just for clarity: This is not related to the TLS HandshakeType req=
uest; it&#39;s about the part of EKT that happens in the SRTP stream.<br></=
div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">The data obtained<br>
will not be random. In some cases (say if unauthenticated counter mode<br>
is being used) it will have a very predictable relation to the<br>
original data, and the resulting errors may leak information. These<br>
sorts of attacks have a long history of happening: it may be more of<br>
an issue for other parts of this whole effort, but I don&#39;t think it&#39=
;s<br>
as harmless as the draft says.<br></blockquote><div><br></div><div>If it wo=
uld help make people more comfortable, I think restricting EKT to be used o=
nly with AEAD transforms would be tolerable.=C2=A0 What you would really li=
ke here is a committing encryption scheme [1], but unfortunately there aren=
&#39;t any of those readily available.=C2=A0 And although neither GCM nor C=
haCha/Poly is committing [2], it&#39;s not clear that that matters here, be=
cause the attacks listed in [2] require that the attacker know both keys in=
volved in the collision (whereas here the attacker would know neither).</di=
v><div><br></div><div>--Richard<br></div><div><br></div><div>[1] <a href=3D=
"https://eprint.iacr.org/2003/254">https://eprint.iacr.org/2003/254</a></di=
v><div>[2] <a href=3D"https://eprint.iacr.org/2017/664.pdf">https://eprint.=
iacr.org/2017/664.pdf</a></div></div></div>

--000000000000b63c980591d51e53--