Hi Tiru, Thanks for the review. I've filed it as https://github.com/tlswg/draft-ietf-tls-svcb-ech/issues/21.
1. I've opened a PR to add examples: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/22 2. This text was heavily debated in DNSOP: https://mailarchive.ietf.org/arch/msg/dnsop/zOx_7v4GShtMX0MMj5djSCxs7hk/. While I would love to have a stronger recommendation here, I would prefer not to reopen this issue. 3. The text makes the privacy properties clear. I don't think it is appropriate or useful for us to instruct implementors about how to describe these properties to their users. 4. I've opened a PR to add a reference: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/23 5. This seems like a topic that is related to ECH generally, not specific to the "ech" SVCB parameter, so I don't think it should be covered in this document. --Ben Schwartz ________________________________ From: tirumal reddy <kond...@gmail.com> Sent: Tuesday, December 10, 2024 1:39 AM To: draft-ietf-tls-svcb-ech....@ietf.org <draft-ietf-tls-svcb-ech....@ietf.org>; <tls@ietf.org> <tls@ietf.org>; Last Call <last-c...@ietf.org> Subject: Secdir last call review of draft-ietf-tls-svcb-ech This Message Is From an External Sender Reviewer: Tirumaleswar Reddy K Review result: Ready with issues I have reviewed this document as part of the SEC area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security area directors. Document editors and WG chairs should treat these comments just like any other last-call comments. 1. A SVCB RRSet containing some RRs with "ech" and some without is vulnerable to a downgrade attack: a network intermediary can block connections to the endpoints that support ECH, causing the client to fall back to a non-ECH endpoint. This configuration is NOT RECOMMENDED. Comment> Please mention scenarios where such mixed behavior may be acceptable. Highlighting the exceptions would be helpful. 2. ECH ensures that TLS does not disclose the SNI, but the same information is also present in the DNS queries used to resolve the server's hostname. This specification does not conceal the server name from the DNS resolver. If DNS messages are sent between the client and resolver without authenticated encryption, an attacker on this path can also learn the destination server name. A similar attack applies if the client can be linked to a request from the resolver to a DNS authority. Comment> While authenticated encryption provides protection against active attackers, the privacy benefits are negated if the DNS resolver itself is malicious. It may be useful to recommend using trusted DNS resolvers. 3. It will be helpful to provide recommendations to endpoint implementations not to mislead end-users that "ECH" would provide the same level of security fully anonymizing solutions like Tor, "ECH" may not provide any privacy because of the reasons discussed in 2nd paragraph of Security Considerations Section. 4. The discussion on the anonymity set could benefit from examples or references that illustrate how traffic analysis might narrow it. 5. The behaviour recommendation for middleboxes acting as a TLS proxy should be discussed. Cheers, -Tiru
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
