Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Douglas Stebila <dstebila@gmail.com>
In-Reply-To: <CADi0yUPXXwdRNJfrP_HiL9-F-8fuqstTpBukWgtEMkpSnQnysg@mail.gmail.com>
Date: Thu, 7 Jul 2016 21:47:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CA6DA4EA-16CE-4FC9-8930-019CC5CAFDAB@gmail.com>
References: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com>
 <A2C29D69-FF97-4C16-941B-87C0022C6362@gmail.com>
 <CAF8qwaC+iXoJ_Z9xuB4UqR4-7EmXUmr2pRRcBDxtDP-eZ8LzAg@mail.gmail.com>
 <201607062024.46745.davemgarrett@gmail.com>
 <CABcZeBO_Nh_u+++wOqH68j3mNfkM3A+W+4ZR7-J0ciV0-4q1KA@mail.gmail.com>
 <CAF8qwaArt-kmRf3EBdo4j7Q-xFEe25LZLperxzqtKqV-2sbJ1Q@mail.gmail.com>
 <4809BB22-BF00-4824-93BD-2C66497CC557@gmail.com>
 <CADi0yUPXXwdRNJfrP_HiL9-F-8fuqstTpBukWgtEMkpSnQnysg@mail.gmail.com>
To: Hugo Krawczyk <hugo@ee.technion.ac.il>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/huvNtwLq6BoPrJ9JOsIezjLoW9I>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>,
 "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] judging consensus on keys used in handshake and data
 messages
Precedence: list

With Hugo's analysis of the secure channel-like security afforded even =
when the application key is used to encrypt non-application data, and as =
C=C3=A9dric pointed out to me the application key will be used to =
encrypt non-application data like certain alert messages; so I think =
option 1 is a reasonable choice, and option 3 would not recover the =
composability property we hoped it might.

Douglas


> On Jul 7, 2016, at 12:44 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> =
wrote:
>=20
> I do not have an objection to option 1 if re-phrased as=20
> Option 1 - use the same key for protecting both *post*-handshake and =
applications messages..=20
>=20
> I believe this is what was intended by that option anyway. Let me =
clarify.
>=20
> I understand the question as relating *only* to post-handshake =
messages and not
> to the main handshake (three initial flights). For the latter we have =
key
> separation in the sense that none of these main-handshake messages is =
encrypted
> under the application key but rather under dedicated handshake keys. =
This should
> not be changed as it provides key indistinguishability to the =
application key, a
> desirable design and analysis (=3Dproof) modularity property.
>=20
> On the other hand, for post-handshake messages, and particularly for =
encrypting
> post-handshake client authentication messages, preserving key
> indistinguishability is not relevant since at the time of =
post-handshake
> client authentication, the application key has already lost its =
indistinguishability
> by the mere fact that the key was used to encrypt application data. =
Key
> indistinguishability is the main reason to insist in key separation =
and this
> principle does not apply here anymore hence removing the objection to =
1.
>=20
> I'd note that the best one could hope for in the post-handshake =
setting is that
> as a result of post-handshake client authentication the application =
key becomes
> a secure mutually-authenticated key for providing "secure channels" =
security.
> As pointed out by others in previous posts I have an analysis showing =
that this
> delayed mutual authentication guarantee is achieved even if one uses =
the
> application key to encrypt the post-handshake messages. I have =
circulated a
> preliminary version of the  paper among cryptographers working on TLS =
1.3=20
> and  I will post a public copy next week so this can be scrutinized =
further.
>=20
> Hugo
>=20
>=20
> On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan =
<karthik.bhargavan@gmail.com> wrote:
> If we are left with 1 or 3, the miTLS team would prefer 1.
>=20
> On the cryptographic side, Hugo has a recent (draft) paper that seems =
to provide
> some more justification for (1), at least for client authentication.=20=

>=20
> I know this is a bit off-topic, but the miTLS team would also like to =
get rid of 0-RTT ClientFinished=20
> if that is the only message left in the 0-RTT encrypted handshake =
flight. That should remove
> another Handshake/Data key separation from the protocol, leaving only =
3 keys: 0-RTT data,
> 1-RTT handshake, and 1-RTT data.=20
>=20
> Best,
> -Karthik
>=20
>=20
>> On 07 Jul 2016, at 02:49, David Benjamin <davidben@chromium.org> =
wrote:
>>=20
>> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <ekr@rtfm.com> wrote:
>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <davemgarrett@gmail.com> =
wrote:
>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
>> > I'm also curious which post-handshake messages are the problem. If =
we were
>> > to rename "post-handshake handshake messages" to "post-handshake =
bonus
>> > messages" with a distinct bonus_message record type, where would =
there
>> > still be an issue? (Alerts and application data share keys and this =
seems
>> > to have been fine.)
>>=20
>> Recasting all the post-handshake handshake messages as not something =
named "handshake" does make a degree of sense, on its own. =
(bikeshedding: I'd name it something more descriptive like "secondary =
negotiation" messages or something, though.) Even if this doesn't =
directly help with the issue at hand here, does forking these into a new =
ContentType sound like a useful move, in general?
>>=20
>> I'm not sure what this would accomplish.
>>=20
>> Me neither. To clarify, I mention this not as a suggestion, but to =
motivate asking about the type of message. If the only reason the proofs =
want them in the handshake bucket rather than the application data =
bucket is that they say "handshake" in them then, sure, let's do an =
inconsequential re-spelling and move on from this problem.
>>=20
>> But presumably something about the messages motivate this key =
separation issue and I'd like to know what they are.
>>=20
>> David
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls