Thanks. This seems like a good improvement. I have filed https://github.com/tlswg/dtls13-spec/issues/128 to track it.
On Fri, Mar 27, 2020 at 8:29 AM Hanno Becker <hanno.bec...@arm.com> wrote: > I have a minor comment on DTLS 1.3 draft 37. > > On the topic of sending ACKs, the draft recommends: > > ``` > ACKs SHOULD NOT be sent for other complete > flights because they are implicitly acknowledged by the receipt of > the next flight, which generally immediately follows the flight. > ``` > > I wonder if the case of post-handshake authentication should be > explicitly mentioned as a potential exception to this rule, since > the TLS 1.3 RFC explicitly mentions that responses to > `CertificateRequest` may be delayed in some contexts: > > ``` > Note: Because client authentication could involve prompting the user, > servers MUST be prepared for some delay, including receiving an > arbitrary number of other messages between sending the > CertificateRequest and receiving a response. > ``` > > In this case, it would be beneficial to immediately explicitly ACK > the `CertificateRequest` message even though it is also implicitly > acked through the eventual response via the `Certificate` message. > > Regards, > Hanno > 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
