Re: [dnssd] Review of draft-ietf-dnssd-srp-02

[Jonathan Hui <[e-mail]>]

Ted,

Thanks for working to resolve my comments! Responses below:

On Thu, Oct 29, 2020 at 9:27 AM Ted Lemon <[e-mail]> wrote:

> On Oct 8, 2020, at 3:19 PM, Jonathan Hui <
> jonhui=[e-mail]> wrote:
>
> Intended status: Informational
>>
>
> Why not standards track?
>
> Because I accidentally put “info” in the XML instead of “std”. :)
>

Draft-05 still indicates Informational.

> [RFC6763] that allows services to automatically register their
>
>
> It's not clear to me at this point what "automatic" really means. It
> becomes clear later in the doc (e.g. Section 2.6.1), but I think it would
> help to be clear in the Introduction.
>
> Thanks, this is a really good catch. I’ve substantially updated the
> introduction to explain this in more detail.
>

The additional 4.5 paragraphs of text in the introduction looks great and
the detail is certainly helpful.

> using UDP unless TCP is required due to the size of the update.  It
>> is the responsibility of a Constrained-Node Network supporting SRP to
>> provide appropriate anycast routing to deliver the DNS updates to the
>> appropriate server.  It is the responsibility of the SRP server
>>
>
> Is "appropriate" well-understood here? I could use some clarification on
> what requirements are placed on the Constrained-Node Network to support SRP
> anycast. For example, can there be more than one SRP server on the network?
> If so, does the anycast address always need to map to the same SRP server
> for a given host?
>
>
> Interesting, this was actually fixed in a newer version. So the whole
> discussion of how to configure SRP on “constrained-node networks” is now
> left up to the specification for that network type.
>

Somehow I reviewed an older draft. The latest text looks good to me!

> o  The Host Description records for a service are a KEY RR, used to
>>    claim exclusive ownership of the service registration, and one or
>>    more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of
>>    the host where the service resides.
>>
>
> Are there recommendations/thoughts on how an SRP server should handle SRP
> updates containing multiple IPv6 addresses of varying scopes? Is this a
> topic within scope of this document?
>
> I’ve added a paragraph to the validation section saying that link-scope
> and IPv4 autoconf addresses are invalid, and registrations that include
> them should be treated as invalid registrations.  I’ve also mentioned that
> addresses must be in scope for all potential clients of the SRP server, but
> haven’t explained this in more detail. I may add a section about this later.
>

Updated text looks good to me.

> The service generates a public/private key pair.  This key pair MUST
>> be stored in stable storage; if there is no writable stable storage
>> on the client, the client MUST be pre-configured with a public/
>> private key pair in read-only storage that can be used.  This key
>> pair MUST be unique to the device.
>>
>
> Strictly speaking, we require the service to retain the key pair for as
> long as it would like to make updates to its existing service information.
> For example, should we recommend that a device generate a new key pair
> after factory reset (if it has the ability to do that)? I'm thinking that
> the public key can serve as a static identifier.
>
> Yes, that’s intended.  I’ve added some text.
>

Updated text looks good to me.

> lease time Section 2.6.1.  Shorter TTLs will result in more frequent
>> data refreshes; this increases latency on the client side, and
>> increases load on any caching resolvers and on the authoritative
>> server.  Longer TTLs will increase the likelihood that data in caches
>
>
> Worth mentioning effect on network utilization? Or is that already implied?
>
> OK.  I added text.
>

Typo: "be an + issue for" -> "be an issue for"

Otherwise, the updated text looks good.

> 4. Privacy Considerations
>
>
> Should we mention UDP here?
>
> Dunno what you mean about this.
>

The current text recommends using TLS when using TCP to mitigate privacy
concerns. Are there any recommendations or warnings to state here when host
implementations are using UDP?

> Should we mention the public key here?
>
> I’ve added some text. I think we may also want to allow the client to say
> “don’t show my key.”
>

Updated text looks good. Giving the client that flexibility sounds
interesting.

> specification in [RFC8375]Section 7.
>
>
> "Section 7" link not pointing to the appropriate doc.
>
> I’m not following this.
>

The "Section 7" link in
https://tools.ietf.org/html/draft-ietf-dnssd-srp-05 points
to https://tools.ietf.org/html/draft-ietf-dnssd-srp-05#section-7.

Thanks!

--
Jonathan Hui