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

[Ben Smyth <[e-mail]>]

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


Thanks for your support,

Ben