MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Wed, 6 Jul 2016 09:39:53 -0800
Message-ID: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11444b06c7fb7a0536fb0fb9
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sF1CPxxb4tko_-JOT2ZF4jab32g>
Subject: [TLS] judging consensus on keys used in handshake and data messages
Precedence: list

--001a11444b06c7fb7a0536fb0fb9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We are the unenviable position of calling consensus between three choices
[0]:

- Option 1 - use the same key for both handshake and applications messages.
- Option 2 - restore a public content type and different keys.
- Option 3 - separately encrypting the content type.

At this point the consensus is rough.

The first option we would broadly characterize as supported by the
implementers because they can=E2=80=99t see the harm in using the same key =
but
opposed by the cryptographers because it makes the proofs harder making
mistakes easier to miss.

The second option as supported by researchers/cryptographers because it
cleanly separates the keys used but opposed by the implementers because
it=E2=80=99s unnecessarily complex.  In general, privacy advocates do not s=
upport
this option either.

The third was not really discussed at all and it=E2=80=99s not clear what i=
s the
impact to security proofs or implementations.

As we see it the privacy concerns are somewhat of a moving target, however
not encrypting the content type seems worse for privacy than encrypting it.

We are looking to eliminate option 2 and choose 1 or 3.  If you are in
favor of option 2 then we need to know if option 1 meets your needs, if
option 3 is better than option 1, or if you feel that the only viable
option is option 2.

J&S

[0] https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8lRreqBuiNA

--001a11444b06c7fb7a0536fb0fb9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">We are the unenviable position of calling consensus betwee=
n three choices [0]:<br><br>- Option 1 - use the same key for both handshak=
e and applications messages.<br>- Option 2 - restore a public content type =
and different keys.<br>- Option 3 - separately encrypting the content type.=
<br><br>At this point the consensus is rough.<br><br>The first option we wo=
uld broadly characterize as supported by the implementers because they can=
=E2=80=99t see the harm in using the same key but opposed by the cryptograp=
hers because it makes the proofs harder making mistakes easier to miss. =C2=
=A0 <br><br>The second option as supported by researchers/cryptographers be=
cause it cleanly separates the keys used but opposed by the implementers be=
cause it=E2=80=99s unnecessarily complex.=C2=A0 In general, privacy advocat=
es do not support this option either.<br><br>The third was not really discu=
ssed at all and it=E2=80=99s not clear what is the impact to security proof=
s or implementations. =C2=A0<br><br>As we see it the privacy concerns are s=
omewhat of a moving target, however not encrypting the content type seems w=
orse for privacy than encrypting it.<br><br>We are looking to eliminate opt=
ion 2 and choose 1 or 3.=C2=A0 If you are in favor of option 2 then we need=
 to know if option 1 meets your needs, if option 3 is better than option 1,=
 or if you feel that the only viable option is option 2.<br><br>J&amp;S<br>=
<br>[0] <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGie=
wI8lRreqBuiNA">https://mailarchive.ietf.org/arch/msg/tls/UwIHOwGzxfOGiewI8l=
RreqBuiNA</a></div>

--001a11444b06c7fb7a0536fb0fb9--