Joey, thanks for this review, and apologies for the very late response.
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..."
It took me a bit of head scratching to figure out what you meant here. I've changed:
publishing even though we do not have any basis for trusting the requestor. We reason that mDNS <xref target="RFC6762"/>
allows arbitrary hosts on a single IP link to advertise services <xref target="RFC6763"/>, relying on whatever service is
advertised to provide authentication
to:
publishing even though we do not have any basis for trusting the requestor. We reason that mDNS <xref target="RFC6762"/>
allows arbitrary hosts on a single IP link to advertise services <xref target="RFC6763"/>, relying on whatever service is
advertised to provide authentication as a part of its protocol rather than in the service advertisement.
To make it clear that the authentication being described is not being provided by mDNS or SRP.
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.
This is discussed in -23 here:
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. The policy stated here should not be applied in such a
situation: a policy appropriate to the full set of uses for the key
must be chosen. Specifying such a policy is out of scope for this
document.
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.
Thanks!
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
