Re: [TLS] judging consensus on keys used in handshake and data messages

[Watson Ladd <[e-mail]>]

On Jul 8, 2016 6:50 AM, "Joseph Salowey" <[e-mail]> wrote:
>
> We would like to have all comments in on this by Friday, July 7, 2016.
>
> Also, to clarify, Hugo's interpretation is correct:
>
> Option 1 - use the same key for protecting both *post*-handshake and
applications messages.

I don't object to this if 2 is of the table. The only reason this option is
reasonable is that we've carefully attempted to ensure keys are separated.
I'll submit a PR to add text warning of extensions that don't do this.
(Some exist IIRC).

>
>
>
>
> On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk <[e-mail]>
wrote:
>>
>> I do not have an objection to option 1 if re-phrased as
>> Option 1 - use the same key for protecting both *post*-handshake and
applications messages..
>>
>> I believe this is what was intended by that option anyway. Let me
clarify.
>>
>> 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 (=proof) modularity property.
>>
>> 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.
>>
>> 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
>> and  I will post a public copy next week so this can be scrutinized
further.
>>
>> Hugo
>>
>>
>> On Thu, Jul 7, 2016 at 1:10 AM, Karthikeyan Bhargavan <
[e-mail]> wrote:
>>>
>>> If we are left with 1 or 3, the miTLS team would prefer 1.
>>>
>>> On the cryptographic side, Hugo has a recent (draft) paper that seems
to provide
>>> some more justification for (1), at least for client authentication.
>>>
>>> I know this is a bit off-topic, but the miTLS team would also like to
get rid of 0-RTT ClientFinished
>>> 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.
>>>
>>> Best,
>>> -Karthik
>>>
>>>
>>>> On 07 Jul 2016, at 02:49, David Benjamin <[e-mail]> wrote:
>>>>
>>>> On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla <[e-mail]> wrote:
>>>>>
>>>>> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett <[e-mail]>
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.)
>>>>>>
>>>>>> 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?
>>>>>
>>>>>
>>>>> I'm not sure what this would accomplish.
>>>>
>>>>
>>>> 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.
>>>>
>>>> But presumably something about the messages motivate this key
separation issue and I'd like to know what they are.
>>>>
>>>> David
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>