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

[Joseph Salowey <[e-mail]>]

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.




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
>
>