Redirection attacks and TLS contexts

[chris-wood]

Section 8.1.2 recommends that clients mitigate redirection attacks by not using client authentication to DNS resolvers. Perhaps a better approach would be to not use a TLS context or association that is used for other purposes, regardless of whether that context uses client authentication.

[bemasc]

I don't think that is sufficient. The attack does not depend on the client authentication being shared with another context. For example, if I rewrite the dohpath to be /upload, and this triggers an HTTP Basic Authentication response that causes the client software to pop up a username+password prompt, the user might log in and enable the attack.

[chris-wood]

There are lots of ways connection state could be misused here. For example, what if the new DNS query is sent over a connection that uses cookies? What if the DNS query resumes a previously established TLS connection that used some application layer authentication? Basically, this text

To mitigate redirection attacks, a client of this SVCB mapping MUST NOT provide client authentication for DNS queries...

seems not quite right, since it seems to focus on TLS-layer things. I recommend further refining to make it clear what is expected of this new connection. I'm happy to propose a PR to clarify my thinking, if that would be useful.

[bemasc]

"Client authentication" in this text is not intended to to be limited to TLS. It applies to any form of client authentication in any protocol, including HTTP.

[chris-wood]

Great -- I'll propose text!

[bemasc]

I've added a small change to #17 that tries to clarify this requirement.