Re: [TLS] Implicit ACKs in post-handshake

On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson <mt@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.Becker@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-bounces@ietf.org> on behalf of Eric Rescorla <
> ekr@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
>