Re: [Add] A proposed charter for ABCD

[Alissa Cooper <[e-mail]>]

+1

I suspect a rev of the charter Tommy posted in December [1] to reflect comments in that thread would be close enough to start the community-wide feedback step of the chartering process, given the support expressed for it thus far.

Alissa

[1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w 

> On Jan 6, 2020, at 8:53 AM, Mirja Kühlewind (IETF) <[e-mail]> wrote:
> 
> Hi all,
> 
> I agree with Stephan in that I would prefer a more scoped charter.
> 
> I see a lot of interest in the ideas around the adaptive DNS work and I think we should build a charter that targets exactly that, as proposed by Tommy, to make sure that at least this piece of concrete work can move forward (quickly).
> 
> Other topics/problems can go in to other existing or new working groups. Especially topics related to documenting operational practices, as mentioned below in the charter, we already have a working group for and these topics should be discussed that group, nann my rly dnsops (potentially leading to some rechartering of that group in order to make clear that aspects related to operating and maintaining encrypted DNS traffic and DNS servers are in scope).
> 
> Mirja
> 
> 
>> Am 04.01.2020 um 17:20 schrieb 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.
>>> 
>>> 
>> <0x5AB2FAF17B172BEA.asc>
>> -- 
>> Add mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/add
> 
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add