Subject: [TLS] Implicit ACKs in post-handshake

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2020 13:48:42 -0700

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

---

From: Hanno Becker <[email-masked]>
Date: Thu, 23 Apr 2020 21:22:55 +0000

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 <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Thursday, April 23, 2020 9:48 PM
To: <[email-masked]> <[email-masked]>
Subject: [TLS] Implicit ACKs in post-handshake

Hi folks,

-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.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2020 14:25:48 -0700

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 <[email-masked]> wrote:

> ------------------------------
> *From:* TLS <[email-masked]> on behalf of Eric Rescorla <
> [email-masked]>
> *Sent:* Thursday, April 23, 2020 9:48 PM
> *To:* <[email-masked]> <[email-masked]>
> *Subject:* [TLS] Implicit ACKs in post-handshake
>
> Hi folks,
>
> 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.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 24 Apr 2020 09:57:36 +1000

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:
> > *From:* TLS <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Apr 2020 17:23:00 -0700

On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson <[email-masked]> 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

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 24 Apr 2020 16:49:44 -0700

> That text is already there, thanks to Hanno.

Indeed. Given this recent addition, perhaps it's easiest to do nothing. 

Best,
Chris (no hat)