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

Paul Vixie <paul@redbarn.org> Tue, 12 March 2019 18:17 UTC

Return-Path: <paul@redbarn.org>
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 742F7130E66; Tue, 12 Mar 2019 11:17:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mazzjEqzYSgs; Tue, 12 Mar 2019 11:17:42 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35341277DE; Tue, 12 Mar 2019 11:17:42 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B4052892C6; Tue, 12 Mar 2019 18:17:42 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Eliot Lear <lear@cisco.com>
Cc: nalini elkins <nalini.elkins@e-dco.com>, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, "doh@ietf.org" <doh@ietf.org>, "dnsop@ietf.org" <dnsop@ietf.org>, "Ackermann, Michael" <mackermann@bcbsm.com>, Christian Huitema <huitema@huitema.net>, "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>
Date: Tue, 12 Mar 2019 18:17:41 +0000
Message-ID: <1821023.QPalJCvhiW@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <36C6BE4B-5919-4658-9AF1-AB1572E5999C@cisco.com>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <76386691-c1aa-c48a-9b0d-67eb36a08a4f@redbarn.org> <36C6BE4B-5919-4658-9AF1-AB1572E5999C@cisco.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bI9B0BFH1JK7XDQjivKBcCBkOK8>
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 18:17:44 -0000

On Monday, 11 March 2019 18:18:38 UTC Eliot Lear wrote:
...
> > 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, 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?
> 
> That or it will require a bit more management at the MDM level.  I’m hoping
> the latter.  And I hope that one output of all of these documents will be a
> recommendation regarding MDM interfaces.

MDM is a cooperation protocol. that is, both the operator and the app or user 
have to want data management to be be mastered (DM to be M, so, MDM).

this is off-topic for DoH, which seeks to prevent on-path interference with 
DNS operations. that is, someone or something using DoH cannot be expected to 
seek cooperation with the network operator.

teenagers and malware being two easy examples. BYOD being another.

pre-DoH, it was possible to ensure that noncompliance with MDM would yield 
failures. that is, disallowing outbound 53 and 853 except from the operator's 
own name servers. post-DoH, such enforcement is (deliberately) impossible.

can we therefore please stop talking about MDM here.

vixie