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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-dnssd-srp-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Joey Salazar for the SECDIR review.

Authors: Thank you for editorial style that provided introductory prose on the
protocol design before discussing the protocol itself.

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

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

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

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

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

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

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

** 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/

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

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