Re: [Add] fixing coffee shop brokenness with DoH

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 25 July 2019 15:16 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1788120073 for <add@ietfa.amsl.com>; Thu, 25 Jul 2019 08:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=gmail.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 lKk-iwFGOq8z for <add@ietfa.amsl.com>; Thu, 25 Jul 2019 08:16:35 -0700 (PDT)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 22D6D12006F for <add@ietf.org>; Thu, 25 Jul 2019 08:16:35 -0700 (PDT)
Received: by mail-ua1-x92e.google.com with SMTP id c4so19982188uad.1 for <add@ietf.org>; Thu, 25 Jul 2019 08:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XvPhNw6V6IG9JXT3OuME49JANd9nQiQmp4PWR+iO6c4=; b=YsVZ+TzjIZIHb/IrxuJDiOZdvYNTru8u37XtJAhVgR2Pi6HQggiKXm+NXYB0Cd3qAt xVRw7Fk1aGYtCo1jvvqpKYgD8Gks2fmCpUVKZgDVRVLlS/Fucb71ALFI42YJoNwPTsgx 5++CacVSciWzIBk4+ETVPJhEozxsBZfrIa/OaLSu4yvykBG4LBoEhsSMa88iElfgTDgk Bb3UZIu/6n+eBV2JZJ9XMGRdBUdww2VuerQHggktQ/s0A/G6GrIWkfzmbk7NFJmFpFOy Tjd3O8nlfSbw9ikXmWKTyAhrt1fwtn0viw3q9+dQZFQiJtdJtSxByhsEAYDaQZpxM7KL EAgQ==
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=XvPhNw6V6IG9JXT3OuME49JANd9nQiQmp4PWR+iO6c4=; b=m6YHzlVPNK7fiNs3QLx5tz14jhLCuLkYunBJTAtldlB1WeMaEP5/0BSGOmM7SdcPh5 brT/pXNA4MLVJVQR3bXnj3Rwo61ic8zksmmANPWrzxtSupTpS5PBM3GomdVgcW9WPvaC 7akhEQPDgJoVVJdTv/cTkLOZXNanV0pMF/zMoxfQ7xfWLgekKBKVXYNFiHiDVOXIxe2U ttv+/CE50lY+6llFZQJr0KvSm+2dMGbku9415Q4iYEWJKker/tUfJIu0CZJO1xEHtpRf AvE1bPc2VCxBGA20chUxcVzUEgwqqP3OpVOCH+sFprlaEGSgCJWyywHd5v9qLZAnRi1m DdwQ==
X-Gm-Message-State: APjAAAWkllUzEE+kgn0H5xaRmEKT5bVZluDHTIHk76wyMyAhbShI+YWt tIqvf1O5XAq6F+vDX9i/mWi5WgIG/Re+fNbFGPI=
X-Google-Smtp-Source: APXvYqzNo6Lw5SNsk2hVNwmo73AzvHqHtzNgCo+wx1oGqEe5/ubBuEiX9TrvwGOqkO2LyqSl6pEwLff+nKW416cRfNw=
X-Received: by 2002:ab0:1c0c:: with SMTP id a12mr15202031uaj.75.1564067794246; Thu, 25 Jul 2019 08:16:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAChr6Sx9TEt6CMzRRrdb-HwT_k987oW=4yF1FCbDF17zkaE2Vg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E23910C@GAALPA1MSGUSRBF.ITServices.sbc.com> <14DF8769-A817-4C06-9140-80198518244F@akamai.com> <CAChr6SzH1EycAr5n+dK5BQcG=0Zsw66qE=8Rptvq7SEoEvQQ=Q@mail.gmail.com> <E5A0DAE2-A718-41EA-B490-58ABD0F31CF2@rfc1035.com> <CABcZeBMqvZivS_Hk_2mSOAOnM+mHy1mtcwnHVFc14v_jdkgU=Q@mail.gmail.com> <1EFB37A3-23C6-44FF-B001-8F04B381EC04@rfc1035.com> <CABcZeBPB2Bb8RCigDt+tJ5Lz3KQQnPAVVkrF+fDUiTFJcw=eVw@mail.gmail.com> <D3359CC8-80B4-4443-B3B1-F2AD80C94DA6@rfc1035.com> <CABcZeBOZiu_=VfWJDY_9V86TiGpsuZRKMCiersopxD+kTBBUtA@mail.gmail.com> <20190725142135.0FFA715BD17B@fafnir.remote.dragon.net> <CABcZeBPO-hi=z-fB1toOCBRTUF+krndCZqPHS=Jrev1tTtY6XQ@mail.gmail.com>
In-Reply-To: <CABcZeBPO-hi=z-fB1toOCBRTUF+krndCZqPHS=Jrev1tTtY6XQ@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 25 Jul 2019 11:16:22 -0400
Message-ID: <CAH1iCir9L+U7cUWJgOLdP-G1MtxWvPo5sUn4z9GRvym12buH2A@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Paul Ebersman <list-add@dragon.net>, ADD Mailing list <add@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000047dfe3058e82e9e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/UhAC2GE_8FMQVmuavOE12zw5n4k>
Subject: Re: [Add] fixing coffee shop brokenness with DoH
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 15:16:38 -0000

On Thu, Jul 25, 2019 at 10:29 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Thu, Jul 25, 2019 at 7:21 AM Paul Ebersman <list-add@dragon.net> wrote:
>
>>
>> jreid> Not really. A validation failure is a fairly strong indication
>> jreid> that the resolver is lying to you.
>>
>> ekr> Not really, no. Our current belief is that there is going to be
>> ekr> quite a high rate of non-malicious validation failures.
>>
>> What's the basis of this belief?
>>
>> When I was at comcast, query volumes on recursive were on order 500
>> billion q/day and hard/persistant DNSSEC failures were on order of
>> dozens per month, so that seems like a pretty high success rate.
>>
>
> See my previous message. This is about middleboxes interfering with the
> DNS queries, which would not be visible to you from the vantage point of
> comcast's recursive resolver.
>
> -Ekr
>

I'm confused by this reference to middleboxes and DNS.

The presumed use case is Do* (DoH/DoT), where the middleboxes only see TLS
traffic, and absolutely have no ability to inspect or interfere with the
contents of DNS packets within those connections.

If we remove the middlebox from the equation, how then do you maintain the
belief that "there is going to be quite a high rate of non-malicious
validation failures"?

The other messages in this thread indicate an extremely low rate of DNSSEC
failures.

Brian