What makes this case interesting is the non-machine time that might exist between receiving CertificateRequest and sending Certificate.
In most of the exchanges, we expect there to be an answer that is immediately available, so that the implicit ACK works. Here we have to recognize that ACK might need to be sent anyway if the Certificate message is going to take time to source. If we don't have something already, it might pay to at least mention that if there are significant delays involved in preparing a response, an ACK SHOULD be sent rather than relying on implicit acknowledgment. On Fri, Apr 24, 2020, at 07:25, Eric Rescorla wrote: > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
