Re: [TLS] TLSv1.3 Cookies

[Matt Caswell <[e-mail]>]

On 13 September 2017 at 17:08, Ilari Liusvaara <[e-mail]> wrote:
>> > Yes, if one receives a ClientHello with both Cookie and EarlyData, one
>> > can reply with a fatal alert, because that is not supposed to happen.
>>
>> That isn't quite the scenario I was talking about. Rather your case
>> (2) above in a server which is operating statelessly, i.e. the client
>> has attempted to send early_data but has not provided a valid cookie
>> yet. The early_data when it arrives will look like bad packets, even
>> though (from the client perspective) it was valid to send them.
>
> If you really got some transport that uses TLS on something where
> stateless operation makes sense (so not TCP) that transports the 0-RTT
> TLS data in-band (so not QUIC), just throw any initial records starting
> with 0x17 into trash.
>
> AFAIK, QUIC does not use TLS 0-RTT data, it uses 0-RTT exporters to
> derive encryption keys for data, that is sent outside TLS. So in
> that case, TLS would see two consequtive ClientHello messages if the
> first gets rejected.


Ah! Right - yes that is a good point. I was looking at this from the
perspective of the need to support QUIC. I had missed that subtlety -
thanks. There is still a theoretical issue if something other than
TLS/TCP or TLS/QUIC wants to do this. But given there is no actual
known use case for that then I guess we can cross that bridge when we
come to it.

Matt