Skip to main content

Telechat Review of draft-ietf-dnssd-srp-23

Request Review of draft-ietf-dnssd-srp
Requested revision No specific revision (document currently at 25)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2023-08-08
Requested 2023-07-11
Authors Ted Lemon , Stuart Cheshire
I-D last updated 2023-08-08
Completed reviews Dnsdir Telechat review of -23 by Anthony Somerset (diff)
Dnsdir Last Call review of -20 by Anthony Somerset (diff)
Artart Last Call review of -20 by Patrik Fältström (diff)
Secdir Last Call review of -20 by Joey Salazar (diff)
Opsdir Last Call review of -20 by Dhruv Dhody (diff)
Tsvart Last Call review of -20 by Joerg Ott (diff)
Dnsdir Telechat review of -22 by Anthony Somerset (diff)
Iotdir Telechat review of -22 by Christian Amsüss (diff)
Intdir Telechat review of -22 by Jean-Michel Combes (diff)
Secdir Telechat review of -23 by Joey Salazar (diff)
Assignment Reviewer Joey Salazar
State Completed
Request Telechat review on draft-ietf-dnssd-srp by Security Area Directorate Assigned
Posted at
Reviewed revision 23 (document currently at 25)
Result Has nits
Completed 2023-08-08
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


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.