Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-srp-23

[Ted Lemon <[e-mail]>]

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:

 The reason for this is precisely that we have not established trust. So we
can only publish information that we feel safe in
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:

 The reason for this is precisely that we have not established trust. So we
can only publish information that we feel safe in
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:

      The policy described here for managing keys assumes that the keys are
    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!