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

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-dnssd-srp-23: 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:
----------------------------------------------------------------------

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)

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.

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?

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

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.

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.

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.

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.


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

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.

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

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?

        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.

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

       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.

       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.

Section 6.3 could also advise adding "www", "mail" etc to the zone so that no
SRP requesters can request 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?

        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)

        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)

        If the key lease time

Should be: if the KEY lease time