On Thu, Apr 30, 2020 at 2:46 AM Ben Smyth <resea...@bensmyth.com> 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