Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 12 March 2019 02:34 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5B129A86; Mon, 11 Mar 2019 19:34:21 -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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 zW66LLNt_nvB; Mon, 11 Mar 2019 19:34:16 -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 2142C1286CD; Mon, 11 Mar 2019 19:34:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 54F7ABE8A; Tue, 12 Mar 2019 02:34:13 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
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 sDbm3DfD0Di5; Tue, 12 Mar 2019 02:34:11 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22344BE50; Tue, 12 Mar 2019 02:34:11 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1552358051; bh=XOzjFjiq25ZTlSAkRCJ2QoZZI3foJ9DbYn9X2HvtMQ4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=4UVt8AQo+iH42arOjzTupJ41BSXWeiemBVqB/1zcni4ZCedcDR/ys1JvaHzV6cHwE b7T0fJ1OcuFkMOAosMewQxGG5svz7UcOeReqXeFkdkAzFyWC/+Agl7rSHDtE5odAA5 ihDszCBsVHNTdfcx7gxEwyPn64KM3oF+Ir2NqeFM=
To: nalini elkins <nalini.elkins@e-dco.com>
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>, Christian Huitema <huitema@huitema.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, "Ackermann, Michael" <mackermann@bcbsm.com>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie> <1991054337.12802.1552259263075@appsuite.open-xchange.com> <eea64b30-aad0-a030-5360-1b1484f1d0e3@huitema.net> <CAPsNn2WhjHSEHJUEL8GB6X0d24fkajgPnY4YgkOQbXjyxb5q8Q@mail.gmail.com> <e62efaf3-4a35-4a52-5ed4-dee2e7fafe72@huitema.net> <69f989ba-0939-b917-b586-9e3af3fb8b74@redbarn.org> <CAPsNn2XNCzgAdfJtxBVboAe+d6sbCiV2fZv9185wm+HN+3zRdg@mail.gmail.com> <BYAPR16MB279065EE519680E7FC9A637CEA480@BYAPR16MB2790.namprd16.prod.outlook.com> <CAPsNn2Up1AtJJCdmu_9NC4jfzc-8dtE+QjUzRxMBUwaN44gvOg@mail.gmail.com> <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org> <CAPsNn2VAgLDW++kb=Csfczp4oydqa4sY-dKWw7P7qTwj=MfxdQ@mail.gmail.com> <b405fbdd-dc36-5df1-b5bc-9ff2dcb149a2@cs.tcd.ie> <CAPsNn2VGMz0-3-5rZ7iSJcEAEWiT4pDMVETBnG60OE3LDbnf+Q@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: <de7ccb1a-e1f3-9229-4421-3e936d8dc658@cs.tcd.ie>
Date: Tue, 12 Mar 2019 02:34:09 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CAPsNn2VGMz0-3-5rZ7iSJcEAEWiT4pDMVETBnG60OE3LDbnf+Q@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PwaTV0h67mgFITQ1of00qsE7hqGaYjDvM"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/vfWG2XIxmPYLO2YGxHPO8vCAW7Q>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 02:34:21 -0000


On 12/03/2019 01:54, nalini elkins wrote:
> Stephen,
> 
>> TLS1.3 will, I expect, noticeably improve security for an awful lot of
>> enterprises in time.
> 
> I am sure you are right. 

Great.

> There is also likely to be quite a bit of pain
> ahead for many. 

I don't agree at all about that, despite claims to the
contrary from you and some others. But that topic was debated
at length already. (Seriously, do you expect some other outcome
if you re-start that debate?)

> Also,
> this is exactly why I propose a neutral observer who might tease out the
> nuances.  

I think that's an outstandingly bad idea. The IETF has no
voting and hence no electorate nor constituency and hence
no identifiable non-voting population from whom ostensibly
neutral observers could be chosen via some (currently
non-existent) IETF process. In addition to be just being a
bad idea, what you appear to be suggesting seems to me like
it'd require fundamental change to the core of the IETF and
to also be entirely off topic for the subject line of this
mail.

S.

> Or
> say something along the lines of "if you do x, you will need to do y".  It
> may also be
> needed to have subtopics.   And, the pro and con sides could also provide a
> writeup.
> The write up could also propose transition strategies.
> 
> I am trying to make it so that people, including enterprises, can better
> decide the merits of the
> situation for themselves.
> 
> Many people do not have the time, expertise or energy to follow these
> discussions which
> have gone on for a number of years.  I have also seen assessments of
> protocol changes from people
> who have "a dog in the hunt" so to speak.  That is, vendors who provide an
> assessment which
> (shockingly enough) results in their own products (which again shockingly,
> cost money) being the best
> solution.  There is much hyperbole on all sides of not just the TLS1.3
> issue but DoH also.
> 
> I compliment the authors of the current drafts on DoH deployment drafts for
> good efforts to bring
> light to this subject.
> 
> Having said that, I would like to see IETF work with a neutral third party,
> maybe an academic institution,
> or CERT, or someone else help people, including enterprise operators, who
> have to make decisions to
> implement these protocols and possibly change their architecture
> strategies.  Even if we manage to
> come to consensus on an IETF draft and create an RFC on DoH deployment,
> many enterprises do not
> keep up with all RFCs nor do they always have the time to evaluate
> everything properly because they
> are so busy with the fires of the current day.   I worked for large
> enterprises for many years doing network
> design and troubleshooting.  I was always extremely busy fighting the
> issues of the day.
> 
> Enterprises, and many others, do pay attention to what NIST or CERT says.
>  Just my 2 cents to try
> to find a long term solution to what has been a contentious and exhausting
> multi-year set of discussions
> for all involved and which seems set to rekindle with DoH.
> 
> Nalini
> 
> On Tue, Mar 12, 2019 at 5:30 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> 
>>
>> (This distribution list is too scattered and diverse. Be
>> great if some AD or someone just picked one list for this.
>> In the meantime...)
>>
>> On 11/03/2019 20:43, nalini elkins wrote:
>>>  impact assessment that certain changes such as
>>> DoH and TLS1.3 will have on enterprises,
>>
>> TLS1.3 will, I expect, noticeably improve security for an awful
>> lot of enterprises in time.
>>
>> As for DoH, I wonder has anyone done studies on how split-horizon
>> names and access patterns leak today?
>>
>> I don't recall having read that kind of study. I can imagine
>> many ways in which that kind of stuff would leak. I'd be very
>> surprised if it never happens. I don't know how often it does.
>>
>> For names, leaking once is kinda fatal. For access patterns,
>> I guess one leak exposes an IP address that's interested in a
>> name (e.g. secret-project.example.com) but more would be
>> needed for broader access patterns to be exposed to "foreign"
>> recursives and/or in-band networks.
>>
>> ISTM that it is quite possible that enterprises that deploy their
>> own DoH services could potentially reduce such leakage and gain
>> overall. (I'm assuming here that sensible browser-makers will
>> end up providing something that works for browsers running in
>> networks with split-horizon setups before those browsers turn
>> on DoH as a default at scale.)
>>
>> Cheers,
>> S.
>>
> 
> 
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>