Re: [dnssd] Paul Wouters' Discuss on draft-ietf-dnssd-srp-23: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

On Mar 4, 2024, at 13:16, Ted Lemon <[e-mail]> wrote:



You're right, with server policy 2 cookies would protect against spoofing.

I guess one way to think about this is that we could face a DoS attack where we're being forced to validate a lot of bogus signatures and the TCP connection wouldn't protect against that if it's a DDoS attack from real reachable hosts? Is that why you're interested in this? It's the only reason I can think of to consider doing it—otherwise it's needless complexity.

No. I am interested because going from UDP to TCP is more resource heavy and complicated than enabling DNS COOKIES for UDP, while both offer equivalent anti-spoofing behaviour. Enabling DNS COOKIES when under attack is also cheaper than enabling TCP. Plus TCP runs additional firewalling risks.

But I didn’t say you cannot do TCP. I just asked you change “TCP” to “TCP or UDP DNS  COOKIES”, except I used the term “source validated transport” that includes both of these and potentially also meaning DoT, DoH or DoQ if that would get deployed.

Paul

On Mon, Mar 4, 2024 at 12:47 PM Paul Wouters <[e-mail]> wrote:

On Mon, Mar 4, 2024 at 11:30 AM Ted Lemon <[e-mail]> wrote:

Paul, first of all in no way should you take this message as a request for immediate attention—I know an AD's life in the run-up to IETF is very busy. So it's perfectly fine if you don't deal with this until after IETF.

I was hoping that you'd have time to respond to my previous note so that we could negotiate on changes, but since you didn't have time, I'm making my best attempt at addressing the remaining open issues prior to today's draft submission cutoff in hopes that you'll be satisfied with the changes.

I hadn't had time to formulate my response but I had some disagreements or else I would have signaled ok :)

 

Regarding SRV target compression, I've made the following update:

              Although <xref target="RFC2782"/> requires that the target name in the SRV record not be compressed, an SRP requestor
-             SHOULD compress the target in the SRV record. The motivation for <em>not</em> compressing in <xref target="RFC2782"/>
+             MAY compress the target in the SRV record. The motivation for <em>not</em> compressing in <xref target="RFC2782"/>

+           <t>

+             Note that this does not update <xref target="RFC2782"/>: DNS servers still MUST NOT compress SRV record targets. The
+             requirement to accept compressed SRV records in updates only applies to SRP registrars, and SRP registrars that are
+             also DNS servers still MUST NOT compress SRV record targets in DNS responses. We note also that
+             <xref target="RFC6762"/> recomments that SRV records be compressed in mDNS messages, so <xref target="RFC2782"/> does
+             not apply to mDNS messages.</t>
+           <t>
+             In addition, we note that an implementor of an SRP requestor might update existing code that creates SRV records
+             or compresses DNS messages so that it compresses the target of an SRV record. Care must be taken if such code is
+             used both in requestors and in DNS servers that the code only compresses in the case where a requestor is generating
+             an SRP update.</t>

this looks great. Thanks.

 

I don't think we need to say "SHOULD" for compression since it's not an interop issue; the only interop issue is that if we let the SRP requestor compress, then we have to require that SRP registrars correctly handle compressed SRV targets. I hope the extra two paragraphs address the concern that this might pollute other DNS implementations.

Regarding DNSSEC validation, I wasn't satisfied with the previous edit I made to the text about recursive resolvers, so I made the following change:

-         <li>Recursive resolvers at sites using 'service.arpa.'  MUST transparently support DNSSEC queries: queries for DNSSEC
-            records and queries with the DNSSEC OK (DO) bit set (<xref target="RFC4035" section="3.2.1" sectionFormat="of"/>).
-            While validation is not required, it is strongly encouraged: a caching recursive resolver that does not validate answers
-            that can be validated may cache invalid data.  This, in turn, will prevent validating stub resolvers from successfully
-            validating answers. We can't place normative requirements on DNS recursive resolvers, but we remind implementors that
-            DNSSEC validation is a Best Current Practice <xref target="RFC9364"/>.</li>
+         <li>For correctness, recursive resolvers at sites using 'service.arpa.' must in practice transparently support DNSSEC
+            queries: queries for DNSSEC records and queries with the DNSSEC OK (DO) bit set (<xref target="RFC4035" section="3.2.1"
+            sectionFormat="of"/>).  DNSSEC validation is a Best Current Practice <xref target="RFC9364"/>: although validation is
+            not required, a caching recursive resolver that does not validate answers that can be validated may cache invalid data.
+            This, in turn, would prevent validating stub resolvers from successfully validating answers. Hence, as a practical
+            matter, recursive resolvers at sites using 'service.arpa' should do DNSSEC validation.</li>

This is a change to the previous proposed change, but I think it stands by itself. The goal here is to make it clear that we really want recursive resolvers to validate, and that there's a BCP that says they should, and also motivate why regardless of SHOULDs and MUSTs, sites that use service.arpa really have to do DNSSEC correctly.

This also looks great.

 

I haven't done an update to address the question about DNS cookies because it still doesn't make sense to me. I don't think there's a problem to solve here—there's no downside to using TCP transport for SRP updates as far as I can tell, and cookies doesn't actually solve the problem of source address validation.

I'm not sure why you don't see that TCP and DNS COOKIES offer the same guarantees on source address validation?

You can push out these changes, and perhaps at IETF we can chat about COOKIES?

Paul

 

On Tue, Feb 27, 2024 at 5:03 PM Ted Lemon <[e-mail]> wrote:

Thanks for getting back to me, Paul. I know the response was a long time coming and it's always extra work to get back up to speed after a big time gap.

I'm going to respond to the points on which there remains disagreement and leave the rest out.

On Fri, Feb 23, 2024 at 4:15 PM Paul Wouters <[e-mail]> wrote:

On Wed, Aug 9, 2023 at 7:59 PM Ted Lemon <[e-mail]> wrote:

On Wed, Aug 9, 2023 at 5:49 PM Paul Wouters via Datatracker <[e-mail]> wrote:

2) finding the domain name to use

In Section 3.2.2 on where to publish, hosts need to somehow know their
domain name. Especially for roaming devices, this seems unlikely and
the only choice to participate would be to assume the name given by
DHCP for the 'search domain'. I feel that by not stating this explicitly,
that is what is going to happen anyway. So why not state it? Or if this
is really unwanted, add such a statement to Section 3.2.2.

RFC 6763 actually includes information on how to figure this out, in section 11. This is discussed in detail in sections 3.1.1 and 3.1.2. Maybe it would be worth adding a pointer to that here? 

Thanks. That does explain it. I'll leave it up to you to add a pointer or not.

I've added:

   As described above, full-featured devices are responsible for knowing the domain in which to register their services.
   Such devices MAY optionally support configuration of a registration domain by the operator of the device. However,
   such devices MUST support registration domain discovery as described in <xref target="RFC6763" section="11" sectionFormat="of"/>,
   "Discovery of Browsing and Registration Domains".

  

5) Basically Updates: 2782 without saying so

Section  3.2.5.4 Compression in SRV records basically updates RFC 2782 without
stating so via an Updates: clause. As we are talking about DNS library code reuse,
I think this would be unwise to update. I would drop the option of allowing the
compressing of SRV target names.

I don't agree that this updates RFC 2782. Only SRP registrars are required to support this. We are not saying that DNS authoritative servers need to support this (or indeed that they should do it) nor are we saying that DNS caching resolvers need to support this when parsing answers to queries sent to authoritative servers or that they should do it when sending responses to clients. The only case where this is required is when parsing SRP updates. Would it help to say that more explicitly? I thought we were clear on this, but I don't mind being even clearer if you think it's necessary.

My focus here is on DNS library code being re-used and affected. Is packet size really such a big issue on a LAN that you say SHOULD for compression? If this was a MAY I would be happier,

as using a stock dns library would not cause breaking a SHOULD clause.

The problem is that it's no use if the server isn't required to support it. I see your point about libraries—we don't want to accidentally cause some DNS server to start sending SRV responses to regular DNS queries where the target is compressed. However, this feels like it's kind of our of our control. I can add some text here reminding implementors to avoid this mistake if you think it would help. I agree that this is problematic, but if you think about an 802.15.4 network with a frame size of 127 bytes, the extra bytes we're saving here really do matter at least in principal.

6) DNSSEC on resolvers

Section 8.4 point 1 is true for all recursive resolvers and I think it is harmful
to call it out here as if it is still acceptable to run resolvers without DNSSEC
enabled. I would remove the entire point 1.

Hm. The thing is, the resolvers we're talking about here are home router resolvers, and I don't know of any home routers other than those sold by cz.nic that actually support this.

dnsmasq supports DNSSEC and I believe that is the most common dns resolver on routers ?

 

So from my POV we are making things better with this text. If we /require/ this, I think our requirement will be ignored, but maybe not. I think we would have to ask the working group whether there is consensus to require it. I don't want to delete it because I think we're missing an opportunity if we don't at least encourage this.

You can change the text to instead reference RFC9364 which states DNSSEC is BCP.

 I've updated the text as follows:

   <li>Recursive resolvers at sites using 'service.arpa.'  MUST transparently support DNSSEC queries: queries for DNSSEC
            records and queries with the DNSSEC OK (DO) bit set (<xref target="RFC4035" section="3.2.1" sectionFormat="of"/>).
            While validation is not required, it is strongly encouraged: a caching recursive resolver that does not validate answers
            that can be validated may cache invalid data.  This, in turn, will prevent validating stub resolvers from successfully
            validating answers. We can't place normative requirements on DNS recursive resolvers, but we remind implementors that
            DNSSEC validation is a Best Current Practice <xref target="RFC9364"/>.</li>

I'm not convinced that this satisfies your request, but it doesn't really make sense to put normative language in here—we're simply documenting the implications of this special-use domain, but it's up to operators to decide whether or not they care. So I don't know what else we should say here. I'm reluctant not to document the issue. I mean, granted, I used MUST in the first sentence, but I'm feeling a bit weird about that now that we're discussing it here.

 

       To prevent such spoofing, TCP is required for such networks.

It should say "source validated connections, such as TCP or UDP with COOKIES"
(same later on in section 6.1) and normatively reference RFC 7873. Constrained
devices could also use UDP with COOKIES.

We didn't consider cookies. I don't think it's particularly useful since it doesn't validate the first registration. That's why we recommend explicit source validation for the UDP case.

I don't understand this answer. If you want spoofing protection, TCP is only one option. My rephrasing makes it more general, and implementers can decided which option to pick.
You can still keep using TCP. Others could do DNS COOKIES. Currently, you text "requires" to use TCP, which I believe is wrong.

I don't see how DNS cookies help. This is a simple request/response, and cookies only help on the second request. Am I misunderstanding? The reason TCP works is that there's a three-way handshake before we even send the DNS Update.

 

 

        In other network environments, updates for names ending in
        "default.service.arpa" may be rewritten by the registrar to
        names with broader visibility.

Can we avoid the use of "registrar" to avoid confusion with Registrar,
which in DNS speak usually refers to a domain registrar? How about using
"network authority" ? Or consistently use "SRP registrar". (see also the
use of "registrar" in section 3.3.6, 5.1, 6.1, 7)

Oh, good point. I think "SRP registrar" makes more sense than "network authority," plus I'd like to avoid confusing "authority" and "registrar" for the same reason you want to avoid confusing SRP registrars and domain registrars. :)

This wasn't done in the latest version yet.

There are a lot of cases in the document where we say SRP registrar once in a paragraph, and then just registrar thereafter. I can fix these, but then we wind up with text like this:

This means that if an attacker from outside of the administrative
 domain of the SRP registrar knows the SRP registrar's IP address, it can in principle send updates to the SRP registrar
 that will be processed successfully.   SRP registrars SHOULD therefore be configured to reject updates

 from source addresses outside of the administrative domain of the SRP registrar.</t>

This seems unnecessary. Are you concerned about these cases? I do see a few cases where we just use registrar and not SRP registrar throughout a paragraph, so I could fix those without fixing all the others. I don't mind either way, but the exhaustive approach feels like it makes the document harder to read, not easier.

 

 

        In this case, the requestor MUST either abandon the service
        registration attempt, or else choose a new name.

The word "attempt" should be removed here. It is the registration that is
aborted entirely, not just this attempt (or else try a new registration with
a different name)

Hm, okay. How about "In this case, the requestor MUST choose a new name or give up"? 

I've made this change.

 

        If the key lease time

Should be: if the KEY lease time

Hm, we actually only use "KEY lease" once. Everywhere else we say "Key lease." I don't see a strong reason to use all caps, but we could if you think it's important. We should definitely be consistent.

Same here.

I went with "KEY lease". Even the capitalization of "lease" was inconsistent. :)

 

Sorry I took a bit long to respond. Hopefully we can have a few quick back and forths and move the document onwards.

I think the delay is my fault, so no worries. Thanks for getting back to us on this!