Re: [Doh] Mozilla's plans re: DoH

Petr Špaček <petr.spacek@nic.cz> Thu, 18 April 2019 08:03 UTC

Return-Path: <petr.spacek@nic.cz>
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 0D9CF1200DE for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 01:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 4qSR592vLAyk for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 01:03:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1256F120129 for <doh@ietf.org>; Thu, 18 Apr 2019 01:03:18 -0700 (PDT)
Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2001:67c:1220:80c:8010:dac7:96a7:dd53]) by mail.nic.cz (Postfix) with ESMTPSA id 563616338B for <doh@ietf.org>; Thu, 18 Apr 2019 10:03:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1555574594; bh=D0hZ8y7CQ5gVsqsY+50EaPnf1i7X1lAL4X2L+dSF8fI=; h=To:From:Date; b=M0G6Ojb++Vm+w5eGEKWq8led2CE6c36p+Ccet5BXLjnI9SZuOMQ2mp3/m0vHqeFUe XghOMLFpCrxGJQ2TzffM+/cD3BHatNOUzMEKTnG5hJiCyYQYSLIQ9QOuZ5aBt1pN6f qS/qK5jbXR0jGFOwBDGhj5czcFZwSVeTSRcPs0Gg=
To: doh@ietf.org
References: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com> <CAH1iCio7yS1Ag-FS5-HLhvVw2JDC6=nRCe6AUopWZ=2j5L6ajQ@mail.gmail.com> <CABcZeBNm3Pr0PuOdsFbpRaekmUVEqbzOwjmOfRRBHCyjY67UGA@mail.gmail.com>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Openpgp: preference=signencrypt
Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCBQZXRyIFNwYWNl ayA8cGV0ci5zcGFjZWtAbmljLmN6PokCVAQTAQgAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIe AQIXgBYhBL4m67nL4FmzkQyjW86N1qGlCiHkBQJcEOXhBQkFp4LgAAoJEM6N1qGlCiHkxNwQ ALFyQ7Rrghf0rM9GN2+kgP92Qvot21h8/Je3bRTvoLyhYUXcAMRmODZQ/0EsjExFc+pRwn+E 0GD2TpiorDnRMpJYEmHqenYGIrZ5TE0lHwwu0fi/X3evDY4j68OFlim5Q6+7pHOlZWaRsSm5 T6blSwIaNDFYtBhI0X1ZXTGqbXIUBFuGxolo/xEgUkeDy+6D4R8yT17CTHkuGYYrfUYnoBTr j3xMVil/lNMievaklAL8kRNVl0It4M8VzHTyEdMq7pG0CJ0CfU8COizCsu4+zy8dsxMVE0Su hju05LSsClZ9X1csxSK9HjKq+TG1Hx2qciFHRB1qC2mNIvWTm10Gkj4tLTWcJp3k2Wyv+1K2 sLFxreGOwbx0uR7XtIIBTiiZAiVsjBH0D39qG2ZLz+bJkQvlTDZQuXzsMS51wROvTVxPYcXX p069hON2+/QqJasmpOHhOydGkB3uokA0crqvMOnK+EcueKQQspvdLGiFLefJPuM8VVyR9fFZ YjnX2vfGZbE+MxY8wG4mDbhgxsUORAEtNUH/G0dvTv66fzKpl5q9GIZs7el+1IU31w7KivgS 7fsWcOsdzq4KzZzNBRJtEDoxX4b9lQ8P6ttMlPi7PnQ+iN0OUxKSnAnKQiqKMFRO1zH22vn7 iiF4JMO32//0HcpsyV8oEdjDkSJsFRnDfLW2uQINBFhri/0BEADFp4ZfxSoKTAad0IkFK9CV oZ6XKywYLFNPPhzw++gbvHL2EX7QqhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQo u0FeSNnzRGb607U8OFOPQ+ei92Mm1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkh wtWU/6yo+RZs7cFRuihuLl8FuoP0A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAw GDtjWkBVawpoHWwq58OQSx5piwyOCnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdW Jw5OV9BoA7UTHG95xVHV5QiEm6q6igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8 mmKyS8E+mSh3djmqdJNHF1pJqKxAxPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03d uzocyU95DfP/lwNJr5SH918Vf1t7WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkS eXNoMlHJOIqbqm7N414I0HytbENf7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw 3f3Gn3+PDzGEHI9sfQv/mYvO77oRSGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6If ZZ0OIWKLSRa/DQARAQABiQI8BBgBCAAmAhsMFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ 5fcFCQWngvoACgkQzo3WoaUKIeTg+w/9Gyp5EcB4AoR3vKVxP0SAh1zBher3bh9uGaKTAWt0 +0v8fyZYGEPqZr//9rkodPnXbQnr9ogzjJmZpsPvGPyRZikWjYIwkfM2Vb4BCyr5wQ9++9KB kob5zCQmUw2o7s/gISpFsCC5B0eYusArVDnrCyrroyaxbN6MpUb5lzVMEOCzYljtdrPRAXPL FKRm3ijLV0RcYPzJJVOPV5EzUfCtGsGTXXRI9Y9O/7lFaJ+iWnwygo/Xoi0IgBHvOAj9Gp3Q 0BY+sI6Rgzm9dbddm8gYJ4+FjfZivI7fbdfSubTWvrtFmFdHovIPJYLvXK7hUG22ww4CneIF D4oZSVy9xUoqJf0qQNruzEqTr7y7lbZIzxgPCSVmH0jpgJ1po6RLaJllNA+ZklOQ76fCMiaD 5yQuJluwD5w+acPWTbmZX6DijGHPZSjzeUkiMKctYSRqVUo6JmK0dgwwm3l1/Orb4D3YsLVP QDa4ZrCfSldrGC3zkEJ8iCVSYQwlc0JfIxyn8C3LLxToPYeFv/bQTeDYBjaV7a0SQ/xKUdpg RFzrGrxj7CM2WHcpxCLVK0agobuUO7YXoufHRM6y0rfMwT10baDjh+hLKMshxTqsP55lWvtM SleSGjheVTiZChb3jK0rUPCC4Rg3gDTEQsptC3TgN48PtLpmhsNc4JPm64zlrreInZQ=
Organization: CZ.NIC
Message-ID: <f8943aeb-22aa-6713-0692-cdea9548213d@nic.cz>
Date: Thu, 18 Apr 2019 10:03:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBNm3Pr0PuOdsFbpRaekmUVEqbzOwjmOfRRBHCyjY67UGA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: cs
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/FUCjkPqWy2_RDp9LcOotapBqLnM>
Subject: Re: [Doh] Mozilla's plans re: DoH
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: Thu, 18 Apr 2019 08:03:21 -0000


On 01. 04. 19 22:45, Eric Rescorla wrote:
> 
> 
> On Mon, Apr 1, 2019 at 1:32 PM Brian Dickson
> <brian.peter.dickson@gmail.com <mailto:brian.peter.dickson@gmail.com>>
> wrote:
> 
> 
> 
>     On Wed, Mar 27, 2019 at 2:18 AM Eric Rescorla <ekr@rtfm.com
>     <mailto:ekr@rtfm.com>> wrote:
> 
>         I’ve heard a number of questions about Mozilla’s plans around
>         DoH. We’ve made a number of public statements, but it might be
>         useful
>         to try to put this all in one place.
> 
>         In context, the problem we are attempting to solve here is attack on
>         the user’s name resolution from an attacker with full or partial
>         control of the network, as contemplated by Section 3 of BCP 72
>         as well
>         as BCP 188. There’s ample evidence of monitoring/manipulation of
>         user
>         traffic via this vector [0][1][2].
> 
> 
>         [1]
>         https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-pearce.pdf
> 
> 
>     Looking specifically at the problem statement and evidence, I have a
>     question about this (or any other) investigative work:
>     Has there been any related/follow-up work, or other similarly scoped
>     work, to examine the use of DNSSEC in the domains tested, that
>     you're aware of or can point folks at?
> 
> 
>     I.e. Were any of the manipulated domains signed DNSSEC domains,
>     where validation might have prevented the manipulated responses from
>     being accepted from the resolver?
> 
>     Clearly there would still be the issue of being able to find/reach a
>     resolver that does not manipulate results, but at least the
>     manipulation would be detected/blocked.
> 
> 
> I don't have much more information than is in the paper (you'll note I'm
> not an author), but generally DNSSEC doesn't help that much here. You
> can't safely do DNSSEC validation on user-facing clients because of a
> combination of tampering by middleboxes (typically record stripping,
> etc,. not really "attacks") and errors in the published DNSSEC records.

Tampering by middleboxes is solved by DoH, isn't it?

Statement "can't safely do DNSSEC validation on user-facing clients
because of ... errors in the published DNSSEC records" requires some
evidence to show it is still valid in 2019.

According to APNIC's data [1] ~ 17 % of web population is behind DNSSEC
validating resolver today, so anyone who screws up DNSSEC will notice
and fix it quite quickly.

Second data point is that we (as CZ.NIC company) provide support to
telcos operating DNSSEC-validating resolvers, and do not see any
significant breakage caused by misconfigured DNSSEC. To give some weight
to this statenemt please note that CZ has ~ 65 % users behind validating
resolvers, CZ.NIC doing support also for local telcos, and we simply do
not see the rummored breakage caused by DNSSEC misconfiguration.

[1] https://stats.labs.apnic.net/dnssec

-- 
Petr Špaček  @  CZ.NIC