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

[Ted Lemon <[e-mail]>]

This is the thing that confuses me. TCP is required for servers to
implement. DNS cookies are a performance hack for public-facing DNS
authoritative and caching servers. We have to implement TCP and support it.
DNS Cookies is therefore necessarily additional effort. I see why this
makes sense for an authoritative server or a DNS cache out on the internet,
but that use case is specifically excluded here (see section 6.1). So
implementing DNS Cookies as far as I can tell adds no value at all for this
use case.

Anyway, there's probably something I'm missing here, and as you say, we
might as well discuss it in Brisbane in the hallways.

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

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