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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 16 August 2019 14:42 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 C5AFB120096 for <dns-privacy@ietfa.amsl.com>; Fri, 16 Aug 2019 07:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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] 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 nxdXHG5vcMbd for <dns-privacy@ietfa.amsl.com>; Fri, 16 Aug 2019 07:42:25 -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 E8E00120047 for <dns-privacy@ietf.org>; Fri, 16 Aug 2019 07:42:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD260BE39 for <dns-privacy@ietf.org>; Fri, 16 Aug 2019 15:42:20 +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 xm9Pvuyz1ArB for <dns-privacy@ietf.org>; Fri, 16 Aug 2019 15:42:20 +0100 (IST)
Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 81A0ABE20 for <dns-privacy@ietf.org>; Fri, 16 Aug 2019 15:42:20 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1565966540; bh=+0u6xLY3x4pFbrxpw4MPHNOdSpXOKXSyN6VEspqFlXY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MLqoAigyRazLooJcIQybTyLacQv6RcVt5vTcKe7xwVEjveOFyF9VFONcQDsRWWtj4 XPxhvyonpDXb90F1PztMRK3EHUBR1fYUwnD7txCNGnu8Kut+4J8rq/dsvudNes492t 8gr9p4SykowMVmetRa1OKcK1o8xwkDpO+mf0gsDg=
To: dns-privacy@ietf.org
References: <CADyWQ+GUivgm7ghErR4dhp4L2rB_hBK4yLMhaAQHYw1_xsmm4w@mail.gmail.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: <b346dd41-f8cc-a3c3-f7c3-bc0593bddff9@cs.tcd.ie>
Date: Fri, 16 Aug 2019 15:42:18 +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: <CADyWQ+GUivgm7ghErR4dhp4L2rB_hBK4yLMhaAQHYw1_xsmm4w@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2uDyLWX4284akrd50ygWORAkpApIs3ffH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/lIPShV_eU18YtwlAnS3ckORhnhQ>
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: Fri, 16 Aug 2019 14:42:28 -0000

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.

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.

#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.

#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.

#4: 5.1.4: the lowercase "must" for DNSSEC validation is
odd. I'd like a "MUST" but perhaps that's not feasible
now?

#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?

#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.

#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.

#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.

nits:

- 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.

- 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":-)

- I don't understand the bullet list just before section
  5.1, nor the preceding paragraph - what's it trying
to say?

- 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.

- 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.

- 5.1.2: Is anyone publishing TLSA for DoT/DoH servers?
  If so, great! If not, "can also consider" mightn't be
worth saying.

- 5.1.3.1: the link at [1] seems broken? I didn't check
  all others, but someone should:-)

- 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.)

- 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.

- 5.2.3: The content of [10] really needs to be in the
  document body, or else the text above it needs to
change.

- 5.3.1: The "NOTE" that the authors may add something
  later needs fixing.

- 5.3.2: The "pitfalls" link reference is broken I
  think.

- 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?

- section 8: A "TODO" there isn't gonna work really:-)