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

[Ted Lemon <[e-mail]>]

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.

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"/>
              is not stated, but is assumed to be because a caching
resolver that does not understand the format of the SRV record
              might store it as binary data and thus return an invalid
pointer in response to a query. This does not apply in the
              case of SRP: an SRP registrar needs to understand SRV records
in order to validate the SRP Update. Compression of the
              target can save space in the SRP Update, so we want clients
to be able to assume that the registrar will handle
              this. Therefore, SRP registrars MUST support compression of
SRV RR targets.</t>
+           <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>

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.

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.

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!
>
>