[TLS] Secdir last call review of draft-ietf-tls-svcb-ech

[tirumal reddy <[e-mail]>]

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