Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking

[Eric Rescorla <[e-mail]>]

On Thu, Apr 30, 2020 at 2:46 AM Ben Smyth <[e-mail]> wrote:

> Section 4.2.10 requires a server receiving early data to behave in ways
>>> including (p53):
>>>
>>> * Ignore the extension and return a regular 1-RTT response.  The server
>>> then skips past early data by attempting to deprotect received records
>>> using the handshake traffic key, discarding records which fail
>>> deprotection...
>>>
>>> * Request that the client send another ClientHello by responding with a
>>> HelloRetryRequest... The server then ignores early data by skipping all
>>> records with an external content type of "application_data"...
>>>
>>> What are the use cases for each behaviour?
>>>
>>
> I expect that the first response will be the ordinary one. However, in
>> some cases you will be forced to employ the second one because it is not
>> possible to send a SH. For instance, consider the case where the server has
>> been reconfigured and no longer accepts the DH group that the client
>> employs in the CH. In that case, it will have to send HRR.
>>
>
> SH and HRR are simply used in their usual ways: Thanks for the
> clarification.
>
>
>> And why does the former rely on deprotecting, when checking record
>>> content types is surely more efficient?
>>>
>>
>> Unfortunately, the record types are encrypted, and this will not work.
>>
>
> (I meant the external content type. But, that doesn't work anyhow.)
>
> I have now understood:
>
> When not consuming early data, respond with SH or HRR. For the former,
> given that all messages will be encrypted, the server must decrypt messages
> with the handshake traffic key, discard messages when decryption fails, and
> treat the first successfully decrypted message as the client's next
> handshake message, thereafter proceeding as if no early data were sent. For
> the latter, the second CH message will be unencrypted and the server can
> discard all encrypted messages (identified by record type 0x23, rather than
> 0x22), before proceeding as if no early data were sent when the second CH
> is identified.
>

Yes.

-Ekr


> Thanks for your support,
>
> Ben
>