Draft: draft-ietf-add-svcb-dns

Commentary: Please review . 
 currently says : This MUST seems strange . Is this just saying " do n't do silly or otherwise bad things with client queries " ? I 'm not sure that 's something we need normative language for here , so unless there 's a particular behavior that this is meant to require ( or prohibit ) , I 'd recommend removing it . 
  is your consumer - facing endpoint with limited logging , and is a debug endpoint that drops all queries into a log that 's accessible to your whole engineering staff . The point of this sentence is that , if this is your configuration , you ca n't promise users the limited logging on the consumer - facing endpoint , because any intermediary could flip users onto the debug endpoint , causing you to violate your own promise . You need to move these endpoints onto separate hostnames . Separate paths , port numbers , or even separate ALPNs , is not sufficient , because an attacker can steer the user between them . 
 I agree the original text was unclear unless you 're already familiar with the problem . I was n't . However  's response above DID make sense to me , so it would be good to use some of it . 
 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 . 
 I do n'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 to be , and this triggers an HTTP Basic Authentication response that causes the client software to pop up a  prompt , the user might log in and enable the attack . 
 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 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 . 
 "  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 . 
 Great -- I 'll propose text ! 
 I 've a small change to that tries to clarify this requirement .
Paragraph (version A):
This behavior creates a number of possible attacks for certain server
configurations.  For example, if "https://$HOSTNAME/upload" accepts
any POST request as a public file upload, the adversary could forge a
SVCB record containing "dohpath=/upload".  This would cause the
client to upload and publish every query, resulting in unexpected
storage costs for the server and privacy loss for the client.
Similarly, if two DoH endpoints are available on the same origin, and
the service has designated one of them for use with this
specification, this adversary can cause clients to use the other
endpoint instead.
Paragraph (version B):
This behavior creates a number of possible attacks for certain server
configurations.  For example, if "https://$HOSTNAME/upload" accepts
any POST request as a public file upload, the adversary could forge a
SVCB record containing "dohpath=/upload{?dns}".  This would cause the
client to upload and publish every query, resulting in unexpected
storage costs for the server and privacy loss for the client.
Similarly, if two DoH endpoints are available on the same origin, and
the service has designated one of them for use with this
specification, this adversary can cause clients to use the other
endpoint instead.
Paragraph (version A):
To mitigate redirection attacks, a client of this SVCB mapping MUST
NOT provide client authentication for DNS queries, except to servers
that it specifically knows are not vulnerable to such attacks.  If an
endpoint sends an invalid response to a DNS query, the client SHOULD
NOT send more queries to that endpoint.  DNS services that are
identified by a hostname (identity) MUST ensure that all
unauthenticated DNS requests to that name receive any promised
privacy and security guarantees, regardless of transport, port
number, or HTTP path.
Paragraph (version B):
To mitigate redirection attacks, a client of this SVCB mapping MUST
NOT identify or authenticate itself when performing DNS queries,
except to servers that it specifically knows are not vulnerable to
such attacks.  If an endpoint sends an invalid response to a DNS
query, the client SHOULD NOT send more queries to that endpoint.
Multiple DNS services MUST NOT share a hostname identifier (identity)
unless they are so similar that it is safe to allow an attacker to
choose which one is used.