Re: [dnssd] Roman Danyliw's Discuss on draft-ietf-dnssd-srp-22: (with DISCUSS and COMMENT)

[Ted Lemon <[e-mail]>]

On Wed, Jul 12, 2023 at 6:44 AM Roman Danyliw via Datatracker <
[e-mail]> wrote:

> ** Documenting the risk of malicious, internal clients
>
> -- Section 1.
>
>    This is considered reasonably safe because it requires physical
>    presence on the network in order to advertise.
>
> -- Section 6.1.
>    SRP Updates have no authorization semantics other than FCFS.  This
>    means that if an attacker from outside of the administrative domain
>    of the registrar knows the registrar's IP address, it can in
>    principle send updates to the registrar that will be processed
>    successfully.
>
> The Security Considerations and introductory framing go to great lengths to
> helpfully describe the risk of malicious registrations from outside of the
> administrative domain.  However, I am unable to find any discussion of the
> risks malicious clients inside the administrative domain pose.  Is this a
> perimeter-based security model (trust everything once insider the
> network)?
> After initial compromise, a compromised system could register information
> that
> would support the steering of traffic to servers controlled by this
> attacker.
>
> I scanned how RFC6763, RFC3007, RFC2136 and RFC2137 handle it.  As an
> aside,
> note that none of their Security Considerations are said to be applicable.
> Section 5 of RFC2137 reminds us that dynamically configured domains are
> inherently less secure. Section 8.1 of RFC2136 comes closest with a
> mitigation
> of using IPsec, but it isn’t clear that is desired here.
>

The security model is explicitly discussed in Section  3.2.4, "How to
Secure It." We explicitly address your question in the second paragraph:

The goal of securing the DNS‑SD Registration Protocol is to provide the
best possible security given the constraint that service registration has
to be automatic. It is possible to layer more operational security on top
of what we describe here, but FCFS naming is already an improvement over
the security of mDNS.

The reality is that service registration is similar to things like router
advertisements. If I can send a router advertisement on the local network,
I can tell you what DNS resolver to use, and thereby advertise services to
you with no authentication at all. I can do the same with mDNS.
Fundamentally, what allows a device to advertise services on the network is
that the user connected the device to the network, and the network isn't
blocking traffic that would serve to advertise such services. There are
interesting problems to solve in the "add devices to the network" space,
but that's outside the scope of this document and indeed outside of the
charter of the working group. Fundamentally what we wanted here was an
improvement over the status quo ante, and I believe that's what we have.

It looks like section 6.1, "Source validation" actually talks about some of
the other risks in the area that you're concerned about, and that may have
been less obvious because of the too-narrow section heading. I've made the
following clarifications in the security considerations section which I
hope address this:

@@ -771,6 +771,9 @@
          on routers <xref target="RFC2827"/>. This would ordinarily be
accomplished by measures such as are described in
          <xref target="RFC7084" section="4.5" sectionFormat="of"/></t>

+      </section>
+      <section>
+       <name>Other DNS updates</name>
        <t>Note that these rules only apply to the validation of SRP
Updates.
          A server that accepts updates from SRP
          requestors may also accept other DNS updates, and those DNS
updates may be validated
@@ -783,7 +786,9 @@
          the service registration information with information provided by
an authenticated DNS update requestor.  An implementation
          that allows both kinds of updates should not allow DNS Update
requestors that are using different authentication and
          authorization credentials to update records added by SRP
requestors.</t>
-
+      </section>
+      <section>
+       <name>Risks of allowing arbitrary names to be registered in SRP
updates</name>
        <t>It is possible to set up SRP updates for a zone that is used for
non-DNSSD services. For example, imagine that you set
          up SRP service for example.com. SRP hosts can now register names
like "www" or "mail" or "smtp" in this domain. In addition,
          SRP updates using FCFS naming can insert names that are obscene
or offensive into the zone. There is no simple solution to
@@ -799,6 +804,18 @@
            names are generally available, or can be constructed
manually.</li>
        </ul>
       </section>
+      <section>
+       <name>Security of local service discovery</name>
+       <t>Local links can be protected by managed services such as RA
Guard <xref target="RFC6105"/>, but multicast services like
+         DHCP <xref target="RFC21321"/>, DHCPv6 <xref target="RFC8415"/>
and IPv6 Neighbor Discovery <xref target="RFC4861"/> are
+         most commonly unauthenticated and can't be controlled on
unmanaged networks, such as home networks and small-office
+         networks where no network management staff are present. In such
situations, an SRP service is actually more limited in
+         terms of security risks. This is discussed in more detail in
<xref target="how-to-secure"/>. The fundamental protection
+         for networks of this type is the user's choice of what devices to
add to the network. Work is being done in other
+         working groups and standards bodies to improve the state of the
art for network on-boarding and device isolation (e.g.,
+         <xref target="RFC8520"/> provides a means for constraining what
behaviors are allowed for a device in an automatic way),
+         but such work is out of scope for this document.</t>
+      </section>


** Section 1.
>    So we can only publish information that we feel safe in publishing
>    even though we do not have any basis for trusting the requestor.
>
> What is the basis of considering particular information “safe”?
>

The reasoning is explained here:

We reason that mDNS [RFC6762] allows arbitrary hosts on a single IP link to
advertise services [RFC6763], relying on whatever service is advertised to
provide authentication.

This is considered reasonably safe because it requires physical presence on
the network in order to advertise. An off-network mDNS attack is simply not
possible. Our goal with this specification is to impose similar
constraints. Because of this you will see in Section 3.3.1 that a very
restricted set of records with a very restricted set of relationships are
allowed. You will also see in Section 6.1 that we give advice on how to
prevent off-network attacks.


 Perhaps you are objecting to the word "safe," and I can't really say you
are wrong to so object, but what we mean by "safe" here is "we aren't
making things worse, and actually are making things a bit better."

** Section 3.1.2.  Editorial
>    ... the (proposed) special-
>    use domain name (see [RFC6761]) "default.service.arpa" is used.
>
> Remove “(proposed)” as this will be approved by the time the document is
> an RFC.
>

OK


> ** Section 3.1.2
>    In
>    other network environments, updates for names ending in
>    "default.service.arpa" may be rewritten internally to names with
>    broader visibility.
>
> How would a constrained client know which names in default.services.arpa to
> rewrite and which ones it should not?
>

Proposed fix:

-            visibility.  In other network environments, updates for names
ending in "default.service.arpa" may be rewritten internally
+            visibility.  In other network environments, updates for names
ending in "default.service.arpa" may be rewritten by the registrar


> ** Section 3.1
> Networks that are not constrained networks can have more complicated
>    topologies at the IP layer.
> ...
>
>    This creates the possibility of off-
>    network spoofing, where a device from a foreign network registers a
>    service on the local network in order to attack devices on the local
>    network.  To prevent such spoofing, TCP is required for such
>    networks.
>
> -- Is a registrar supposed to reject UDP based traffic when it thinks it is
> operating in a non-constrained environment?

-- Is it possible to for unconstrained and constrained nodes to use the same
> registrar?  If so, how would the registrar know the node type per each
> request
> (so it could reject UDP)?
>

I've updated the relevant paragraph as follows:

        <t>For UDP updates from constrained devices, spoofing would have to
be prevented with appropriate source address filtration
          on routers <xref target="RFC2827"/>. This would ordinarily be
accomplished by measures such as are described in
-         <xref target="RFC7084" section="4.5" sectionFormat="of"/></t>
-
+         <xref target="RFC7084" section="4.5" sectionFormat="of"/>. For
example, a stub router <xref target="draft-ietf-snac-simple"/>
+         for a constrained network might only accept UDP updates from
source addresses known to be on-link on that stub network, and might
+         further validate that the UDP update was actually received on the
stub network interface and not the interface connected to
+         the adjacent infrastructure link.</t>


** Section 3.2.4.1
>    a server that registers its service using DNS-SD Registration
>    protocol is given ownership of a name for an extended period of time
>    based on the key used to authenticate the DNS Update.
>
> Is it the key, or the lease lifetime requested when “registering” the key?
>

Oh, hah. This is a bare key, so it doesn't have a lifetime associated with
it, but this is probably worth clarifying! :)

Changed it to:

              First-Come First-Serve naming provides a limited degree of
security: a server that registers its service using
              DNS&nbhy;SD Registration protocol is given ownership of a
name for an extended period of time based on a lease
              specific to the key used to authenticate the DNS Update,
which may be longer than the lease associated with the
              registered records.

** Section 3.2.5.1
>    if there is no
>    writable stable storage on the SRP requestor, the SRP requestor MUST
>    be pre-configured with a public/private key pair in read-only storage
>    that can be used.  This key pair MUST be unique to the device.  A
>    device with rewritable storage should retain this key indefinitely.
>    When the device changes ownership, it may be appropriate to erase the
>    old key pair and install a new one.
>
> Thanks for discussing the issues around key management.
>
> -- In the case of compromised device with read-write storage, it seems
> like the
> key MUST be regenerated.
>
> -- What is the proposed behavior for a compromised device with read-only
> storage?
>
> -- In what cases would it NOT be appropriate to erase the key when the
> device
> changes ownership?
>

The document doesn't really talk about what to do when the device is
compromised. FWIW, these keys in their use in SRP aren't controlling
anything very dire. If you transfer the device to a new owner, the new
owner could only abuse the key by gaining access to the network to which it
was formerly connected and register it under the same key, or use the key
to register some other service on the network. Given that the trust
relationship for the device is out of scope for this document, I think that
more detail on this concern is also out of scope. My expectation is that a
commissioning protocol/process would take care of this sort of thing.

I would be worried if this key were being used for authenticating something
other than SRP updates, however, so I've added the following:

    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. The policy stated here should
     not be applied in such a situation: a policy appropriate to the full
set of uses for the key must be chosen. Specifying
     such a policy is out of scope for this document.</t>


> ** Section 3.2.5.*  It appears field experience of some kind if being cited
> (with the use of “typically”).  Can it be cited?  Is this typical behavior
> recommended?
>
> -- Section 3.2.5.2: “There is no specific requirement for how this is
> done;
> typically, however, the requestor will append a number to the  referred
> name.“
>
> -- Section 3.2.5.3: “The lifetime of the DNS-SD PTR, SRV, A, AAAA and TXT
> records [RFC6763] uses the LEASE field of the Update Lease option, and is
> typically set to two hours.”
>
> Is this 2 hour lease time a recommended or default value?
>
> -- Section 3.2.5.3: “The lifetime of the KEY records is set using the
> KEY-LEASE
> field of the Update Lease Option, and should be set to a much longer time,
> typically 14 days.”
>
> Is 14 days a recommended value?



> Section 5.1 later says “A default limit of two hours for the Lease and 14
> days
> for the SIG(0) KEY are currently thought to be good choices.”
>

This spec defines a mechanism. Defining policies is out of scope. The
reason we were so vague is that we do not feel qualified to be less vague.
How implementations determine key lifetimes is likely to be dependent on
the context. For example, what is the "recommended" TTL for a DNS AAAA
record? I can give you some examples of how it is typically used, but I
don't think that adds value here—it feels like it would just be confusing.


> ** Section 6.1
>    Registrars should therefore be configured to reject
>    updates from source addresses outside of the administrative domain of
>    the registrar.
>
> What are the circumstances under which registrars would not reject updates
> outside of the administrative domain?  Why isn’t s/should therefore be
> configured/MUST be configured/
>

Again, you're asking us to make definite policy statements. The reason we
say "should" here is that we expect the implementor and/or operator to
follow the recommendations we have given unless they have some good reason
not to.


> ** Section 6.1
>    This would ordinarily be accomplished by measures such as
>    are described in Section 4.5 of [RFC7084]
>
> Is there IPv4 guidance?  This reference only discusses IPv6 routers.
>

The section we are referencing here points to BCP 38, which covers IPv4 and
IPv6, so I think we're okay here.


> ** Section 8.2
>    It is not possible
>    to register a PKI certificate for a subdomain of 'service.arpa.'
>    because it is a locally-served domain name.
>
> Is this saying that one couldn’t get a PKI certificate from a public CA
> (as in,
> for the Web PKI/CAB Forum-compliant CA)?  Couldn’t an administrative domain
> running its own CA to issue certificates with these names, especially since
> this shouldn’t be an internet exposed service.
>

That won't work, because the name isn't globally unique. As a device roams
from one administrative domain to another, things will work in exactly one
such domain if such a CA is being operated. This is way, way out of scope.
The only reason we're talking about this here is because IANA insisted that
we add this text. If it were up to me we'd delete most of this section. We
aren't forbidding something here that we ought not to forbid: an
administrative domain that wants to have PKI on an internal domain should
use an internal domain that is part of the global namespace (e.g.
silicon-valley.example.com, for a company whose public domain name is
example.com). They should not use a name that is not globally unique.

Anyway, thanks for the review! I hope these proposed changes and responses
sufficiently address your concerns. Was nice to talk to you f2f in San
Francisco! :)