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

[Ted Lemon <[e-mail]>]

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

> 1) Other service record types
>
> If we allow SRV records, then we should probably also support this
> for the newer types of service records, eg SVCB and HTTPS, as long
> as the same constraints are there (eg only pointing to itself)
>

This is a really good question, which the working group hasn't considered
At All. :)

I think I like this as an idea, but it also feels like it's new work—that
is, it doesn't have to happen in this document, and in fact doing it in
this document would be really hard. For starters, I think we'd need to
update RFC6763 as well.

I'd also really like to think of some use cases that this would enable, so
if you have one or more use cases in mind, could you share them?

Bottom line, though, is that I think we should add this as a new work item
once we have some motivating use cases, rather than trying to cram it into
the SRP document at the last minute.


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

>
> 3) KEY rollovers?
>
> How does a SRP requestor do a KEY rollover without running a race
> condition that
> might lose its ownership of its name? Can it send a KEY update containing
> the
> future KEY signed with the current KEY? Should it be double signed to
> prove ownership
> of the future private key?
>

This is a really good question. The short answer is that nobody who
currently implements SRP does this, but that doesn't mean it's a bad idea.
It's actually a really good idea. I think it would have to be double
signed, as you suggest. I guess my question is, do we need to do this in
the current document, or can we do it as an update? The reason I ask is
that for the usual security model of SRP, this really isn't a big deal.
It's fine for the SRP requestor to just remove the old key and add a new
one, and it's unlikely that someone is going to jump in and put in a
different key. And there's always the risk that the device might fail to
renew for long enough that its key expires and some interloper comes along
and claims the name and whatever trust went along with it. But we don't
actually assign any trust value to the key other than "this is the key that
was previously used to add this name," so this is really only important if
we use the key for other reasons. And trusting the name registered with the
key is actually kind of a bad idea unless there's some trust establishment
process out of band, because FCFS just isn't any good for that.

What I'm getting to here is, is this something that needs to happen in this
document, or could it be a follow-on document? If we're going to do this,
I'd really like to think it through, and I don't think it's urgent.


> 4) SUDN
>
> Section 10.1 attempts to register a Special-Use domain without a template
> as per RFC 6761 Section 5.  Domain Name Reservation Considerations.
> (I'm aware of the irony of this wrt one of the authors of this document
> :-) ]
>

You mean section 8?


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

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


> 7) Too generic a name for in .arpa
>
>        the special-use domain name (see [RFC6761]) "default.service.arpa"
>
> Why aren't underscores used here to ensure the space is not considered
> a possible valid hostname? eg default._service.arpa or
> _default._service.arpa
> I would also think "service" is far too generic. Possibly "_dns-sd" would
> be
> better. "service.arpa" seems way to generic to be a reference for dns-sd
> only.
>

The working group consensus was to use default.service.arpa. All current
implementations use it. We could change it, but why? I don't see how adding
underscores makes it better. If someone thinks it's a hostname, what bad
result follows? To my eye, using underscores makes it look like
_default._dns-sd.arpa is a service, rather than a domain containing
services.


> 8) Possible replay security implications
>
> A DNS Update for "default.service.arpa" seen in one network could be
> replayed as
> a DNS Update in another network (even if one does not have the private
> key). I'm
> a bit concerned this could have security implications, eg of impersonating
> a device.
>

It's not clear to me how this would be a useful attack. Sure, you could add
a service, but it would probably have an IP address that couldn't be
reached, and if the key is being used as a basis of trust, that's going to
require that some application-layer protocol uses the key to sign
communications, which means that the attacker really has to have the
private as well as the public key.


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Why are there two different ways of removing content? One using a DNS
> Update
> DELETE command, and one using a DNS Update refresh with lease time of 0 ?
> Also,
> the notion of delete being a lease of 0 update should be specified in
> draft-ietf-dnssd-update-lease and maybe not in this document, especially as
> that draft currently states "SHOULD NOT" for lease values < 3600
>

I partially explained this in my response to your DISCUSS on the update
lease document. To your first question, the reason to have two mechanisms
is that SRP supports devices that may not have sufficient stable storage to
remember what was previously updated. Update Lease isn't targeting
constrained devices, so we aren't concerned about this for Update Lease.

Section 3.3.2:
>
>         A DNS Update that contains any additional adds or deletes that
>         cannot be identified as Service Discovery, Service Description
>         or Host Description Instructions is not an SRP Update.
>
> I think this means to say "So nothing from the entire DNS Update should be
> processed in the context of dns-sd srp" ? I think that point should be made
> more explicit.
>

I think we state this pretty explicitly here in the first paragraph of
section 3.3.2: An SRP registrar MAY either process such messages as regular
RFC2136 updates, including access control checks and constraint checks, if
supported, or MAY reject them with Refused RCODE. But you go on to
(correctly) criticize that text, so...


>         An SRP registrar MAY either process such messages as regular
>         RFC2136 updates, including access control checks and constraint
>         checks, if supported, or MAY reject them with Refused RCODE.
>
> I think processing as regular 2136 would fail, based on the fact that there
> would be no proper TSIG authentication in place. Unless it was not a
> dnsdsd-srp
> message at all, which again would be obvious for using TSIG and not SIG(0).
>

RFC 2136 requires neither TSIG nor SIG(0).


> But also, I don't know how to parse the construct of "MAY x or MAY y".
> Does the
> "or" imply I MUST do one of the MAYs? Or can both MAYs be skipped?
>

That's a good point (which I address below).

         An SRP registrar MAY either process such messages as regular
        RFC2136 updates, including access control checks and constraint
        checks, if supported. Otherwise it MUST reject them with Refused
RCODE.

        If the server fails to renew its service registration before the
>         KEY lease (Section 4 of [I-D.ietf-dnssd-update-lease]) expires,
>         its name is no longer protected.
>
> What does "no longer protected" mean? Does it mean the name remains active
> but anyone can claim it? Or does it mean the name is removed. From a
> security
> point of view, I think if KEY_LEASE < LEASE, LEASE should be reduced to
> KEY_LEASE.
>

 We are trying not to explicitly require that garbage collection happen
exactly at the moment the lease expires. But your point about the text is
right, and so I've made the following changes to address the above two
points:

   <t>An SRP Update MUST include an EDNS(0) Update Lease option
   <xref target="I-D.ietf-dnssd-update-lease"/>. The Lease time specified
in the Update Lease option MUST be less than
   or equal to the Key Lease time. A DNS update that does not include the
Update Lease option, or that includes a Key
   Lease shorter than the Lease, is not an SRP update.</t>
 <t>When an SRP registrar receives a DNS Update that is not an SRP update,
it MAY
   process the update as regular RFC2136 updates, including access control
checks and constraint
   checks, if supported. Otherwise the registrar MUST reject the DNS Update
with the Refused RCODE.</t>

section 3.2.5.1 states:
>
>         When the device changes ownership, it may be appropriate to erase
> the
>         old key pair and install a new one.
>
> I think it should remove the advise for "install a new one". The new owner
> couldn't trust the old owner knows the key, and would have to
> re-refactory-default the unit to get rid of the 'new' old key.
>

Hm, good point. The text there doesn't attribute agency to anyone in
particular, but does kind of imply that the key is removed by the same
entity or process that adds the new key, which is obviously not a good idea.

I've changed it as follows:

     When the device changes ownership, it may be appropriate
     for the former owner to erase the old key pair, which would then
require the new owner to install a new
     one. Therefore, the SRP requestor on the device SHOULD provide a
mechanism to erase the key, for example as the
     result of a "factory reset," and to generate a new key.


>        The policy described here for managing keys assumes that the
>         keys are only used for SRP. If a key that is used for SRP is also
>         used for other purposes, the policy described here is likely to
>         be insufficient.
>
> I think this should be much stronger, eg a "MUST NOT be used for anything
> else
> except SRP". Since the public key appears as KEY in DNS, it seems much too
> dangerous to allow this key to be used for anything else.
>

I'm not sure you're wrong about this, but I don't think the reason you've
given is a good one. TLSA seems like a counterexample, and for that matter
TLS itself, since you can get the TLS public key simply by making a TLS
connection to a server and asking for it, so IOW it's also published
publicly. So for instance for an IoT device, if the SRP key is the same key
that's used for TLS to the service being published, what new attacks are
possible? (AFAIK nobody is doing this—this is just an example I made up
since it seems like something someone might be tempted to do).


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

Section 6.3 could also advise adding "www", "mail" etc to the zone so that
> no
> SRP requesters can request it.
>

It could, yes. But current implementations don't do that, and the reason
they don't is that they are not updating domains where names like www, mail
and so on have useful special meanings. RFC6761 doesn't suggest that
mail.local be ignored. This is analogous. I don't think it's really a good
idea to use SRP to update a top-level zone that would have names like
"mail" and "www" in it.


> Section 6.6 states:
>
>         SRP registrars SHOULD implement the algorithms specified in
>         [RFC8624], Section 3.1, in the validation column of the table,
>         that are numbered 13 or higher and have a "MUST", "RECOMMENDED",
>         or "MAY" designation in the validation column of the table.
>
> There is a 8624bis that puts this properly into a registry, so hopefully
> this
> document could state something about RFC8624 and its successors instead of
> manually hacking column recommendations into the draft?
>

It's expired. Otherwise I think it's a good point. Are you concerned that
we excluded RSASHA256, or just that we did it the way we did?


>         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. :)


>         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"?

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

Thanks for the long and detailed review! I know it was a lot of work. It's
good to get a new review from a DNS expert after all this time. :)