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

From: Ben Smyth <[email-masked]>
Date: Wed, 29 Apr 2020 14:20:50 +0200

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? And why does the former rely on
deprotecting, when checking record content types is surely more efficient?

(I'm extending my TLS 1.3 tutorial --
https://bensmyth.com/publications/2019-TLS-tutorial/ -- to include
discussion of early data and I'm struggling to understand the rationale
behind these two behaviours.)

Best regards,

Ben

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 29 Apr 2020 06:43:01 -0700

Hi Ben,

Thanks for your note and for your efforts on the tutorial!

On Wed, Apr 29, 2020 at 5:43 AM Ben Smyth <[email-masked]> wrote:

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

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

Best,
-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ben Smyth <[email-masked]>
Date: Thu, 30 Apr 2020 11:45:54 +0200

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 30 Apr 2020 06:04:45 -0700

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

> 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
>> And why does the former rely on deprotecting, when checking record
>>> content types is surely more efficient?
>>>
>>

Yes.

-Ekr