Re: [Add] When Two Worlds Collide

Eric Rescorla <ekr@rtfm.com> Sat, 17 August 2019 00:33 UTC

Return-Path: <ekr@rtfm.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 ED5F81200FA for <add@ietfa.amsl.com>; Fri, 16 Aug 2019 17:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 9ci4by2tTZPO for <add@ietfa.amsl.com>; Fri, 16 Aug 2019 17:33:56 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 912E21200F1 for <add@ietf.org>; Fri, 16 Aug 2019 17:33:55 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id j17so5212391lfp.3 for <add@ietf.org>; Fri, 16 Aug 2019 17:33:55 -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=QsDClcFIisVknIksykSZVsuXJXH0aprPcTOgrSmakNo=; b=CQwX06cQ1Rdi2KphbDjNacPtEIM/4CaWKPQTKbi6yLoqfGaYrNXWKHY2/kQ3TkUpH7 bCuB/tul6hSNoph4iliBT8o/l+hQyKkkUjrP7Fp2ZHB/303ryoExppf0CChFJkdPmFJ6 xGo3zYLZz7CB/2BpgwEHoD0KDSNsPp4aM1OpgkkBsEhI6h9mvL8xd0L43xn0b8Epwl/r LfkpH7c3bJTQnAPkT39tP16fovwqTuQjteZ7k85V92/JYyTUVWoQaF8194OC7VKJGVcz XS0XG7cwxKZugwPIFHzZuhnZxKFF6+9Z/R77NJRKmOD2DeRBiHC2m3ogGZur2lLph46J JP3g==
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=QsDClcFIisVknIksykSZVsuXJXH0aprPcTOgrSmakNo=; b=UZ9CQ+gOLjfOasNqSjgYYr4lhHxQBE58wkxlUCxCi6FOqqSPOBxqAN89EJ8NvMrpem oVGEjsYtM70Xt4V4Ara3nwB9sjBuwbkNk8MIC1yJU2NphJuU8k5NWhN9Rf5JFu88Dvks syvgTJCNAfA1DzzatU5qqp3cW5JO+uZ5w+8031oVLeBsBpf57PUQT6RBenx+8JAURnx6 btQ4x2u0ykP5RvoGJoglRyT0mJGilQJ8bDcIzyvJ3mfWG497IHxQCp6rN9X8KP41JvAe fXBgmq5S28i7q6J30jT2i+ea/YCACUXAdT7C43p9TPlUsuCFmvAXwLFUiyMU0lGqY2Sw DhOg==
X-Gm-Message-State: APjAAAUMWmbcY8+y2kMa5nrtVm4/uxsV+ga+2NTPqcKKxbKTet5yBmHv Wl0Ne728F64CmQLOkwG7p+fHQg1W2TCpaVUAqpdYyg==
X-Google-Smtp-Source: APXvYqxkovO20U1+1l92l6NpQFtuPzNEZHM6i8Mpkn6yF5fupmT8rhIK6EYaPZ03KUKjWMDavkyE737rKhtlPqwJysk=
X-Received: by 2002:ac2:51a3:: with SMTP id f3mr6290369lfk.94.1566002033837; Fri, 16 Aug 2019 17:33:53 -0700 (PDT)
MIME-Version: 1.0
References: <LO2P265MB1327CC055667B8F972AEDC04C2AC0@LO2P265MB1327.GBRP265.PROD.OUTLOOK.COM> <CAH1iCiqt0YODvxuQf-_Wm3zdC0HAcyRTJ-jMYLe-kMKeLEy9zQ@mail.gmail.com> <09178E42-08B2-4958-A1C8-AF507AEE8834@fugue.com> <LO2P265MB13270AAEC9901FB41632D2F0C2AF0@LO2P265MB1327.GBRP265.PROD.OUTLOOK.COM> <0BDD4F7F-7301-476A-80DA-0CC84EE4557D@fugue.com> <B0B173E7-DA2F-40B9-9DE5-412D4808E9A2@gmail.com> <2BE3565E-4D1D-4C3D-8E5E-9BBF0A6C76EC@fugue.com> <2D09D61DDFA73D4C884805CC7865E6114E279D3E@GAALPA1MSGUSRBF.ITServices.sbc.com> <DAD9F31D-60E6-4F34-9229-4455872E9BE4@hopcount.ca> <CABcZeBO6cvg_1HkFBh_ryNHMKLjWcsN3sKOMGTEXGgDBSwKgPQ@mail.gmail.com> <50618337-3358-4F81-AEAF-F479330488A7@hopcount.ca> <CABcZeBMQJkJcMJ17ivnU3U4vjmHdGmnDL0rMnuSAMXPm1HHXGw@mail.gmail.com> <4F898538-E82D-487C-88AF-0EB803690204@hopcount.ca> <CABcZeBOjHOpb0ti4DaGdoFCerzsO+R9G1kCdWu2K-uQhKQ+eTQ@mail.gmail.com> <3ACBFB29-45C2-41CB-9619-30C679ADB646@hopcount.ca> <CABcZeBO575cia+Up_UFb9hG0jrFWS1q=xs+wUwDpqB7pgGBG0A@mail.gmail.com> <CAJhMdTNQ5G-VRdUgNh2qAjruqBc=4amPMg+TDN2P1LcAnYdeXg@mail.gmail.com>
In-Reply-To: <CAJhMdTNQ5G-VRdUgNh2qAjruqBc=4amPMg+TDN2P1LcAnYdeXg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 17 Aug 2019 02:33:16 +0200
Message-ID: <CABcZeBPsQTZujyojLKwy2UjaEGy7S3O8Pc2r0p1-P00JvmpJXQ@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: "STARK, BARBARA H" <bs7652@att.com>, ADD Mailing list <add@ietf.org>, Ted Lemon <mellon@fugue.com>, Bret Jordan <jordan.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f1dd4405904542dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/MNry270WcoNQuCygyvLAWVEnWo0>
Subject: Re: [Add] When Two Worlds Collide
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: Sat, 17 Aug 2019 00:33:58 -0000

On Sat, Aug 17, 2019 at 2:08 AM Joe Abley <jabley@hopcount.ca> wrote:

> On Aug 16, 2019, at 18:43, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Sat, Aug 17, 2019 at 12:08 AM Joe Abley <jabley@hopcount.ca> wrote:
>
>> On 16 Aug 2019, at 17:50, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> > My point is that either (1) you can do MITM, in which case you can
>> disable DoH or (2) you cannot disable DoH, in which case you won't be able
>> to MITM anyway. But in neither case should you need to MITM DoH.
>>
>> I'm confused. This is not unusual.
>>
>> A user walks into the office with their personal, unmanaged phone. They
>> join the wifi. Some things work, but many things do not. User not
>> technical. What happen. Call IT.
>>
>> User's problems relate to the fact that all HTTPS is effectively blocked
>> because much software on their device reacts badly to the certificates
>> being presented by the corporate firewall, which is MITMing all the HTTPS
>> traffic it can identify through destination port number or deep packet
>> inspection.
>>
>> IT person says here, scan this QR code on the poster and follow the
>> instructions. Some eye-rolling accompanies the need to point finger at
>> large, obvious poster; some inference that most people don't need finger to
>> notice poster. User does that, all now work.
>>
>
> Why can't those instructions describe how to turn off DoH?
>
>
> That seems like a degenerate case of modifying the traffic carried within
> HTTPS, which is what I was trying to describe. So I don't really understand
> the question.
>
> Perhaps what is missing is the need to MITM HTTPS for reasons other than
> DoH in a network that accepts unmanaged devices, which I mentioned earlier.
>

I also do not understand your question. This is not about managed versus
unmanaged.

Suppose that you have a policy that requires some level of HTTPS MITM. In
order to execute that policy, you need to modify user's computers (either
via a management interface or otherwise) or convince the user to modify
their computers. At that time, you can also disable DoH or convince users
to disable DoH (assuming, as Stephen says, that DoH can be disabled).
Therefore, there should not be a need to MITM DoH traffic, because you can
just divert it to Do53.

-Ekr


>
> Joe
>