Subject: Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-edns-client-subnet-06: (with COMMENT)

From: Dave Lawrence <[email-masked]>
Date: Thu, 25 Feb 2016 00:22:40 -0500

Alissa Cooper writes:
> I support Stephen's DISCUSS point. My assumption in reading the
> recommendation is that all recursive resolvers are recommended to disable
> ECS by default.

Please confirm that this new paragraph at the end of the privacy
section, written in response to Stephen's message, addresses your
concerns as well:

   We recommend that the feature be turned off by default in all
   nameserver software, and that operators only enable it explicitly
   in those circumstances where it provides a clear benefit for their
   clients.  We also encourage the deployment of means to allow users
   to make use of the opt-out provided.  Finally, we recommend that
   others avoid techniques that may introduce additional metadata in
   future work, as it may damage user trust.

> = Section 1 =
> "The
>    motivation for a user to configure such a Centralized Resolver varies
>    but is usually because of some enhanced experience, such as greater
>    cache security or applying policies regarding where users may
>    connect."
> 
> Assuming by "user" you mean end user of the DNS, I think this would make
> more sense if it said "user or ISP" or something like that. I assume it's
> much more common for ISPs to explicitly choose to use centralized
> resolvers than for end users to do so.

I think you're probably right, even taking into consideration that the
original motivation for this came from OpenDNS and Google running
resolvers that users had to affirmatively select.  Either way, I've
changed the text from:

   motivation for a user to configure such a Centralized Resolver varies

to

   motivation for having such Centralized Resolvers varies 

Does this work?

> = Section 2 =
> Given that you reference specific implementations in various places in
> the document, would be interesting to note any specific implementations
> that surface the opt-out choice to users.

An excellent point.  As far as I know, getdns is the only stub
resolver currently offering it, thanks to Daniel Kahn Gillmor at the
last Hackathon.  Is it acceptable to say "regrettably" about something
in an RFC?  I could put this in as the final paragraph of the Privacy
Note:

   Regrettably, support for the opt-out provisions of this specification 
   are currently limited.  Only one stub resolver, getdns, is known to
   be able to originate queries with anonymity requested, and as yet
   no applications are known to be able to indicate that user
   preference to the stub resolver.

> = Section 5 =
> 
> s/client location/client network location/

Done.

> = Section 7.2.1 =
> 
> "A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH
>    indicates that the provided prefix length was not specific enough to
>    select the most appropriate Tailored Response.  Future queries for
>    the name within the specified network SHOULD use the longer SCOPE
>    PREFIX-LENGTH."
> 
> I think it would help to expand a bit about using the exception case for
> the SHOULD here. It seems to me that this basically involves a judgment
> call by the operator of the recursive resolver between exposing a longer
> prefix or providing less useful information to an authoritative resolver
> that is indicating that it needs more information. But setting SOURCE
> PREFIX-LENGTH involved a judgment call in the first place about the
> privacy protection involved in providing a less-than-full address. So how
> is a recursive resolver supposed to decide whether to follow the
> indication from the authoritative resolver about prefix length?

Agreed that it is a bit wishy-washy.  I added this sentence to the end
of the quoted paragraph:

   Factors affecting whether the Recursive Resolver would use the
   longer length include the amount of privacy masking the operator
   wants to provide their users, and the additional resource
   implications for the cache.

Is that okay?

I'm unsure whether it warrants further expansion.  I've felt (without
hard evidence) that in practical terms it would actually be unusual
for a caching resolver to dynamically change its policy for future
requests based on longer scope lengths.  I mean sure, if the recursive
sent up a truncated source length (say,v4 /16) from their normal
policy of /24 because of a user option, then the authoritative will
come back at /24 or whatever and the recursive will subsequently use
/24 anyway because that's their default policy.  But I'm doubtful that
same resolver being told /25 in a response would then switch to using
/25 in future queries.