________________________________ From: Mohamed Boucadair via Datatracker <nore...@ietf.org> Sent: Wednesday, April 30, 2025 10:57 AM
... ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- ... > # Write-up > The write-up lists two implementations but I failed to find where in these two > the ech service parameter is supported. I'm not sure which two implementations you're referring to. The shepherd's writeup says "This specification is implemented today by Chrome, Firefox, and Safari [1], and is deployed on all Cloudflare free tier domains [2]." > It seems to me that these implems are > more for the ECH support. Please consider updating as appropriate. Thanks. In addition to implementing ECH, these four implementations(/deployments) specifically support(/use) the "ech" SvcParamKey as specified in draft-ietf-tls-svcb-ech. Here's a random Cloudflare free tier domain, showing use of "ech=": https://dns.google/query?name=ratil.life&rr_type=HTTPS&ecs= Here's a line for reading this key in the Chromium source code: https://source.chromium.org/chromium/chromium/src/+/main:net/dns/https_record_rdata.cc;l=396;drc=3a3c641c8597f54a4eb6286d816f52b8a649c8bf > # 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. Could you point me to the text in question? I don't see any text that matches that description in draft-ietf-tls-svcb-ech. Perhaps you're concerned about Section 5.2? This section concerns how SVCB data is incorporated into the TLS handshake, and would not be relevant to a client that is using ECH without SVCB. > ## The procedure to place a connection (including the fallback part) may be > impacted by the revised HE (HAPPY WG) ... How do we plan to manage that > dependency? HE has a considerable overlap with RFC 9460 (SVCB), and potentially could Update that document. However, it has very little overlap with draft-ietf-tls-svcb-ech specifically. > ## 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? I am not aware of an OS/system API that specifically exposes SVCB resolution today. I believe the browser implementations mentioned above either (1) perform DNS resolution entirely in the application, using the system's UDP or TCP APIs or (2) use a system API like Apple's DNSServiceQueryRecord function, which returns the DNS records RDATA as a byte array. Either way, SVCB parsing is the responsibility of the application. > ## 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? In general, TLS-related specifications only describe the endpoint behaviors that achieve the standard's intended security goals. For example, RFC 8446 (TLS 1.3) Section 4.4.4 says Recipients of Finished messages MUST verify that the contents are correct and if incorrect MUST terminate the connection with a "decrypt_error" alert. If a user prioritizes connectivity over security, they could ignore this requirement and proceed anyway, but this would void TLS's security claims. Similarly, allowing "SVCB-optional" fallback in this instance would void ECH's privacy claims. > Also, how users are informed about the > reasons of connection failures? This seems like a very general topic, not in scope for a SvcParam definition draft. In general, clients and servers have a variety of mechanisms for categorizing, displaying, and reporting connection failures. As far as I know, the IETF does not standardize an error reporting schema for TLS, nor does it recommend any best practices about informing users. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > # Title: Expand SVCB The title is "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings". What is your suggested change? > # Section 2: Consider adding terms used in the document (SVCP-optional, > SVCB-reliant) Those terms are defined in RFC 9460. Are you suggesting that we repeat the definitions here? Are those the only definitions you would like to see? I've incorporated the other comments in https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/24. Regards, Ben
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
