IETF Logo Mail Archive

Re: [Doh] Reviewing Resolver-Associated DOH

"Hewitt, Rory" <rhewitt@akamai.com> Fri, 15 March 2019 16:54 UTC

Return-Path: <rhewitt@akamai.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E7212D4EC for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 09:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.85
X-Spam-Level:
X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, 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=akamai.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 CM4Whso8ELc7 for <doh@ietfa.amsl.com>; Fri, 15 Mar 2019 09:54:20 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 CE54112705F for <doh@ietf.org>; Fri, 15 Mar 2019 09:54:19 -0700 (PDT)
Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2FGlScl019492; Fri, 15 Mar 2019 16:54:18 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=YrthzAnUZmPEYtL9uvCEsdfJeNCNb0/rf6TfC8pfXrM=; b=QvAj9NXrlqxJcKXexeoBUnzl3OGm8pPQOsP5fcePl9/VVavYBLVBdSGMw2LWwuSyWW+a SVr6+31hmloftBePQDq4bIlLLv/MDqceXIKMx6ChBjH6qOqbhkig21xg21AmbeZyuOpb MtQsexHyYnNjuaFAycBCpIuTJnWvi3e7dHRUMB0faNnmneLeaIWkEjo7uGEOAihPAkbG gkW0EE4ykGPgJFHBbVx5Tv7j1dbGVWUD/kn6c8/qiQOv9+2Y53dtKyjrEfPY/MS5rm7y vWlNAUytYk6NbS/XD4FL0PjNGZ6wJ00koY6MW+W931V7NabQYgfNbWXGMQ4YZeAQ2018 6w==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2r8cnr107q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Mar 2019 16:54:17 +0000
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x2FGlG7u009207; Fri, 15 Mar 2019 12:54:17 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2r49q0yc8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 15 Mar 2019 12:54:16 -0400
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 15 Mar 2019 11:53:22 -0500
Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1473.003; Fri, 15 Mar 2019 11:53:22 -0500
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, DoH WG <doh@ietf.org>
Thread-Topic: [Doh] Reviewing Resolver-Associated DOH
Thread-Index: AQHU2zDf0C46PZ1RqE+PSQesFzBXNqYM5Zdg
Date: Fri, 15 Mar 2019 16:53:21 +0000
Message-ID: <c1bf24e9731d481caed07e0c5f11e89e@ustx2ex-dag1mb3.msg.corp.akamai.com>
References: <CAHbrMsCNyeabhk0sVexOHVedVkgG2dvV9T8wWL++om5juAUvEw@mail.gmail.com>
In-Reply-To: <CAHbrMsCNyeabhk0sVexOHVedVkgG2dvV9T8wWL++om5juAUvEw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.28.212.170]
Content-Type: multipart/alternative; boundary="_000_c1bf24e9731d481caed07e0c5f11e89eustx2exdag1mb3msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-15_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903150119
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-15_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903150119
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/PcX0wHIDVFKBrjiWq-Tq_Gwfeq4>
Subject: Re: [Doh] Reviewing Resolver-Associated DOH
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Mar 2019 16:54:23 -0000

Ben,

Comments inline:


  1.  IP-address certificates



No position



  1.  A new .well-known endpoint



As with all /.well-known/ endpoints, the issue is both standardization and publicization. AIUI, @mnot's original ideal would be to have /.well-known/ be pretty 'generic'. Therefore I'm not a fan of "/doh-servers-associated/" - I'd much rather see "/dns/doh/", which would enable other (future) DNS-related functionality to have a sub-folder within "/.well-known/dns/". If that's not a possibility, what about "/.well-known/dns-doh/"?



  1.  JSON



Not sure of the question here. Are you asking about the format JSON should take, or whether JSON is a 'good idea'? Yes to the latter.



  1.  Recursive resolvers synthesizing responses as if they were authoritative for certain names



No position



  1.  Machine-readable content in a TXT record



As with #3, good idea, but not sure of the exact question.



Finally, I think the spec should contain examples of a 'proposed' JSON response and of the format of a TXT RR. Without examples (even where marked as "unofficial proposal"), it's much harder to read by those who didn't write it.

Rory

From: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Sent: Friday, March 15, 2019 6:13 AM
To: DoH WG <doh@ietf.org>
Subject: [Doh] Reviewing Resolver-Associated DOH

I'd like to thank the working group participants for the extensive discussion of our most recent drafts.  However, I would appreciate more review of the Resolver-Associated DOH draft, which has the largest time segment allocated for the upcoming meeting.  This draft contains several components that have been controversial in the past:

1. IP-address certificates
2. A new .well-known endpoint
3. JSON
4. Recursive resolvers synthesizing responses as if they were authoritative for certain names
5. Machine-readable content in a TXT record

Also, the draft does not enable the use of DoH if (1) an application relies on POSIX-like DNS APIs to bootstrap AND (2) the resolver is only reachable on a non-public IP address (e.g. RFC 1918).  This is a side effect of the requirement that the DoH server provide a valid certificate for its name, chained to a root that is already trusted by the client.  This draft does not alter that requirement.

If any of these technical elements are of concern to you, please comment now, so that the meeting can be as productive as possible.

--Ben

v2.23.0 | Report a Bug | By Email