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.
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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
