IETF Logo Mail Archive

Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator

Jared Mauch <jared@puck.nether.net> Wed, 20 March 2019 01:14 UTC

Return-Path: <jared@puck.nether.net>
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 90024128DFF; Tue, 19 Mar 2019 18:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 N_nIqWpntjOF; Tue, 19 Mar 2019 18:14:03 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1521B1277E7; Tue, 19 Mar 2019 18:14:03 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:cd14:2c86:15f5:ed4e] (unknown [IPv6:2603:3015:3606:cbe1:cd14:2c86:15f5:ed4e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 79018540EE9; Tue, 19 Mar 2019 21:14:00 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net>
Date: Tue, 19 Mar 2019 21:13:59 -0400
Cc: Ted Hardie <ted.ietf@gmail.com>, paul vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4599B066-BA82-4EA8-92C1-F1BE1464A790@puck.nether.net>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net>
To: Michael Sinatra <michael@brokendns.net>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/zIPXBYNy5G3iFlm-g1_EX2OfOBQ>
Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
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: Wed, 20 Mar 2019 01:14:04 -0000


> On Mar 12, 2019, at 5:52 PM, Michael Sinatra <michael@brokendns.net> wrote:
> 
> [1] As an example, I am personally and practically opposed to inline TLS
> decryption in most enterprises.  DoH gives further ammo for security
> folks to insist on inline TLS decryption, IMO.  DoT, not as much, since
> the protocol can be easily identified on the wire and any necessary
> actions taken.  Manipulating DoT transactions is a far cry from
> manipulating/decrypting all TLS...

My impression is there are people who will not be satisfied until all traffic looks
identical and you have zero way to protect your home, enterprise or similar.  (The lack
of protection is a side-effect, not a design criteria of making it harder to detect
variation in endpoint behavior)

I don’t support efforts to offer standards that make everything look the same when
they are not the same.

Next someone is going to show up in IDR saying how we must TLS all the routing data
because reasons.  

- Jared

v2.30.2 | Report a Bug | By Email | System Status