Last Call Review of draft-ietf-dnssd-srp-20
review-ietf-dnssd-srp-20-secdir-lc-salazar-2023-06-12-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is: Ready with nits

Major Concerns: None

Minor Concerns: 1
6.  Security Considerations
        Although the method described in the '3.3.3. FCFS Name And Signature
        Validation' section seems a good improvement over mDNS security, I
        second what Anthony Somerset highlighted in the dnsdir review; that
        some text would be welcome about a domain/service potentially denying
        naming to other domains/services by "squatting".

Nits:

Section 3.1.1 Full-featured Hosts
   Since a default registration domain is a requirement for the Service
   Registration protocol to be discoverable on the local network using the
   mechanism in the draft, perhaps normative language is needed, i.e
   Full-featured hosts MUST be either configured manually with a registration
   domain, or capable of discovering the default registration domain as
   described in Section 11 of [RFC6763].
3.1.2.  Constrained Hosts
   "It is the responsibility of a Constrained-Node Network supporting SRP to
   provide one or more SRP registrar addresses.  It is the
   responsibility of the SRP registrar supporting a Constrained-Node
   Network to handle the updates appropriately."
   Similar to the observation for the previous section, stronger language is
   recommended here for setting clearer expectations of Constrained Hosts and
   the SRP registrar supporting them. s/updates may be accepted/updates MAY be
   accepted/ s/may be rewritten/MAY be rewritten/
3.2.1.  What to publish
   Text seems to be missing in
   "For any Service Instance Name ([RFC6763], Section 4.1), an SRV RR,
   one or more TXT RRs, and a KEY RR."
   s/In principle Service/In principle, Service/
   Similar to the wording in 3.3.2.  Valid SRP Update Requirements, I would
   suggest s/There is never more than one hostname in a single SRP update./Each
   SRP update MUST contain one single hostname./
3.2.4.  How to secure it
   s/what we describe here/the FCFS Naming method we propose/
   Text seems to be missing in "The goal
   is not to provide the level of security of a network managed by a
   skilled operator."
3.3.2.  Valid SRP Update Requirements
   The sentence "An SRP registrar MAY either
   process such messages are either processed as regular RFC2136
   updates" seems unclear.
6.  Security Considerations
   s/credentials to to update/credentials to update/

Other than these, I found the document easy to read and to follow, with good
use of highlights of related protocols and RFCs. Thank you for your work on
this draft.