Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-bcp-op

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 19 September 2019 12:33 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EC21201A3 for <dns-privacy@ietfa.amsl.com>; Thu, 19 Sep 2019 05:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnwH5log2HaI for <dns-privacy@ietfa.amsl.com>; Thu, 19 Sep 2019 05:33:32 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19A4120024 for <dns-privacy@ietf.org>; Thu, 19 Sep 2019 05:33:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32ED6BE5C; Thu, 19 Sep 2019 13:33:30 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkpNMD9tTgVq; Thu, 19 Sep 2019 13:33:30 +0100 (IST)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E7F79BE55; Thu, 19 Sep 2019 13:33:29 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1568896409; bh=JZpxhWRTVRYtAe9iRaYGHi0sOHZACeQ040I1mkIobmY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FI7BcmfWwgG3FvYJ0nvMPqCM+AwtPVW5g8eAQ7hT1uevgM6Uo3TGUU9zPTQSkm2Bz 6qVEYcK6Lh1wJqhoQgehmofTyRWuAMmyLGP1xyC2PwyBqYkbEyYpJviXAqwGCKUe5g BkpQ8c4xYHnWqc+7WKWjvPyLQl41Br/ETERlaqyI=
To: Sara Dickinson <sara@sinodun.com>
Cc: dns-privacy@ietf.org
References: <CADyWQ+GUivgm7ghErR4dhp4L2rB_hBK4yLMhaAQHYw1_xsmm4w@mail.gmail.com> <b346dd41-f8cc-a3c3-f7c3-bc0593bddff9@cs.tcd.ie> <55E1EF5E-6838-4DF7-8ACD-673C56EE34A7@sinodun.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <179ee9b9-72a7-cf2d-54b8-428d566593ac@cs.tcd.ie>
Date: Thu, 19 Sep 2019 13:33:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <55E1EF5E-6838-4DF7-8ACD-673C56EE34A7@sinodun.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ek0JmotCgWtOCZ1xougT43QXKGV62GFEj"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ccXcTCP0IhlOX8UZ0LuK1SBTTUs>
Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-bcp-op
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 12:33:37 -0000

Hi Sara,

Sorry for being slow responding...

I think the only bits below where I'm still concerned
are the ones relating to (so-called:-) "consent." I'd
be happy to continue discussing that but even happier
if we didn't depend on the (IMO dodgy) concept. Other
than that, I guess another rev should resolve all the
issues I raised.

On 23/08/2019 17:54, Sara Dickinson wrote:
> 
> 
>> On 16 Aug 2019, at 15:42, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie>; wrote:
>> 
>> Hiya,
>> 
>> I had an hour so gave this a read. I like the draft but think it's
>> not ready quite yet. Depending on the answer to my question at #1
>> below, that could all be fixed before or just after the end of the
>> WGLC though but it might take a bit longer as there's more than a 
>> teeny bit of work needed I'd say.
>> 
>> Substantive comments and nits below.
> 
> Hi Stephen,
> 
> Thanks so much for the detailed review!
> 
>> 
>> Cheers, S.
>> 
>> 
>> #1: I wonder would we be better to wait until some real operators
>> have published DPPPS documents before making this an RFC? I'd
>> expect that there'll be some changes when/if that happens (I'm
>> assuming it's not yet happened but didn't check.) If some such
>> operator has said they'd do that, but want to wait 'till there's an
>> RFC, then that's a good enough reason to go ahead now. If we just 
>> don't know, then going ahead and recording this in an RFC is
>> probably ok, but risks this not being followed much or at all.
> 
> I admit we have a chicken and egg problem. Cloudflare, Google, Quad9
> and several other operators have all published ‘privacy statements’
> but in very differing formats (see 
> https://dnsprivacy.org/wiki/display/DP/Comparison+of+policy+and+privacy+statements,
>
> 
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Public+Resolvers and
> https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers).
> 
> I don’t really see any motivation for them to update these until
> there is an RFC to follow and also I fully expect to bis this
> document in the foreseeable future as the landscape evolves. The
> consensus at IETF105 seemed to be to get on and publish this in
> preference to waiting some unknown time for operator movement.

Fair enough.

>> 
>> #2: I think a sample DPPPS document should at least exist and be
>> referenced from this or included as an appendix. Is there one
>> somewhere? If not, then I think we really ought fix that before
>> publication.
> 
> I like that idea. I think an example in the Appendix could work well
> and could even be based on one of the existing policies :-)

That'd be great.

>> #3: Perhaps we should ask the pearg and httpbis folks if there's
>> any more/better guidance to add to 5.1.3.2? IIRC a pearg
>> presentation at IETF105 seems to have indicated that some h2
>> session management stuff might also assist with traffic analysis.
>> Checking that out before publication would seem worthwhile in case
>> there's more to usefully say here.
> 
> I’ve mentioned this off-list to a couple fo PEARG folks, but I think
> sending mail to those groups makes sense too.

I see you did that and got no response. Well, you
checked at least!

>> 
>> #4: 5.1.4: the lowercase "must" for DNSSEC validation is odd. I'd
>> like a "MUST" but perhaps that's not feasible now?
> 
> There was a discussion early in the life of the document about how
> prescriptive it could/should be because it was a BCP and the approach
> taken after that was not to use normative language throughout the
> document and instead just to use the 3 categories defined at the end
> of section 5 with a SHOULD there:
> 
> “This document does not specify policy only best practice, however
> for DNS Privacy services to be considered compliant with these best 
> practice guidelines they SHOULD implement (where appropriate) all:
> 
> o  Threat mitigations to be minimally compliant
> 
> o  Optimizations to be moderately compliant
> 
> o  Additional options to be maximally compliant"
> 
> DNSSEC is classed as a Threat Mitigation so it falls into the top
> category. If folks want to revisit this general approach then now is
> the time :-)

Ack.

> 
>> 
>> #5: given that 1% of zones are signed, and that DNSSEC answers are
>> big, do we think padding is sufficient to prevent an observer from
>> knowing when a qname is in the 1%? If so, great! (But really?;-) If
>> not, is that a problem worth mentioning? And is there anything one
>> could do about it?
> 
> It is a good question, but I’m not sure this document should do
> anything other than recommend following the guidelines in RFC8467?
> Also, I think that only applies if the client is directly requesting
> the DNSSEC records from the resolver so it can do validation itself
> (which virtually none do today…..), otherwise the resolver just sends
> the same answer with the AD set appropriately for both signed and
> unsigned responses.
> 
> FYI: My understanding is that an update to RFC8467 is highly likely
> given the recent research on website fingerprinting presented in
> PEARG at IETF 105: 
> https://datatracker.ietf.org/meeting/105/materials/slides-105-pearg-encrypted-dns-privacy-a-traffic-analysis-perspective
>

Fair point that addressing this elsewhere may be better.

>> 
>> #6: I don't think mention of "consent" is a good thing to
>> positively recommend operators do as there is (afaik) no good way
>> to really do that. The idea that whatever is behind a DNS stub
>> client can meaningfully "consent" to something is really just
>> broken IMO.  (Mentioning that one cannot assume consent is fine,
>> but saying to go get it, when that makes no sense, isn't fine IMO.)
>> Same applies to 6.1.1 item 7.
> 
> For the subset of operators with ‘contracts' with users e.g. ISPs it
> seems entirely possible to obtain consent? For others, I agree - it
> is untested.

I guess I maintain my position though - a BCP that says
to "somehow" arrange for some ill-defined (and oft abused)
"consent" isn't a good plan.

>> #7: 6.1.1, item 3: "sold or rented" - heh - good luck with that;-)
>> Why not just say doing that's a "MUST NOT"? What operator adhering
>> to this BCP would really be selling or renting the data? I would
>> hope none, and that the BCP calls that out as non-conforming.
> 
> So Section 5.3.3 is actually the part that describes what operators
> need to do for compliance and that does say “should not provide
> identifiable data to third-parties  without explicit consent from
> clients"

"Consent" again? How many times is that honoured vs. abused
by (web) service providers? I think far more the latter
than the former. I'm against extending such pretense to the
DNS.

> 
> Section 6.1.1 is just stating what a DPPPS should contain, regardless
> of the level of compliance of the operator. I see a DPPPS as serving
> to let client know how an operator might deviate from complying from
> the BCP so shouldn’t necessarily be limited to only those that do
> comply?

I don't understand that sorry. T

> 
>> 
>> #8: 6.1.1, item 6: That all looks too heavy to actually be done by
>> any of the bigger folks who use anycast - are we really expecting
>> them to list all the local laws that might apply?  What use would
>> that be to someone selecting an operator really? While some
>> information about jurisdictions ought be part of this, I think
>> that needs more thought.
> 
> Item 6.1.2?
> 
> I didn’t read the section that way so it probably needs some
> clarification. I understood points 1 and 2 to apply to just the legal
> entity of the operator (e.g. Google would specify US) and point 3 is
> just a list of the counties the anycast servers are located in. Would
> be interested to hear other views on this.

Same here. I've no idea if anycast DNS operators consider
the unicast instances only need to adhere to the law where
the operator entity is established or not. IANAL, but
that'd seem odd. If unicast instances need to follow the
local law where the instance is running, then this section
could end up as 100 useless pages.

> 
>> 
>> nits:

Your responses on the nits are all fine. I'll be happy to
check the diffs when you e.g. fix the URLs etc.

The naming bikeshed discussion didn't happen I guess, so
take that suggestion or leave it as you see best.

Cheers,
S.


>> 
>> - abstract: Is "DNS operators" right? Maybe this is really just
>> "DNS recursive resolver operators" and doesn't include advice for
>> authoritative server operators? Probably better to have the
>> abstract correct.
> 
> Section 2 makes the scope clear ‘'However this document is limited in
> scope to best practice considerations for the provision of DNS
> privacy services by servers (recursive resolvers) to clients (stub
> resolvers or forwarders).”
> 
> but it wouldn’t hurt to tidy up the abstract :-)
> 
>> 
>> - DPPPS: that's not a great term, hard to say and hard to remember
>> how many P's - I'd suggest a bit of creative bacronyming might be
>> worthwhile - I'll start the bikeshed painting with "DNS Recursive
>> Operator Privacy statement" or "DROP statement":-)
> 
> It is a total mouthful but the idea was to roughly follow but not
> collide with RFC6841 which describes a DP (DNSSEC Policies) and a DPS
> (DNSSEC Practice Statement). I’m liking DROP, but let the
> bikeshedding begin :-)
> 
>> 
>> - I don't understand the bullet list just before section 5.1, nor
>> the preceding paragraph - what's it trying to say?
> 
> It goes back again to the discussion about how prescriptive the
> document should be. The very first drafts had those 3 categories of
> actions as MUST/SHOULD/MAY options for operators in each section but
> there was push back against it so the current text is an attempt to
> convey more of a ’traffic light’ system of compliance.
> 
>> 
>> - 5.1.2: X.509 probably needs a reference to rfc5280, but where do
>> I go to find a definition of an "SPKI pinset"? Later you point to
>> rfc7858 for that but I don't find the term "pinset" used in there -
>> "pin set" (with a space) is used in appendix A there, so maybe
>> that's the reference you want.
> 
> Yup - it should be ‘pin set’ and this should also reference RFC8310
> for authentication methods based on pin sets.
> 
>> 
>> - 5.1.2: (sadly) maybe it'd be better to remove the mention of the
>> DNSSEC chain extension draft. I suspect it'd just confuse readers
>> of an RFC later.
> 
> Ack. I lived in hope of its resurrection but since it hasn’t happened
> I’ll yank that text.
> 
>> 
>> - 5.1.2: Is anyone publishing TLSA for DoT/DoH servers? If so,
>> great! If not, "can also consider" mightn't be worth saying.
> 
> Only a few of the individual test servers at the moment, none of the
> big players to my knowledge. That is why is is only an
> optimisation...
> 
>> 
>> - 5.1.3.1: the link at [1] seems broken? I didn't check all others,
>> but someone should:-)
> 
> Will fix.
> 
>> 
>> - 5.1.3.1: Maybe say using RFC8467 or a successor specification?
>> It's pretty early days to be very confident in that RFC. (Much
>> though I like it.)
> 
> Will do.
> 
>> 
>> - 5.1.7: Is "Operator" in the section heading here really the
>> operator of the DNS privacy service? Better to be clear about that.
>> People might think you mean n/w operators between the stub and
>> recursive.
> 
> Right, this section is designed to inform the DNS privacy service
> operator (I’ll update the heading)
> 
>> 
>> - 5.2.3: The content of [10] really needs to be in the document
>> body, or else the text above it needs to change.
> 
> Ack - will see what SVG magic can be done or will convert to ASCII
> art...
> 
>> 
>> - 5.3.1: The "NOTE" that the authors may add something later needs
>> fixing.
> 
> Indeed - I’ll follow up with Roland as I believe he was aware of work
> on this.
> 
>> 
>> - 5.3.2: The "pitfalls" link reference is broken I think.
> 
> Yup - will fix…..
> 
>> 
>> - 6.1.1, item 2: add "and for how long and how those logs are
>> handled" (and maybe more) - this bullet also overlaps with item 3,
>> so maybe it'd be better to re-organise this list a bit?
> 
> Fair point. I think merging 2 into 3 would be best?
> 
>> 
>> - section 8: A "TODO" there isn't gonna work really:-)
> 
> I thought I had zapped them all but missed that one…. thanks. I’m not
> sure we have much more to say beyond what is in RFC7766 so I think
> the intention had been to just remove that unless anyone wants to
> suggest text?
> 
> FYI - I am out of the office next week so will follow up on any
> further discussion as soon as I am back!
> 
> Best regards
> 
> Sara.
> 
> 
> _______________________________________________ dns-privacy mailing
> list dns-privacy@ietf.org 
> https://www.ietf.org/mailman/listinfo/dns-privacy
>