Re: [Last-Call] Dnsdir last call review of draft-ietf-add-svcb-dns-08

"Rose, Scott W. \(Fed\)" <scott.rose=40nist.gov@xxxxxxxxxxxxxx> · Wed, 5 Apr 2023 14:05:46 +0000

From: Benjamin Schwartz <benjamin.m.schwartz@xxxxxxxxx>

On Tue, Apr 4, 2023 at 9:54 AM Scott Rose via Datatracker <noreply@xxxxxxxx> wrote:

Reviewer: Scott Rose

Review result: Ready with Issues

Overall it is fine and does not change the DNS or DoH protocol or the SVCB

RRType defined in another document. There is the dependence on the SVCB

Internet-Draft advancing before this one, but that is not a DNS issue.

In Section 4.2, it says clients SHOULD NOT support the “port” key unless the

client trusts the server not to attempt an attack.

That's one option.  The other options are (2) if you know you're not on a network with insecure devices behind a firewall or (3) if you apply port number restrictions that you believe are sufficient to prevent any
 confusion.

Is there any way to verify

this? It sounds like this behavior would need to be configured for individual

servers and not in general.

Yes: "do you trust this server not to try to attack other devices on your network?" is a question whose answer cannot be automated.

I get (3). My main concern is an implementer of a client determining client behavior when a port key is seen in a response RR.  “Trust” can be interpreted in various ways, so clients may react differently. I don’t know if that will really
 be an issue for the client except for certain attacks but then there are larger issues at that point. Since it is only the client side case and it is already SHOULD NOT, I don’t know how big of an issue this actually is.  Wouldn’t be an issue most of the time.

In Section 5, the text states: “Clients SHOULD NOT query for any HTTPS RRs…”

Maybe that should be a MUST NOT?

Sending an HTTPS query is useless but also harmless, so I think "MUST NOT" would be too strong.

Is there a reason why a client would send a

query for type HTTPS rather than SVCB? Like if the SVCB query returned a

response saying the RRType does not exist?

The text documents one reason: "if clients might learn about this DoH service through a different channel".  If the client is provisioned with a complete DoH URI template, this draft doesn't apply, but the HTTPS
 record draft does.

I can also imagine cases where the HTTP client implementation used for DoH is extremely high-level, and performs its own HTTPS queries.

Ok, I get that. 

Section 8.1.2, the text says: “If an endpoint sends an invalid response to a

DNS query, the client SHOULD NOT send more queries to that endpoint.”  That

refines what is in RFC 8484, which is rather open ended.  I don’t know if this

rises to the need for this document to update RFC 8484, since the text there

implies retry or try another DoH server but RFC 8484 does not state that a

client SHOULD NOT retry to the same server. Maybe just mention that this

refines the behavior in RFC 8484 for SVCB aware clients?

This section is not limited to DoH; it applies to all transports.  RFC 8484 assumes that the DoH URI template is provisioned securely, so this mitigation would not be relevant.

Ok.

I understand the other minor wording changes/clarifications so snipped.

Scott

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call