Reviewer: Joey Salazar Review result: Has Nits 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
