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

Vittorio Bertola <vittorio.bertola@open-xchange.com> Sun, 10 March 2019 23:07 UTC

Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47882126C87 for <dns-privacy@ietfa.amsl.com>; Sun, 10 Mar 2019 16:07:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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] 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 tGugCemFXqze for <dns-privacy@ietfa.amsl.com>; Sun, 10 Mar 2019 16:07:46 -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 DAECD12797C for <dns-privacy@ietf.org>; Sun, 10 Mar 2019 16:07:45 -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 2D7C86A27C; Mon, 11 Mar 2019 00:07:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1552259263; bh=GEF2j7VFN+6KFA+SzMD4d4BblysUVct82YxLVXEwkZM=; h=Date:From:To:In-Reply-To:References:Subject:From; b=tBB4cyXEh4S3kdeZGMknmy+MH1lzOgje6DtQE7L1vpBcu/nYgKPUj0c/vZDZTbFGl Y5CB/hn6gBQFWBzFh9H1UEJap4FmqSTJs42xlq3Y86PV/UjGG75JGPC6S0LReDu5Iq PAUHO96C6Cwp2fEL0zCYxfU6f6ubcf2oJsDczgp5xYTeBhQXScZ9+B2khcxCLk9zdd +ZzHJVg7xiiZ0O1UisXh56FLxa3d2t5kHi62XEAEX4hIvCBY6JDVIzdYlwuRL7TLuY NPM+/t/kkVnh7IeeHz7qFYITdhxSRS1QCZa7B/4TOwYGpaGq3l0xZ5BJ7J4XvCCdVB 6nIAASgS6zZLg==
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 1EDC73C0734; Mon, 11 Mar 2019 00:07:43 +0100 (CET)
Date: Mon, 11 Mar 2019 00:07:42 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Vittorio Bertola <vittorio.bertola=40open-xchange.com@dmarc.ietf.org>, dns-privacy@ietf.org
Message-ID: <1991054337.12802.1552259263075@appsuite.open-xchange.com>
In-Reply-To: <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie>
References: <1700920918.12557.1552229700654@appsuite.open-xchange.com> <7667c4d7-2e78-0a27-84af-cf1c00fd4897@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_12799_1174367387.1552259263052"
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/dns-privacy/w8-_U8B_tqFuUlXENIR6m6bcZt0>
Subject: Re: [dns-privacy] New: draft-bertola-bcp-doh-clients
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 23:07:49 -0000

>     Il 10 marzo 2019 alle 16.44 Stephen Farrell < stephen.farrell@cs.tcd.ie mailto:stephen.farrell@cs.tcd.ie > ha scritto:
> 
> 
> 
>     Hiya,
> 
>     On 10/03/2019 14:55, Vittorio Bertola wrote:
> 
>         > >         Hello all,
> > 
> >         this new document has been allocated 10 minutes in the dprive agenda
> >         in Prague.
> > 
> >     >     I really hope someone's going to arrange one venue for these
>     discussions. Could be a bit of a mess otherwise between dprive,
>     doh, dnsops, suggested side meetings and the pivo club:-)
> 
I totally agree, and this is the first expected outcome. I am also wondering whether a side meeting in Prague would be useful, perhaps just focusing on this specific question.

> 
>     1. I don't think your characterisation of DNS n/w-selection
>     vs. application-selection is accurate. IIUC, what's actually
>     done by FF is that (if the user has explicitly turned on DoH)
>     then FF tries all the resolvers it knows about and figures
>     out which to use based on the results and timing it sees.
> 
Honestly, I understood it differently - at this point in time they are doing tests on whether their resolver performs better or worse than the system's one, but their announced model is that Firefox will adopt a DoH resolver (though it's unclear how it will be chosen) and it will just use that one. But if people from Mozilla could make a clearer announcement on what their plans currently are, that would be good. Still, most of the issues arise whenever an application, for whatever reason and under any mechanism, starts to use one or more resolvers different than the one set up in the operating system: even if it used more than one, you would still get many of the issues listed in the document (though, if it used more than one at the same time, I think you'd actually also get some new specific issues, so we'd need to add a discussion of this possibility).

>     2. I may have missed it, but where in your document is the
>     bit that says that applications and system libraries SHOULD
>     prefer DoT/DoH or similar over cleartext DNS?
> 
The document is a best practice for clients already having decided that they are going to use encrypted DNS protocols, much like the one by Sara and others is for operators already having decided to provide encrypted DNS resolvers. But I am of course in favour of such a recommendation, so I would be happy to add it on top, if we think that this is the right place.

>     (And maybe that
>     DNS operators SHOULD provide DoT/DoH services?)
> 
That one would be for a draft for DNS operators :-)

>     ISTM that
>     such a recommendation would be needed before you can really
>     ask applications (who've concluded that cleartext DNS is
>     undesirable) to follow the kind of recommendations you
>     describe.
> 
I think it also works the other way round: IMHO it is much easier to get consensus on the basic recommendation you describe above if you have additional recommendations that make a lot of people less nervous about the potentially damaging consequences of a mass switch to encrypted DNS. This is actually a motivation for the document, as stated at the end of the introduction.

Thanks for the comments!

Ciao,
-- 
Vittorio Bertola
Head of Policy & Innovation

Cell: 	+39 348 7015022
Direct Chat: 	vittorio.bertola https://chat.open-xchange.com/direct/vittorio.bertola
Email: 	vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com

Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange https://www.facebook.com/OpenXchange - Web: www.open-xchange.com http://www.open-xchange.com
Open-Xchange AG, Hohenzollernring 72, 50672 Cologne, District Court Cologne HRB 95366
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718
Managing Director: Frank Hoberg

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA

Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.