Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-svcb-ech-07: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Benjamin, Mike, and Erik, Thanks for the effort put into this specification. Thanks to Linda Dunbar for the OPSDIR review and to Ben for the follow-up. Glad to see this piece of work finally making it to publication after de-clustering with SVCB/DNR/DDR. Thanks for the follow-up clarifications provided by the authors and WG. Much appreciated. I leave my OLD ballot and trust the authors/AD to decide about whether changes are needed. =====OLD Ballot== # DISCUSS ## The specification mixes DNS client behavior and TLS client behavior. Given that SVCB is a means among others to provide the ech configuration, I would expect that what a TLS client does with the ech configuration (especially how it feeds the connection establishment process) should be part of the ECH base spec, not individual configuration mechanisms. ## The procedure to place a connection (including the fallback part) may be impacted by the revised HE (HAPPY WG) given that HAPPY CHARTER includes the following: == Since the publication of RFC 8305, several changes to common protocols, clients, and server deployments have occurred that require a revision of the algorithm. Some of these include: * Standardization and increased use of QUIC, which require updating the TCP-specific parts of Happy Eyeballs. * Introduction of Service Binding DNS resource records (SVCB and HTTPS RRs) that provide richer service information and add priorities and parameters that will change the sorting of addresses for Happy Eyeballs. * Preparations for the standardization of TLS Encrypted Client Hello, which can impact which servers a client is willing to connect to based on available security properties. * Increased deployment and refinement of IPv6-only and IPv6-mostly networks. The HAPPY working group will deliver an updated version of the Happy Eyeballs algorithm, "Happy Eyeballs Version 3", that incorporates changes to account for these developments. == How do we plan to manage that dependency? ## Deployment/Implementation considerations: internal API to invoke an underlying resolution library The TLS client may support ECH, a server may publish an ech configuration, but the internal API to invoke SVCB and receive the service parameters blob may not be available. How existing OS libraries behave for passing service parameters? Do they parse the service parameters? Or is this passed blindly? ## Configurable behaviors and failure diagnostic CURRENT: The SVCB-optional client behavior specified in (Section 3 of [SVCB]) permits clients to fall back to a direct connection if all SVCB options fail. This behavior is not suitable for ECH, because fallback would negate the privacy benefits of ECH. Accordingly, ECH- capable SVCB-optional clients MUST switch to SVCB-reliant connection establishment if SVCB resolution succeeded (as defined in Section 3 of [SVCB]) and all alternative endpoints have an "ech" SvcParam. Why no provision is made for customized configurations (based on a user action) to control how fallback is handled? Also, how users are informed about the reasons of connection failures? # Title: Expand SVCB # Abstract: s/using a SVCB or HTTPS record/using a SVCB or HTTPS resource record (RR) # Section 2: Consider adding terms used in the document (SVCP-optional, SVCB-reliant) # Section 3: s/The "ech" SvcParamKey is defined for conveying/The "ech" SvcParamKey conveys # Section 4: The first MUST is not about server behavior. Please consider a better title, e.g., s/Server behavior/Operational Considerations and TLS Server behavior # IANA: maybe helpful for readers to include a pointer where the registry is available (https://www.iana.org/assignments/dns-svcb/dns-svcb.xhtml). Cheers, Med _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
