Med, Thanks for your review. Responses below.
> # Write-up > > The write-up lists two implementations but I failed to find where in these two > the ech service parameter is supported. It seems to me that these implems are > more for the ECH support. Please consider updating as appropriate. Thanks. Given that this specification is necessary for ECH, presumably those implementations include support for this specification somewhere. > # 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. I don't agree with this. This specification is concerned with how the ECHConfig structure is carried in DNS and the ECH specification is concerned with how it is used in TLS. Given that these specifications normatively reference each other and are part of the same cluster and therefore will be published together, I think it's a WG decision how to partition the text. > ## 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? Once this specification is published, the HAPPY WG will need to update the Happy Eyeballs specification appropriately; I do not anticipate any decisions made by that WG requiring changes to this specification. > ## 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? My understanding is that OS library support may or may not be sufficient to implement ECH in a client. However, I believe that the existing client-side implementations implement their own resolvers; at least chrome and Firefox do so (Firefox, just for DoH, which is the only time it enables ECH). > ## 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? Because that would allow an active attacker to bypass ECH by blocking connections. We do not generally permit configuration that enables attacks. > Also, how users are informed about the > reasons of connection failures? This depends on the client, of course, but I would anticipate something like the examples in badssl.com, such as: https://3des.badssl.com/ -Ekr On Wed, Apr 30, 2025 at 7:58 AM Mohamed Boucadair via Datatracker < nore...@ietf.org> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-svcb-ech-07: Discuss > > 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/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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. > > I have a question on the write-up and some few DISCUSS points. > > # Write-up > > The write-up lists two implementations but I failed to find where in these > two > the ech service parameter is supported. It seems to me that these implems > are > more for the ECH support. Please consider updating as appropriate. Thanks. > > # 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? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > # 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
