On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson <m...@lowentropy.net> wrote:
> 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. > That text is already there, thanks to Hanno. -Ekr > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
