Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
draft-ietf-tls-svcb-ech-07
Discuss
Yes
Erik Kline
Paul Wouters
No Objection
Andy Newton
Deb Cooley
Gorry Fairhurst
Jim Guichard
Ketan Talaulikar
Recuse
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Mohamed Boucadair
Discuss
Discuss
(2025-04-30)
Sent
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
(2025-04-30)
Sent
# 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
Erik Kline
Yes
Paul Wouters
Yes
Andy Newton
No Objection
Deb Cooley
No Objection
Gorry Fairhurst
No Objection
Gunter Van de Velde
No Objection
Comment
(2025-04-29)
Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-tls-svcb-ech-07 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-07.txt # General Review # ============== 100 In wire format, the value of the parameter is an ECHConfigList 101 (Section 4 of [ECH]), including the redundant length prefix. In 102 presentation format, the value is the ECHConfigList in Base 64 103 Encoding (Section 4 of [RFC4648]). Base 64 is used here to simplify 104 integration with TLS server software. To enable simpler parsing, 105 this SvcParam MUST NOT contain escape sequences. 106 107 ech="AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQ 108 VZWNoLXNpdGVzLmV4YW1wbGUubmV0AAA=" GV> I used some tooling to decode this Base64 blob. It seems to decode into hex as follows: 0x0048fe0d004401002000201d77eb1c522d08605b179d4214ee4a3635df7e17c336ea9006655a73fcaad63e00040001000164156563682d73697465732e6578616d706c652e6e65740000 and that decodes as: Bytes | Meaning 0048fe0d | Length of the ECHConfigList (72 bytes total) 00440100 | Start of ECHConfig (first part is version 0x0044, meaning draft-13 version of ECH) 2000201d77eb1c522d08605b179d4214ee4a3635df7e17c336ea9006655a73fcaad63e0 | Key configuration and public keys for encryption (big blob) 0040 | Length of public_name 0001 | Cipher suite count (one suite) 0001 | Cipher suite ID (indicates a specific cipher, e.g., TLS_AES_128_GCM_SHA256) 64 | Length of public_name string (100 bytes) 6563682d73697465732e6578616d706c652e6e6574 | "ech-sites.example.net" (this is the public name, in ASCII) 0000 | Padding/termination Is the above is correct? maybe it is worthwhile to add this decoding example from informational perspective within the draft if this decoding activity adds value? G/
Jim Guichard
No Objection
Ketan Talaulikar
No Objection
Mahesh Jethanandani
No Objection
Comment
(2025-05-06)
Sent
I want to thank Linda Dunbar for her OPSDIR review. In particular, she brings up this point in her review: >> Additionally, diagnosing ECH failures can be difficult due to the lack of >> fallback and visibility. The draft should recommend logging and monitoring >> strategies to help operators detect misconfigurations. > I don't believe we have any relevant recommendations for logging or monitoring. Any such logging would likely not be related to the DNS records, so those recommendations would be in draft-ietf-tls-esni or a later draft. I can understand Linda's concern. This document in particular, talks about how the client learns ECH configuration for the server and what its behavior should be given the ECH configuration. Implementors will therefore be looking at this document and not a later draft on what information should be logged. Is there no guidance that this document can provide in that regard?
Orie Steele
No Objection
Comment
(2025-05-05)
Sent
# Orie Steele, ART AD, comments for draft-ietf-tls-svcb-ech-07 CC @OR13 * line numbers: - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-07.txt&submitcheck=True * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments Thanks to Barry Leiba for the ARTART review. ### degrade gracefully ``` 121 These servers SHOULD support a protocol version that is compatible 122 with ECH. At the time of writing, the compatible versions are TLS 123 1.3, DTLS 1.3, and QUIC version 1. If the server does not support a 124 compatible version, each connection attempt will have to be retried, 125 delaying the connection and wasting resources. ``` ... ``` 137 fallback would negate the privacy benefits of ECH. Accordingly, ECH- 138 capable SVCB-optional clients MUST switch to SVCB-reliant connection 139 establishment if SVCB resolution succeeded (as defined in Section 3 140 of [SVCB]) and all alternative endpoints have an "ech" SvcParam. ``` I found these requirements a bit difficult to parse. I noted the mailing list discussion here: https://mailarchive.ietf.org/arch/msg/tls/u2IbReogPhE-nbJz2EDYSjuxRv8/ https://mailarchive.ietf.org/arch/msg/tls/R_d2gDTmkGx-_dwh3iN_mFj6dyA/ I also note the security considerations section: ``` 316 in cleartext. To prevent downgrades, Section 3.1 of [SVCB] 317 recommends that clients abandon the connection attempt when such an 318 attack is detected. ``` I'm not an expert on TLS or ECH, so I found myself wondering if servers SHOULD/MUST support a protocol version that is compatible with ECH, specifically to avoid degrading gracefully.
Roman Danyliw
No Objection
Comment
(2025-05-02)
Sent
Thank you to Lucas Pardue for the GENART review. ** Section 9. Please use the formal name of the registry: OLD IANA is instructed to modify the Service Parameter Keys Registry entry for "ech" as follows: NEW IANA is instructed to modify the “DNS SVCB Service Parameter Keys (SvcParamKeys)” Registry entry for "ech" as follows:
Éric Vyncke
No Objection
Comment
(2025-04-29)
Sent
Thanks for the work done in this document (and thanks for removing this part from the base SVCB I-D). Some suggestions below: Titles of sections 4 and 5 should include "TLS" to remove any ambiguity with "DNS" server/client as the topic is about DNS. Where is "SVCB-reliant" defined in `SVCB-reliant connection establishment` ? While the examples of section 7 are welcome, I find the use of figure legends for explanations quite unreadable (notably because they are sometimes too concise and they do not clearly delineate the different examples).
Mike Bishop
Recuse
Comment
(2025-05-07)
Not sent
I am an author of this document.