Telechat Review of draft-ietf-dnssd-srp-23
review-ietf-dnssd-srp-23-secdir-telechat-salazar-2023-08-08-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.

Please note that I previously reviewed version 20 of this draft and at that
time stated that the document was "Ready with Nits/Has Nits"

I am therefore only reviewing the differences between version 20 and current
version (23)

The summary of the review is: Ready with nits

Major Concerns: None

Minor Concerns: None
The minor concern highlighted in the previous review has been addressed with
the text added to 6.3.  Risks of allowing arbitrary names to be registered in
SRP updates

Nits:

1.  Introduction
The mention of authentication in mDNS might be confusing, perhaps something
along the lines "In this regard, our goal with this specification is
   to impose similar constraints to mDNS [RFC6762], which allows arbitrary
   hosts on a single IP link to advertise services [RFC6763] and relies on
   whatever service is advertised to provide authentication. This pratice in
   mDNS is considered reasonably safe because it requires physical presence on
   the network in order to advertise, with an off-network mDNS attack simply
   being not possible. Because of this you will see..."

Alternatively, shorter text in the introduction section might make the text
more concise, with these new paragraphs explaining the reasoning either in
Section 3.3.3 FCFS Name And Signature Validation or a subsection of its own.
The shorter text could be along the lines "Section x explains the reasoning for
a limited/constrained authentication scope in this protocol"

6.  Security Considerations
Even though specifying key management policies is out of scope, perhaps it
could be worthwhile to add a short mention that "If a key that is used for SRP
is also used for
   other purposes" it could represent a vulnerability.

Other than these remarks, I continue to find the document easy to read and to
follow, with good use of highlights of related protocols and RFCs.

Thank you for your work.