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 <tls-boun...@ietf.org> on behalf of Eric Rescorla <e...@rtfm.com> Sent: Thursday, April 23, 2020 9:48 PM To: <tls@ietf.org> <tls@ietf.org> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
