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

[Ted Lemon <[e-mail]>]

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!