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

[Ted Lemon <[e-mail]>]

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.

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