Re: [TLS] Comments on EndOfEarlyData

[Britta Hale <[e-mail]>]

On 17. mai 2017 00:25, Eric Rescorla wrote:

>> EOED signals the end of data encrypted with early traffic keys, yes, and
>> the next
>> message is the Finished message encrypted with the handshake traffic key.
>> However,
>> the Finished message is not *data*, and use of the application traffic key
>> is signaled
>> by the Finished message, not EOED. The Finished message, like a KeyUpdate
>> message, are
>> handshake messages, and both signal the start of a new key use for
>> application data.
>>
> In comparison, EOED signals the end of key use for application data - which
>> correlates
>> to alert behavior.
>>
> This seems like a point where reasonable people can differ, especially as
> ultimately
> the motivation for this change was some sense of architectural consistency.
>
> To go back to my earlier question: does this change actually present some
> analytic
> difficulty, or do you just find it unaesthetic?
>
It is a matter of consistency not aesthetics, and that has actual 
implications on analysis. 

Classifying message types is meaningful in terms of truncation attacks.
Under a application traffic secret, a receiver is only guaranteed protection 
from a truncation if it receives an alert (close_notify). According to the 
current draft, a server is only guaranteed protection from such an attack 
for 0-RTT data if it receives a handshake message. Such a difference is sloppy
in terms of analysis.

Furthermore, there is the inconsistency of placement of the EOED message in 
the Finished hash. The lack of synchronization of EOED, i.e. not being fixed 
with respect to the other handshake messages, could complicate analysis in 
terms of matching server/client transcripts.

-- Britta