Re: [TLS] Implicit ACKs in post-handshake

[Eric Rescorla <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> on behalf of Eric Rescorla <
> [e-mail]>
> *Sent:* Thursday, April 23, 2020 9:48 PM
> *To:* <[e-mail]> <[e-mail]>
> *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.
>