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

Eric Rescorla <ekr@rtfm.com> Thu, 18 April 2019 18:13 UTC

Return-Path: <ekr@rtfm.com>
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 D62AF120370 for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 11:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 yUGdMGkCTIm1 for <doh@ietfa.amsl.com>; Thu, 18 Apr 2019 11:13:24 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80161120144 for <doh@ietf.org>; Thu, 18 Apr 2019 11:13:23 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id h21so2670865ljk.13 for <doh@ietf.org>; Thu, 18 Apr 2019 11:13:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pfYONb3QVcUO3SFPgxTQYVTfEh3Dk69sw7d90ImsfNc=; b=EgfKXvncDNUwzC1LG5kJkYxlg8WBH5sA/+eN7yK8UtT7ztK6letswNrMJfn4s+e2Iz t/e7lKWMXajoPBJgsI4DzCqLWU7CXx6I22wkxY9F6mRlhfLiQtNezbpSImisr+7ka1b5 XPihdGOYeLERsusyi7k1CZWQKG9+TMCSIpWWhkVEpdC+skbqeCHFNFRCwDSQZyHk206d VR0Ug7E4ZckHXiR08dqeIoL4y0HqOZM5Hmhyh/kXBCZnUblj1VU4+p8PrfL4xVdPxR7F v2uHZqk21uSwWy3LbloHOIh1JbprrHHNY5GT5Vo0e7sj49AFs2OhXN+z+tEdC6axKbGZ eyRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pfYONb3QVcUO3SFPgxTQYVTfEh3Dk69sw7d90ImsfNc=; b=FuTz1V4i3JghRb7QUA0rNJf611A4nt7R7YH+z7Iwvk67uCOihO/QvkD046q8LCAWML eL+CAtjU1QkGKqCUHvrkRpKseup9c1XdcQ6cmrn4QhdZ1MKQpTRUyTwOkVa6jOJu6ZBs yH+x9eIX2ou3dxM5D79l9dn1YcyNTCw85Gbgnuzoedqopo8HxGNKxdG1wG92ATTfOldB c1LiNtXqAtlfL7dzR9zRtfcj0S8TCOcDXUJPUod2UfKH1DNpXf7hUcJprgxVUqWoSyD+ OXLRyyjSegfexbm03kyevvI3KfqnTNqKODrVNQjShH/HDVTXmx3z/sM91oX9af6IUY+K Zuxw==
X-Gm-Message-State: APjAAAVcedjjaI+9qix/SvYFVSC45/EXcZbO05UTxsetE6BnR+ZdfJ0P IfMUJyPG5wHHd+yIKK1UQnBq4s1gLS7SWc36tWR887VUkak=
X-Google-Smtp-Source: APXvYqxDDBcUTch5/qs7EOfLJrqrpPvW73Vmozv/Ke8SOs6+L1oy1VXWzC4uEMYNiWX2bGFQoNtX55xMdzkqPCYJuLo=
X-Received: by 2002:a2e:8050:: with SMTP id p16mr4919711ljg.160.1555611201421; Thu, 18 Apr 2019 11:13:21 -0700 (PDT)
MIME-Version: 1.0
References: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com> <CAH1iCio7yS1Ag-FS5-HLhvVw2JDC6=nRCe6AUopWZ=2j5L6ajQ@mail.gmail.com> <CABcZeBNm3Pr0PuOdsFbpRaekmUVEqbzOwjmOfRRBHCyjY67UGA@mail.gmail.com> <f8943aeb-22aa-6713-0692-cdea9548213d@nic.cz>
In-Reply-To: <f8943aeb-22aa-6713-0692-cdea9548213d@nic.cz>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 18 Apr 2019 11:12:42 -0700
Message-ID: <CABcZeBPL6+LUO5yG8S5S6g7FRYHx-q3CjHx9d63zrgP4kAhy2w@mail.gmail.com>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000011e0d30586d1f5d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/SbUzw4pTMnK5fPbkc0c6RZvgJsc>
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 18:13:27 -0000

On Thu, Apr 18, 2019 at 1:03 AM Petr Špaček <petr.spacek@nic.cz>; wrote:

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

Yes, probably, but given that the context in which I introduced this point
was about the
need for DoH, I'm not sure that that is relevant.




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

Well, I'm not sure why the situation would have changed, but I'd certainly
welcome any data you have to show that client-side DNSSEC validation
is safe.


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

No, unfortunately not. The question here is about validation in the client,
and
so validating ISP resolvers don't address the problem.




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

I'm not primarily talking about misconfiguration (though I've seen data
reflecting
that as well [0]) but about damage due to middleboxes.

-Ekr

[0] https://www.cs.umd.edu/~dml/papers/dnssec_imc17.pdf

>
> [1] https://stats.labs.apnic.net/dnssec
>
> --
> Petr Špaček  @  CZ.NIC
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>