Re: [Add] A proposed charter for ABCD

[Stephen Farrell <[e-mail]>]

Hiya,

The verbosity and lack of agreement and clarity on the list
since this was posted has convinced me that this is not a
viable charter.

That said, some (mostly negative, sorry;-) comments
below...

Cheers,
S.

On 20/12/2019 15:20, Ben Schwartz wrote:
> Hello ADD list,
> 
> Based on the feedback from the ABCD BoF at IETF 106, and with additional
> input from chairs and area directors from relevant working groups, the ABCD
> BoF chairs have drafted the following updated charter for a working group.
> Please review it and share your perspective.
> 
> Tommy Pauly has recently posted a charter text proposal that considers
> closely related issues. This is not a competition, so please avoid “voting”
> for one proposed text over the other.  The text of any final charter will
> be written by the IESG.  To help them judge whether a working group should
> be formed, and how it should be chartered, the most productive input would
> be to know which elements of each text you find valuable (if any), and
> which you would like to see changed in any final charter.

Tommy's proposal has the benefit of covering fewer topics.
I think that's (fewer topics) likely a requirement if any
progress is to be made.

> 
> -----------------------------------
> 
> Proposed charter text:
> 
> This working group will focus on DNS client side topics, particularly
> discovery and selection of resolvers. This complements existing DNS-related
> working groups, which are responsible for improvements to the DNS protocol
> itself, and for operational questions that are principally of interest to
> DNS server operators.

I like that you've tried to provide a logical functional
basis for what to in/exclude in the WG. However, my take
is that success/failure will be much more driven by the
non-functional aspects (e.g. cat-herding, not biting off
more than can be chewed) so I'm not sure this is needed,
even if it's clever;-)

> 
> The working group is chartered to develop an extensible protocol for a DNS
> client to learn detailed information about a resolver, based on
> draft-ietf-dnsop-resolver-information, which will be transferred from
> dnsop.

Using that to discover that a recursive offers DoT/DoH
seems to provide, at best, opportunistic security. But
I like opportunistic security approaches, where they're
useful, and it could be useful here, in some networks.
In other networks and for some applications, the OS
approach will provide no substantive benefit.

For opportunistic security to be useful also needs at
least a story/plan for how to get to something better. So
I think there's a major missing part here about
re-visited networks. (Even if aspects of that are
implementation-specific, the story is needed before we
know the opportunistic staging post is useful.)

I think a wg that doesn't start out with an agreed
understanding as to whether or not discovery being
opportunistic is ok or not will fail. There may even
be a need to catalog the various possible setups and how
discovery plays out in each in order to make progress.
(Recent list discussion with unqualified uses of the
term "trust" along with ambiguous pronouns seems to
indicate that may be needed.)

Even with all that, I'm not clear what'd motivate an
application (whether a browser or something else) to want
to do this, though I can see this possibly being useful
for a system or OS stub. I could also see some applications
using this as a way to be seen to be "doing something." All
that said, the "useful" here doesn't seem like a huge win
really in many networks. (IOW, if someone thinks defining
this will stop applications using their own choices of DoH
server, my guess is that that's wishful thinking.)

I don't understand the information leakage aspects of this, if a
non-updated recursive forwards the queries upward, nor
potential attacks (on stubs, launched by/via recursives)
this might enable. (E.g. does the nxdomain for the first
a.b.c.10.in-addr.arpa mean no other e.f.g.10.in-addr.arpa
will be forwarded for the TTL?)

I'm not convinced this putative wg is the right place to
develop an extensible protocol like this - dnsop seems much
better suited really, so I'd argue to leave that draft
in dnsop.

> Relying on this new protocol where appropriate, the working group
> should produce standards-track, informational, or experimental documents
> that provide the following items, using the drafts in brackets as input
> (with no obligation to adopt them):
>  * methods for a recursive resolver to advertise support for an alternative
> transport protocol [draft-sah-resinfo-doh],

The security considerations of that seem to me to make it
either pointless (already doing DoT/DoH) or impossible
(DNSSEC for 10.in-addr.arpa).

>  * methods for a recursive resolver to indicate that it will sometimes
> return DNS results that are different from the global DNS
> [draft-grover-add-policy-detection],

That bit seems ok, though canaries are fragile of course.
It's not clear to me that needs to be in the same WG as
the recursive discovery bits, but it could be.

I don't get why both TBD.arpa and <reverse-ip>.arpa would
need to be supported by recursive developers. ISTM one
kind of oddball qname for this stuff ought suffice for all
of the things envisaged in these drafts.

>  * methods for improving user privacy by avoiding DNS queries that leak
> information or directing them to a server that will have this information
> anyway [draft-pauly-dprive-adaptive-dns-privacy], and

I think that draft by itself (and what it implies) is
already the meat for an ambitious WG.

>  * a format for describing the client’s DNS configuration, suitable for
> diagnostics and debugging.

I'm not clear why this is needed.

Attempting all of the above is IMO way too ambitious given
the divergent interests and trust models visible in folks
postings to this list over the last 8 months.

> 
> Where possible, any mechanisms that specify exchange of information between
> clients and resolvers should provide the security properties expected of
> IETF protocols, e.g., confidentiality protection, integrity protection, and
> authentication with strong work factor.  Each specification must clearly
> indicate under what circumstances and assumptions these properties are or
> are not provided.

I'm not sure why including that boilerplate-like text is
a good idea.

> This working group will coordinate and share WGLC announcements with the
> following working groups: dnsop, capport, dprive, dhc, and homenet. The
> working group will also coordinate with the Security Area, and will be
> assigned a security advisor.

Assigned security advisors aren't that useful I think. The
person concerned is either interested or not, if they are
they'll not be shy. If they're not, they'll not be useful.

> 
> P.S. One note regarding this proposal: the chairs of the doh working group
> expect that doh would be closed if a new working group were chartered in
> this manner or similar.
> 
>