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

Eric Rescorla <ekr@rtfm.com> Tue, 12 March 2019 15:59 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CE7130E8C for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2019 08:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 f2Kh20U2X4Wu for <dnsop@ietfa.amsl.com>; Tue, 12 Mar 2019 08:58:57 -0700 (PDT)
Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) (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 D521413114C for <dnsop@ietf.org>; Tue, 12 Mar 2019 08:58:53 -0700 (PDT)
Received: by mail-lf1-x144.google.com with SMTP id h71so2492060lfe.0 for <dnsop@ietf.org>; Tue, 12 Mar 2019 08:58:53 -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=2XWPs/NrlrFLV2YuUoaFlh6oxXyJg5mM/w8l0Mc2MTI=; b=mDXM0erPyJAI4/j59zM24Xcjfm1fjGffO7vhHMvtPrIQMQtxzQMUsB0CWZ8XlxPoYH nDOnUz8wJurQlNfATafMMIqz63WiLbPHAlUpqsPOADwXApGWp9aISoeWfGaAhe5msS2G xPsYclsE1gjhEF5gbcHDvbBlqbL+Jg7R5I+La4p68jUepm7mf1U5J0Pf29LrNLNF5K07 6b90u935/FERvlyoz/BmPgnSs43caYEtuSAt6um6mdHVDypxY60PPcZU2wYR7J/2zOrI W5+LaTD0kh2pNiv299aKDlMpsI2llsYjxn1ykBOvMUsOfxZqL1p8OUkYT1zKVZ2iydqf BmPw==
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=2XWPs/NrlrFLV2YuUoaFlh6oxXyJg5mM/w8l0Mc2MTI=; b=kwK++o2QgTW9NVZwU6xwn4jzWPLmxbhcIDhIefGdlS24r1XwZ0mZMn9xLTTd1mfQKB KeyLytNgeOS6HLJ21Bl1anv0KPY6ftlKQrL1I6MzZiLQBPoEFbgA5Cd0tX52bx+ilD+x yJo2kZp6HNbBrpPMQO4zqtcc2qPcUF8j4Yp2JRSNQN3m7kbaejusLVQ8c0hBVk3DDRfM 63SZkzNixDEHOQMp2ZaqaXhlFnzmWYKfH/r1hye+/IPXYhKTO59rXlh++f0LZiWsQsIi aSS0PmaC7kMzooEsxP93TCVijMRPfOCwfg4EqJtZ95xE6E1wX+cyWzJ3F86LLQJyZX0D kFCw==
X-Gm-Message-State: APjAAAUiKVO+J9BsyWDtD4I91Sfl+pKFxE95waO3ezsgn1nM8vPxpVwj sHuKnrEstJsNnE5ht3P7yQMNORnZRGleV2atkoN6jQ==
X-Google-Smtp-Source: APXvYqxvo4o67J37RiFn6e5Nx056hMr6rLyoPp0a9mk9DoQAra8y8PrvLmKbr2G0JCSNh7crtdEqhwvse8xZxjs3fWU=
X-Received: by 2002:a19:7516:: with SMTP id y22mr19179163lfe.106.1552406331571; Tue, 12 Mar 2019 08:58:51 -0700 (PDT)
MIME-Version: 1.0
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> <CABcZeBOWM0Ps-j3V-CK6VPy0LAqeo7-t7odUZy+dk9d-oCSDsg@mail.gmail.com> <BYAPR16MB2790E12D58E5ED2F58355CCDEA490@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB2790E12D58E5ED2F58355CCDEA490@BYAPR16MB2790.namprd16.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Mar 2019 08:58:12 -0700
Message-ID: <CABcZeBNJ+QURYOhu3ginFvnasMbQ53aK=c5fkAuCfgFwarhgzA@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary="000000000000f0d6140583e7c31b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/WbXdKtJWwqgIQZ7-3Na2sQ63xLA>
Subject: Re: [DNSOP] [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Mar 2019 15:59:07 -0000

On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:

> Hi Eric,
>
>
>
> In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and
> white-list, black-list and grey-list TLS session based on the server
> identity. In other words, middleboxes are conditionally acting as TLS
> proxies to specific servers (categorized in the grey-list).
>
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS
> proxy for all the flows.
>

It would be most useful not to conflate TLS 1.3 and ESNI.

In ordinary TLS 1.3, the SNI is in the clear but the server cert is not.
However, importantly, even in TLS 1.2, the server certificate is not
verifiable, and therefore is not significantly more trustworthy than SNI.

With ESNI, the SNI is encrypted (hence the name). However, the xpectation
is that enterprises which want to do conditional inspection will disable
ESNI on the client. This should not be problematic as they already need
access to the client to install their own trust anchor.

-Ekr



>
> -Tiru
>
>
>
> *From:* Eric Rescorla <ekr@rtfm.com>
> *Sent:* Tuesday, March 12, 2019 3:14 AM
> *To:* Paul Vixie <paul@redbarn.org>
> *Cc:* nalini elkins <nalini.elkins@e-dco.com>om>; Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>om>; doh@ietf.org; dnsop@ietf.org;
> Ackermann, Michael <mackermann@bcbsm.com>om>; Christian Huitema <
> huitema@huitema.net>gt;; dns-privacy@ietf.org; Vittorio Bertola
> <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>rg>; Stephen Farrell <
> stephen.farrell@cs.tcd.ie>
> *Subject:* Re: [Doh] [dns-privacy] [DNSOP] New:
> draft-bertola-bcp-doh-clients
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
>
>
>
>
> On Mon, Mar 11, 2019 at 11:13 AM Paul Vixie <paul@redbarn.org> wrote:
>
>
>
> nalini elkins wrote on 2019-03-11 10:26:
> > Tiru,
> >
> > Thanks for your comments.
> >
> >  > Enterprise networks are already able to block DoH services,
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is
> going to push a SOCKS agenda onto enterprises that had not previously
> needed one,
>
>
>
> I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
>
> doesn't generally encrypt headers any more than TLS 1.2 did, except for
>
> the content type byte, which isn't that useful for inspection anyway.
>
> Are you perchance referring to encrypted SNI? Something else?
>
>
>
> -Ekr
>
>
>
> and that simply blocking every external endpoint known or
> tested to support DoH will be the cheaper alternative, even if that
> makes millions of other endpoints at google, cloudflare, cisco, and ibm
> unreachable as a side effect?
>
> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i
> blocked already (before DoH) so that's not a problem. but if google
> decides to support DoH on the same IP addresses and port numbers that
> are used for some API or web service i depend on, that web service is
> going to be either blocked, or forced to go through SOCKS. this will add
> considerable cost to my network policy. (by design.)
>
> --
> P Vixie
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
>