IETF Logo Mail Archive

Re: [dns-privacy] [Ext] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

Tommy Pauly <tpauly@apple.com> Thu, 18 March 2021 16:03 UTC

Return-Path: <tpauly@apple.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 99DAD3A2E76 for <dns-privacy@ietfa.amsl.com>; Thu, 18 Mar 2021 09:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 bwunleiPg2zd for <dns-privacy@ietfa.amsl.com>; Thu, 18 Mar 2021 09:03:30 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (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 F0B923A2E74 for <dns-privacy@ietf.org>; Thu, 18 Mar 2021 09:03:29 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 12IFsMkl012202; Thu, 18 Mar 2021 09:03:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=REQS8QgqpMDb3wYk0fZyAZzDgotQEMO74EB5N1YJ8Ls=; b=cLiMEsRSqHROsYcDnq8QmAfe+8ZQX+60rV0NkJCCnvEKvhfpKcu7eZN34n5eCkPHI+8l jH/joxMGvuiVXKYxYvgHc4XQUSsurre+eMWR6cwKWcEnkJva0LO05YV7z4U8DLx0ZE+T jBGUWLY20cYvtOgXxtsJLGCWDLw9MRvr+8NrKadcfttSKvSv0ID1Hov2qyJFhIZ0nFDT LiLpWXEbu0UIwfDvp7ksHs/EAiFQZYsmQwtkY3psM18KIW//+Lk1ROxlsTAEAX7yVpb+ oOwrs5EiqjTl3EeEEGG6wui+htJa6cKb/fi0ORuN5rmLLqqdNyxANvOQs3DvlfIYZP5N vw==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 378w9107sd-13 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 Mar 2021 09:03:05 -0700
Received: from rn-mailsvcp-mmp-lapp02.rno.apple.com (rn-mailsvcp-mmp-lapp02.rno.apple.com [17.179.253.15]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QQ6006L49X1U340@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 18 Mar 2021 09:03:01 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp02.rno.apple.com by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QQ6003009SBC400@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 18 Mar 2021 09:03:01 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 08515f0f673f2f6b257e63c6378fe83f
X-Va-E-CD: f9c92b7830167ad49deb44d65e2cce2e
X-Va-R-CD: 6d3b66ae25a925084ecb00a96e0c7ea0
X-Va-CD: 0
X-Va-ID: 872a5079-c45a-4211-b74c-26d2cb56550f
X-V-A:
X-V-T-CD: 08515f0f673f2f6b257e63c6378fe83f
X-V-E-CD: f9c92b7830167ad49deb44d65e2cce2e
X-V-R-CD: 6d3b66ae25a925084ecb00a96e0c7ea0
X-V-CD: 0
X-V-ID: 50642d5a-1180-4c8c-8fd2-17f9f041bc08
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-18_09:2021-03-17, 2021-03-18 signatures=0
Received: from smtpclient.apple (unknown [17.234.31.74]) by rn-mailsvcp-mmp-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QQ600GGD9X07100@rn-mailsvcp-mmp-lapp02.rno.apple.com>; Thu, 18 Mar 2021 09:03:01 -0700 (PDT)
Content-type: text/plain; charset="utf-8"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3668.0.5\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <27817649-FD99-49E6-8D5B-6B3CC6E16BE6@icann.org>
Date: Thu, 18 Mar 2021 09:03:00 -0700
Cc: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <EB6831B6-6B4A-4D73-9FC2-E3B7037B1263@apple.com>
References: <1a1ef163-bef8-0726-8e51-e444e8fe6091@innovationslab.net> <CABcZeBP0WW_zVNAPjDJWr8zWzj-jStObHhBpJEjwsdCtkEtY_w@mail.gmail.com> <A22D0935-ABB2-447A-BEED-B10C1EAEFB88@apple.com> <27817649-FD99-49E6-8D5B-6B3CC6E16BE6@icann.org>
To: Paul Hoffman <paul.hoffman@icann.org>
X-Mailer: Apple Mail (2.3668.0.5)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-18_09:2021-03-17, 2021-03-18 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/GvEZffopCssvRKgLKUajyeoYZFE>
Subject: Re: [dns-privacy] [Ext] WG Call for Adoption: draft-pauly-dprive-oblivious-doh
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: Thu, 18 Mar 2021 16:03:33 -0000


> On Mar 18, 2021, at 8:41 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
> On Mar 17, 2021, at 7:37 PM, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:
>> 
>> As an author, I support adoption as experimental. To Paul’s email, I also am quite happy to have change control governed by the WG.
> 
> Great, but:
> 
>> To the OHTTP discussion, I’m fine with having the direction be to use OHTTP for ODoH, but I personally believe that even in the best case, the timelines and deployment considerations make it more practical to have an experimental ODoH ship prior to a version that uses OHTTP.
> 
> This makes no sense. If you have a non-standard experimental spec that you are already implementing, but a forthcoming different spec whose base is being developed in another WG, you asking people to work on the will-be-obsoleted protocol wastes many people's time. 

I am personally not sure that deployments that want to support ODoH would necessarily want to use a generic OHTTP solution, for two reasons:
- A proxy for ODoH can know that it is proxying a message of a very specific media type that is specific to DNS. An OHTTP proxy may have no way to know what the content is, and can become a completely open proxy.
- A DoH server that wants to support ODoH can add support for the HPKE transformation to the bodies of the messages it transmits, without having to implement a new HTTP stack that has a separate way of formatting all the HTTP messages.

This is what I was referring to as the deployment considerations, and I think that they make the simple ODoH approach not a waste of time or something that would be obsoleted anytime soon—some day, yes, if OHTTP becomes ubiquitous and deployment models are worked out, but that will take time even if OHTTP formatting is defined soon.

Tommy

> 
> If you want to just document what you are doing now, take your draft to the Independent Submission Editor as informational. The ISE will ask if you got external reviews, and it is quite reasonable for you to ask for those reviews.
> 
> Now that I understand the authors' intentions better, I withdraw my support for adoption.
> 
> --Paul Hoffman_______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

v2.23.0 | Report a Bug | By Email