I don't feel strongly about it, and not changing anything is certainly easier. It just felt out of place and I wanted to flag it.
-Ekr On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker <hanno.bec...@arm.com> wrote: > 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
