Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com>
Date: Thu, 7 Jul 2016 00:11:39 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2C29D69-FF97-4C16-941B-87C0022C6362@gmail.com>
References: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zGNp0xE3b8rvvZOqb1h-Qbo4BBA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] judging consensus on keys used in handshake and data
 messages
Precedence: list

Hi, Joe

> On 6 Jul 2016, at 8:39 PM, Joseph Salowey <joe@salowey.net> wrote:
>=20
> We are the unenviable position of calling consensus between three =
choices [0]:
>=20
> - 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.
>=20
> At this point the consensus is rough.
>=20
> 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.  =20
>=20
> 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 support this option either.
>=20
> The third was not really discussed at all and it=E2=80=99s not clear =
what is the impact to security proofs or implementations. =20
>=20
> 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.
>=20
> 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.

I will re-iterate my opposition to option 2. Some occurrences on =
non-application data records within a TLS session are initiated by user =
action or application state. Best example is when the user sees a login =
page and clicks the button that says =E2=80=9CLog in with =
certificates=E2=80=A6=E2=80=9D causing (in TLS 1.2) a HelloRequest to be =
send and a renegotiation with client certificates, or (in TLS 1.3) a =
CertificateRequest to be sent followed by the client sending a =
certificate. This is not some theoretical weakness. This is real =
information disclosure. With TLS 1.2 you can look at the Wireshark =
screen, point to the handshake record in the middle of the TCP flow and =
know that this is where the user pressed the button.

Of options 1 and 3, I can see that #3 is theoretically better, but the =
design seems too baroque to me. I hope it can be done without adding a =
whole new block operation to each record, and I prefer the simplicity of =
#1, but I=E2=80=99m not really opposed to #3. IIRC there were some =
cryptographers who were concerned about #1. We haven=E2=80=99t heard =
from them that #3 solves their issue, have we?

Yoav