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

[Paul Wouters <[e-mail]>]

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

Reluctantly okay.


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


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

Reluctantly okay :P


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

Ah yes. I thought I recalled a small template file that needed to be filled
in but I seem to misremember. Sorry about that.



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


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


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

While I don't agree with this, and believe that a WG consensus for an
unwise name is still valid to be called out in an IESG review, since I'm
the only AD that called it out, I'll let it go. Reluctantly.
I strongly believe "default.service" was a bad choice.


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

Yes, I have no current attack either. It just bugs me.


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

Ok


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

Ok.


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

Fine.


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


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

Fair.


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

Just the way you did it. I pinged dnsop chairs on this draft. I don't
remember why it is expired. I guess no changes then since there is no
better reference to use.


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


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

Same here.

Sorry I took a bit long to respond. Hopefully we can have a few quick back
and forths and move the document onwards.

Paul
Paul