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

Vittorio Bertola <vittorio.bertola@open-xchange.com> Sun, 24 March 2019 22:14 UTC

Return-Path: <vittorio.bertola@open-xchange.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 B5F0E12015E; Sun, 24 Mar 2019 15:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.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 xgzR64k56keN; Sun, 24 Mar 2019 15:14:03 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 0D26012015F; Sun, 24 Mar 2019 15:14:02 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 952F96A277; Sun, 24 Mar 2019 23:13:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1553465639; bh=joWe2EVIVvMfA6N/oVQ1N1QyZjeuPKNHHiufPO0akB4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=li9L8FMYsbvO3JgOSdoSUpuTjoLH5QOZVQ+sMvfL4ONukFa4I3AFipqdR9lk2BT3w cHwb+NjMa5+YoU58kP49iERUUs3sWgj95CJ99b7lbTVBDyCiPy1fZFybblwHKec2bY 7YxE9OllZ3ZFhI1NCFhK3EOJZyYaf/8TiqjODAb7gVTKRH33rD45QhiigN8zu1CFwY AI71vazvJgrvaTiwdb6v1hCK/LVWS9ATpJc4wr7QmZR5GrgZPylGIJDzCTGQesZrTY eiZTaVvTcmm7ZZhYU+NUXyUJ/Uh5d2aLCVf3t7GPlHJO66I+24dWH+w0U0lDtfGllX icQyRpdqyo9Jw==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 7BC6C3C0019; Sun, 24 Mar 2019 23:13:59 +0100 (CET)
Date: Sun, 24 Mar 2019 23:13:58 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Patrick McManus <mcmanus@ducksong.com>
Cc: dnsop@ietf.org, doh@ietf.org
Message-ID: <128237212.13389.1553465639438@appsuite.open-xchange.com>
In-Reply-To: <CAOdDvNrQiM2bpi65tCvwjanQTM1KtcZjRL0aOwS2oAryTR-YEA@mail.gmail.com>
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>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_13388_1300451080.1553465639431"
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev9
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/d8_HjOP673CbRBpCIYyPJIHMm6U>
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: Sun, 24 Mar 2019 22:14:06 -0000

> Il 24 marzo 2019 alle 22.42 Patrick McManus <mcmanus@ducksong.com> ha scritto:
> 
> 
>     On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < brian.peter.dickson@gmail.com mailto: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.
> 
Let's say I just bought a new smart TV that can browse the Internet, but I don't want my kids to be able to access inappropriate websites from it. Or, let's say I actually like the fact that my operator filters out malware destinations at the DNS level and I want my new TV to have that protection as well.

In today's "plain DNS" world, I choose a DNS resolver that provides that kind of filters for me, I set it up on my router, and my router pushes it to my smart TV via DHCP. What is the "existing configuration mechanism" that allows me to set this policy in the DoH world, i.e. if the TV came equipped with applications preconfigured to use their own remote resolver via DoH?

As a minimum, I would have to open all the applications and configure them one by one to use my desired resolver, and repeat this for every device connected to my network - while in the current situation this is all automated after I configure the resolver once on my router. But applications like Firefox might completely refuse to use the resolver I want, advertised by my router on my behalf, because it does not support DoH, or it does but is not on their list of "trusted resolvers". And Javascript bits in the pages I visit might use DoH to pre-encoded servers without even offering me any configuration.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy