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

Patrick McManus <mcmanus@ducksong.com> Mon, 25 March 2019 07:52 UTC

Return-Path: <mcmanus@ducksong.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 B9C69120379 for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 00:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=lgvH7Hfp; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=Vd5hmFdY
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 oPxsE2h4rGQP for <dnsop@ietfa.amsl.com>; Mon, 25 Mar 2019 00:52:54 -0700 (PDT)
Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03C6120372 for <dnsop@ietf.org>; Mon, 25 Mar 2019 00:52:52 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1553500372; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=FfQob3LFjOgXCL0z6SmaCC3M05ZrPM5+ZUuIHLV/x5EbAYTpJqIzNsD/O5hJ1iQQWmLjE539vLuaN 468bhrSboyR6ur31T+Sgjsh0yWdTmG7vsK9H7D/kmrgpzP8k/KMa66KBY8JZMXQXxSUdjKHqzx3tOr VR5NkKKsb/shoa8HRqohngv6kQUrS/tACvnpS3oSD+6DGUycQqtGIj0aAqMAHgSmTxWoEcPpYB3eVW cWujKsprmz78shnpbe7Sv0k/X4zcAay2KWRvUbbsnno4rLlvRoadlkfMk0rF+Ts+EIl+aNRMGu+dON 3L4WqFm79QYqDmQuMGIpz8bVdJvYHTA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=FcjAaMS1DO8NqnRTYL/6KHEij6zFnlm/6ka43/c4WB4=; b=shk2PW3t4At8kDlg4vHB04xeWTJps1mLROHG0t/HCoX8d/VAM1DH/Br1qQoWZe9S0dMyKRyITANXE khPYU0UnTopc0zEbD+4YkrK57qUlx7f/MSzPGG5UCjgvxpngWNNvi9O80YyPNNG6hcDjdcEh3iLOJJ C3pyViSuF89dS09//73d7XAwDgo7aHyq/V5E8lteZ0HGGqYFRNX2tpws3NF3oS3HbbE+QJgIJgxbga nxJH1xyP+CeNhMgwGtPLBqvH148173xyjSbfE91W1+DFxpNy3nQYbe5atmnZqCXH3Q0hkutMwRWOAT 3k2ET2Ls5Od0xN4bd3Rwwo/YyAfPqrg==
ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.173; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=FcjAaMS1DO8NqnRTYL/6KHEij6zFnlm/6ka43/c4WB4=; b=lgvH7Hfp1xlzpRXYPLiRchERACVUjDmTfA6PolHH6CUSH8tpnGzBTrOwEMZP9d2TVjtANCre8sqh1 lBdyLF0Y2eHwsxQCiBzVUEojCB66h8kabUZFmonDTgxdyyUzCAL+WnMH3nk4UXjTRt8p6U1jjrtpoP 2EF93s/ErAOhiw8I=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=FcjAaMS1DO8NqnRTYL/6KHEij6zFnlm/6ka43/c4WB4=; b=Vd5hmFdYo8SYcsvFGOIFawyKfjxaSzEEQhIBIBlLAGBodB6Oz6fQO3B3kyqILbU8FTRt2SZkJfK32 W8KbOmWvSa/w8zKpI3aTJCZQwexJHq+eZHyRAnnreANQe0jCw1c4jxOGDKSdeoAPtserk+rYmGoqW2 Nb4nIqKCuqS8SgsIDG8eNMHVZ3mVncNe3nsYqxIvFpbDD/OP0q7R/xOa6/3wqu7laFlMRL+tey4gwk 1LC9CIVIenUq/rhPOJ9gpS9YTJE3M/Z0tDEbaT9CUHxS3LKoBiLAWErUlZZiai8Jk5Y+nKhxeekrKK uT12FUjgMI+Edtzw0XBcTbbtCVM8DUA==
X-MHO-RoutePath: bWNtYW51cw==
X-MHO-User: fca4ac56-4ed2-11e9-befd-af03bedce89f
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 209.85.167.173
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from mail-oi1-f173.google.com (unknown [209.85.167.173]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id fca4ac56-4ed2-11e9-befd-af03bedce89f; Mon, 25 Mar 2019 07:52:50 +0000 (UTC)
Received: by mail-oi1-f173.google.com with SMTP id 3so6192991oir.7; Mon, 25 Mar 2019 00:52:50 -0700 (PDT)
X-Gm-Message-State: APjAAAW2Ixhy6fdEP9NRry+RtqHvYsEjfZNbDQJ9AXnwECyCpixSCjoP gcs3cm81KsHtQ0D4+9V6gj9iGzk2TcR2yCZiSkA=
X-Google-Smtp-Source: APXvYqwAXHuzDh3jkCsVxOnPhqoIsbMQSeuQtabHXsnbyuTD7yZZyR+YHpPcZhoay4Ab4zv0SBnvxEtY6kNXvEdyPMk=
X-Received: by 2002:aca:e350:: with SMTP id a77mr11028180oih.82.1553500369787; Mon, 25 Mar 2019 00:52:49 -0700 (PDT)
MIME-Version: 1.0
References: <04C556AF-D3B3-41A5-B119-8FE5F81FB9A7@huitema.net> <1878722055.8877.1553241201213@appsuite.open-xchange.com> <CABcZeBPmpN-cEPK92QQW3bkvc41Cx5g7B_YuUXCJK3j1qF995Q@mail.gmail.com> <20190322.101434.307385973.sthaug@nethelp.no> <32A78B0C-52B6-46E5-A46F-D63D21DEC52C@sky.uk> <CAOdDvNqb2+4Az+g608QRjYt+ZdUt1L9GAc=MJM3-xd0ZNmeBEQ@mail.gmail.com> <1C720263-10E4-423B-B152-5673E115A4C1@gmail.com> <CAOdDvNrQiM2bpi65tCvwjanQTM1KtcZjRL0aOwS2oAryTR-YEA@mail.gmail.com> <E7E54A3B-4C85-4B64-BEFD-51891534DC9D@gmail.com>
In-Reply-To: <E7E54A3B-4C85-4B64-BEFD-51891534DC9D@gmail.com>
From: Patrick McManus <mcmanus@ducksong.com>
Date: Mon, 25 Mar 2019 08:52:38 +0100
X-Gmail-Original-Message-ID: <CAOdDvNqKja9SRWa7FpjnGR3XZbVwZbitoU0yuWc+oXw3xXFEQA@mail.gmail.com>
Message-ID: <CAOdDvNqKja9SRWa7FpjnGR3XZbVwZbitoU0yuWc+oXw3xXFEQA@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, "Winfield, Alister" <Alister.Winfield=40sky.uk@dmarc.ietf.org>, Eric Rescorla <ekr@rtfm.com>, "doh@ietf.org" <doh@ietf.org>, "wjhns1@hardakers.net" <wjhns1@hardakers.net>, "dnsop@ietf.org" <dnsop@ietf.org>, "huitema@huitema.net" <huitema@huitema.net>, "vittorio.bertola=40open-xchange.com@dmarc.ietf.org" <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b321540584e67de5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EPvPPwnEuF6Zoc4p_UqznwibQNI>
Subject: Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
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: Mon, 25 Mar 2019 07:53:00 -0000

I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.

One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable, perhaps in the minds of some even desirable,
signal for DoT to trigger downgrades and, further, that clients are
obligated to create a clear signal to the network to enable this approach.
One issue is that you cannot differentiate this signal between a party you
may want to cooperate with (e.g. your enterprise controller) and an
attacker - that's the nature of an unauthenticated injection. But there are
authenticated enterprise configuration methods available for expressing
policy directly to the client in a trusted way. Indeed my post centered
around the notion of https interception being a necessary outcome of DoH in
the enterprise - my point is basically if you can do https interception
then you are doing enterprise config - consider a config to still do
secured DNS with a server that implements the enterprise policy rather than
doing interception.

And if you do that an enterprise client can, by using its own do{th}
server, also enjoy the benefits of transport security and be confident that
the policy server it intends to use is actually the one in use.

fwiw - there are lots of reasons an http client is going to be interested
in an http substrate beyond just traffic analysis defense. It has the
potential for better overall application responsiveness - by sharing
connections and handshakes with other http data. I don't think that
particular discussion is important to this thread.

On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <brian.peter.dickson@gmail.com>;
wrote:

>
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 10:42 PM, Patrick McManus <mcmanus@ducksong.com>;
> wrote:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dickson@gmail.com>; wrote:
>
>>
>> This is important for network operators in identifying encrypted DNS
>> traffic,
>>
>
> not all clients acknowledge a network's right to do such things at all
> times. And of course it would be useful to tell the difference between
> policy and a RST injection attack.
>
> If the client does acknowledge the network has the right to set policy -
> then the policy can be set on the client using existing configuration
> mechanisms that allow the client to differentiate between authorized
> configuration and perhaps less-authorized folks identifying their DNS
> traffic. This is well worn ground in the HTTP space.
>
>
> What I find interesting, is that as far as I can tell, everything you
> wrote applies equally to DoH and DoT, if the transport is the only
> difference. E.g. Same client browser, same DNS service, accessed via DoH or
> DoT.
>
> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>
> Brian
>