Re: [TLS] Implicit ACKs in post-handshake

[Hanno Becker <[e-mail]>]

Hi Ekr,

Do you see some simplifications resulting from this?

On first thought I'd think that since implementations are already able to handle implicit
ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth, too.

In contrast, it seems that if the client's Certificate message no longer
implicitly acknowledges the CertificateRequest, there's need to explicitly
explain the state machine transition upon receipt of the Certificate message
prior to receiving an ACK for the CertificateRequest.

Overall I feel that there is no need for change here, but I might miss something.

Best,
Hanno

________________________________
From: TLS <[e-mail]> on behalf of Eric Rescorla <[e-mail]>
Sent: Thursday, April 23, 2020 9:48 PM
To: <[e-mail]> <[e-mail]>
Subject: [TLS] Implicit ACKs in post-handshake

Hi folks,

As I was going through the ACK clarifications, I noticed that we were
requiring explicit ACKs for everything other than post-handshake
client auth, where we allow implicit ACK. This obviously works,
but given that (1) we expect explicit ACK from the client if there
is a user-consent delay and (2) it's the only one, what would people
think of using implicit ACKs only for the handshake itself.

-Ekr


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.