Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking
On Thu, Apr 30, 2020 at 2:46 AM Ben Smyth 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking
> > 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 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking
Hi Ben, Thanks for your note and for your efforts on the tutorial! On Wed, Apr 29, 2020 at 5:43 AM Ben Smyth 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. > 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 > (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 > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
