From nobody Thu Feb 1 11:15:09 2018 Return-Path: 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 15A6812EC79; Thu, 1 Feb 2018 11:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 h-0MiWeTRJcb; Thu, 1 Feb 2018 11:14:56 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C4812EC6E; Thu, 1 Feb 2018 11:14:55 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id f3so7850048wmc.1; Thu, 01 Feb 2018 11:14:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Y3hmKvzaiEauLquezCPquvYT9g/kBKM3ERZESLSy2xk=; b=VGHX524L2+oHSnic41F4kXqSy6mihnsUoCqDbXC5mj9dsSJSD/ywAsmEmHK3f4vpVa GVU2Idfq5WT6lHYcSDRXJvWgXF9rsoygfPQGv7EdnEwCtmulHRQpE0aZFyrPALnPi5Jb xzqVfpFSn7Zl+8TN+pLmiPS9CQnrYpIRzRUtCfDh/GiUv1O0UmtpbVbx2OvNm5+S2yOw xHsy1lXDvGXxLmFDyDcAb/vGlmn7EdT5npMmAl7cm4HcoQil699u85FabY7FT5jMI3sc EiJvET/dFkIGyrMbCHWkzkbSqJhzELs5A32iVjVua5LO2mD3EMoOEvZMNA1ZHVeOcm6p UtiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Y3hmKvzaiEauLquezCPquvYT9g/kBKM3ERZESLSy2xk=; b=k44OogiqEyKireHy2j/RlnPGdPQxQ9vvKnD3DT79vH83oSRAry+IwoVGXCWGl7VPNM txj7gAFp7vNbt9xQUwF0Q1j9LQw9ROMC4PBcRgVMdoG8fcVLaHTqlRDouK6BGbDM/WKT mmNtNEdQNYlkFSbc2kVaxwGl82mKjrjXtCEyjTAv6po+VS5gCf6V0jD1kRQpC3NReTRY p8InD3aK8mx8MdpMuGWEXhnYrXJ6HOUEOMDmNJumvJPyOsnsk1vkdo2oDU/VKVQVU3eR atmXZAX8/YzVrZWA6vS77qYZLo3e87hrEZE9Enm92Ft9enB9YTElXBC+HpBWjK4E3I1/ JCdw== X-Gm-Message-State: AKwxytdMzXpVfgMX8110Zpui9g1PgjWJieUV+QMH8B+0sO+iol0QFnig mWR/xvgpArjzCo14tpgkO29UZYkbbqMAcH4wIEa5nQ== X-Google-Smtp-Source: AH8x224qsjXm/dF7dh1rjsKoIDkVFfkWOCV9W5CcdkAnSZNYKAPkFApxa3G4ZNw2nDWBJlZwOFDRBxIRbQb0Zn867O4= X-Received: by 10.28.191.148 with SMTP id o20mr28068113wmi.63.1517512494053; Thu, 01 Feb 2018 11:14:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.132.66 with HTTP; Thu, 1 Feb 2018 11:14:53 -0800 (PST) From: tjw ietf Date: Thu, 1 Feb 2018 14:14:53 -0500 Message-ID: To: dnsop Cc: dnssd@ietf.org, doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c071aa0267d9805642b6985" Archived-At: Subject: [Doh] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:14:58 -0000 --94eb2c071aa0267d9805642b6985 Content-Type: text/plain; charset="UTF-8" This starts a Working Group Last Call for draft-ietf-dnsop-session-signal Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons. We are doing a three week Working Group Last Call process, and we're cross posting to a few groups where we hope to receive some strong reviews. This WGLC ends at midnight, 22 February 2018. thanks Tim/suzanne --94eb2c071aa0267d9805642b6985 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This starts a Working Group Last Call = for=C2=A0draft-ietf-dnsop-session-signal

Current v= ersions of the draft is available here:

Pl= ease review the draft and offer relevant comments. Also, if someone feels t= he document is *not* ready for publication, please speak out with your reas= ons.

We are doing a three week Working Group Last = Call process, and we're cross posting to a few groups where we hope to = receive some strong reviews.=C2=A0

This WGLC ends = at midnight, 22 February 2018.

thanks
Ti= m/suzanne
--94eb2c071aa0267d9805642b6985-- From nobody Fri Feb 2 11:20:54 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89274127011; Fri, 2 Feb 2018 11:20:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151759925251.16959.1188783180075188489@ietfa.amsl.com> Date: Fri, 02 Feb 2018 11:20:52 -0800 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-03.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 19:20:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-03.txt Pages : 16 Date : 2018-02-02 Abstract: DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. [[ There is a repository for this draft at https://github.com/dohwg/ draft-ietf-doh-dns-over-https [1] ]]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 2 11:22:50 2018 Return-Path: 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 3ADDC12AAB6 for ; Fri, 2 Feb 2018 11:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 w-CBuqUZstOj for ; Fri, 2 Feb 2018 11:22:47 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC08127011 for ; Fri, 2 Feb 2018 11:22:47 -0800 (PST) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 269953A04F for ; Fri, 2 Feb 2018 14:22:45 -0500 (EST) Received: by mail-oi0-f51.google.com with SMTP id e15so6737719oiy.2 for ; Fri, 02 Feb 2018 11:22:45 -0800 (PST) X-Gm-Message-State: AKwxytdkigWoR5YincvyNsZ2xSyJAb5BRj/Gb15YTC13EGUagkJhsCnx ErK4dcxmLbF60tVCG60I84CE456PQbb5fKibX84= X-Google-Smtp-Source: AH8x226vAnu6FMbDcgOrNpPLVS9xbTopDgg8o3Sd1J3Jc6S1wtFR77/9keIjm8ZKtESrBiWxJovFw0fiJKsCKd+92iA= X-Received: by 10.202.74.143 with SMTP id x137mr12186302oia.101.1517599364765; Fri, 02 Feb 2018 11:22:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.95.80 with HTTP; Fri, 2 Feb 2018 11:22:44 -0800 (PST) From: Patrick McManus Date: Fri, 2 Feb 2018 14:22:44 -0500 X-Gmail-Original-Message-ID: Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="001a1134ebb80c5d5d05643fa350" Archived-At: Subject: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 19:22:49 -0000 --001a1134ebb80c5d5d05643fa350 Content-Type: text/plain; charset="UTF-8" Thanks for taking the time to read the -03. Some of the more important changes to be aware of: * query parameter named body is changed to be named dns * removal of .well known uri * make base64url get encoding dependent on content-type * text describing caching interactions and push trust * some expanded and cleaned up examples of course you should read the draft, comment, and open issues as necessary. That's what we do. There are only a couple of open issues being tracked at this point - https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues -Patrick --001a1134ebb80c5d5d05643fa350 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for taking the time to read the -03. Some of t= he more important changes to be aware of:

* query parameter named body is changed to be named dns
* = removal of .well known uri
* make base64url get encoding depe= ndent on content-type
* text describing caching interactions and = push trust
* some expanded and cleaned up examples
=
of course you should read the draft, comment, and open issue= s as necessary. That's what we do.

There a= re only a couple of open issues being tracked at this point - https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues=

-Patrick

--001a1134ebb80c5d5d05643fa350-- From nobody Fri Feb 2 11:48:54 2018 Return-Path: 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 C488812DA2C for ; Fri, 2 Feb 2018 11:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L8QbCxkjNGEX for ; Fri, 2 Feb 2018 11:48:50 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DDED12D967 for ; Fri, 2 Feb 2018 11:48:50 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id 63so33128123lfv.4 for ; Fri, 02 Feb 2018 11:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rmb93wkQTebtZ1R1weJGfKrwkrJFKY1W6vyUtzJQKOU=; b=ZjGYqwBERlh9fI3VJnaGpNibZLabDvLS0kfoRHPZg2JrP1XkRvYyOasMDUPOesHSRQ 60rPKHeSVqkWY4jqdgNJ4CxQk2QJDOe6uCC7J6Y07vC16bN6l7un9+lI6z/T2TLamYxT QVEtWWEreC76D0nDeCn1N5QkHROkdlhWQuzk+4qxvekHP0xq/Po3a/WG+x2aeKbtxPrx ZnGIST+CSCubYlP7azLIatg7esbLOpI7F+UTMMAJ2KOuhBF2bnoV15c74iEVMx8UifaG xI8BFTjiQuoDA7UkW7LAmZJI5NnEfO7kmUabyFTR+axg5XeMF5353D0J+CirKHEKnaka FpTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rmb93wkQTebtZ1R1weJGfKrwkrJFKY1W6vyUtzJQKOU=; b=oH0qjbhSpkoykUhhsM96+zk9aWTAn2rbRPDEhcjy7RHT4hLSGo6Js/L0aKqFaBAVme WGvwuPYGfKA+0cCG8tAhS9O5ymY1V+72aZgG9t0PVnEXPx/b/cQV5uoaQjmhnT8illC5 bbh7k2pBKGOkBbTiSL78Oh86MmHufcGdjRvwZBSyfHf8lZ+blRgxKpds69gay3zFrFJy JCK+5fCh7UY5bYyw+y8Asi4al1fhs9pERfvUSOughdEl2/MGwI+3LpkYZWgip6yAmXvF sucQ0+2g/MFqNPE3baE2xDdV4jPLGCB7Mvwty/rTuBXiSTLRI2RMvPP2BxHCxfU0O7TL iqcQ== X-Gm-Message-State: AKwxytcS5Nzfk3KBFCWc4+QhYLBVXI69sMrcZoQ0va4xdpGLlNstGHg2 YgbNdmegSB3pvJvXhv7zOviHmnyVhobWz/9w2GM= X-Google-Smtp-Source: AH8x225TkfHwcj3MdEErpq9auFEYXomAcnGsUFfLSazQKjz78qddkwbRKgSX8CBTl0qL7f1KKAuMH5S5W5t9ads4100= X-Received: by 10.25.42.197 with SMTP id q66mr24145150lfq.25.1517600928424; Fri, 02 Feb 2018 11:48:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.169.212 with HTTP; Fri, 2 Feb 2018 11:48:47 -0800 (PST) In-Reply-To: References: From: manu tman Date: Fri, 2 Feb 2018 11:48:47 -0800 Message-ID: To: Patrick McManus Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="94eb2c14aa283fea5c0564400045" Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 19:48:53 -0000 --94eb2c14aa283fea5c0564400045 Content-Type: text/plain; charset="UTF-8" Thanks for providing a Changelog. We should probably have a CHANGELOG in the repo [0] too. A format like [1] makes it easy to track changes and access commits between 2 versions. [0] https://github.com/dohwg/draft-ietf-doh-dns-over-https/ [1] http://keepachangelog.com/en/1.0.0/ Manu On Fri, Feb 2, 2018 at 11:22 AM, Patrick McManus wrote: > Thanks for taking the time to read the -03. Some of the more important > changes to be aware of: > > * query parameter named body is changed to be named dns > * removal of .well known uri > * make base64url get encoding dependent on content-type > * text describing caching interactions and push trust > * some expanded and cleaned up examples > > of course you should read the draft, comment, and open issues as > necessary. That's what we do. > > There are only a couple of open issues being tracked at this point - > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues > > -Patrick > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --94eb2c14aa283fea5c0564400045 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for providing a Changelog.

We sh= ould probably have a CHANGELOG in the repo [0] too. A format like [1] makes= it easy to track changes and access commits between 2 versions.
=

[0]=C2=A0https://github.com/dohwg/draft-ietf-doh-dns-over-https/

Manu

On Fri, Feb 2, 2018 at= 11:22 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:<= br>
Thanks for taking t= he time to read the -03. Some of the more important changes to be aware of:=

* query parameter named body is ch= anged to be named dns
* removal of .well known uri
= * make base64url get encoding dependent on content-type
* text de= scribing caching interactions and push trust
* some expanded = and cleaned up examples

of course you should read = the draft, comment, and open issues as necessary. That's what we do.

There are only a couple of open issues being tra= cked at this point - https://github.com/dohwg/draft-i= etf-doh-dns-over-https/issues

-Patrick


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--94eb2c14aa283fea5c0564400045-- From nobody Fri Feb 2 13:57:49 2018 Return-Path: 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 B64761242EA; Fri, 2 Feb 2018 13:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 bu0WoDM6MgqR; Fri, 2 Feb 2018 13:57:37 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 4C4A61243FE; Fri, 2 Feb 2018 13:57:37 -0800 (PST) Received: from [169.254.45.1] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w12LvF6P079371 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Feb 2018 14:57:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.45.1] From: "Paul Hoffman" To: dnsop Cc: dnssd@ietf.org, doh@ietf.org Date: Fri, 02 Feb 2018 13:57:32 -0800 X-Mailer: MailMate (1.10r5443) Message-ID: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Doh] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 21:57:39 -0000 The current draft is hand-wavy when it comes to which transports DSO can run on. Section 2 says "such as": The term "connection" means a bidirectional byte stream of reliable, in-order messages, such as provided by using DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. Section 4.1 says "are suitable": Standard DNS over TCP [RFC1035][RFC7766], and DNS over TLS [RFC7858] are suitable protocols. The document should explicitly list which protocols are currently acceptable, and say that the list can change in the future based on standards-track documents. Proposed wording for both of these above are: Section 2: The term "connection" means a bidirectional byte stream of reliable, in-order messages. Section 4.1 says "are suitable": DSO MUST be run as standard DNS over TCP [RFC1035][RFC7766] or DNS over TLS [RFC7858]. This list might expand in the future, such an expansion MUST be in standards-track RFCs. Having developers know exactly which protocols can be used is important so that they do not use protocols that they accidentally think are reliable and in-order. For example, the DOH WG is working on a protocol that might initially seem attractive, but it does *not* qualify for DSO. --Paul Hoffman From nobody Wed Feb 7 06:22:20 2018 Return-Path: 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 74B3412D778; Wed, 7 Feb 2018 06:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 Pms7oezrV61B; Wed, 7 Feb 2018 06:22:04 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 00C0F129C6E; Wed, 7 Feb 2018 06:22:03 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 13F682820FF; Wed, 7 Feb 2018 15:22:02 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 0D12928226C; Wed, 7 Feb 2018 15:22:02 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 05D152820FF; Wed, 7 Feb 2018 15:22:02 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id ECCBE6424E41; Wed, 7 Feb 2018 15:22:01 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id DF186401C7; Wed, 7 Feb 2018 15:22:01 +0100 (CET) Date: Wed, 7 Feb 2018 15:22:01 +0100 From: Stephane Bortzmeyer To: tjw ietf Cc: dnsop , dnssd@ietf.org, doh@ietf.org Message-ID: <20180207142201.e3mobmoal43wkh3c@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000002, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.7.141515 Archived-At: Subject: Re: [Doh] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 14:22:08 -0000 On Thu, Feb 01, 2018 at 02:14:53PM -0500, tjw ietf wrote a message of 55 lines which said: > This starts a Working Group Last Call for draft-ietf-dnsop-session-signal After reading -05 : My personal feeling is that it is complicated, with a lot of details. May be separating in two documents, one for the base DSO concept and one for the standards TLV (with their detailed behavior) would have been better. There is a discussion about a possible Privacy section for which I suggest the following text: The intention of this specification is to enable stateful information (connection parameters and DNS data) directly related to the DSO Session to be transmitted. This creates trackable state and prevents queries from coming from successive privacy addresses, as could be the case with regular DNS queries, for a privacy-conscious client. Before using DSO (or any kind of long-lived DNS sessions), this consequence should be taken into account. The risk is partially mitigated by using encryption (which protects against sniffing by a third-party, but not against logging by the server.) The design of new TLV must also avoid adding any information that could make this tracking easier. Now, other points: > There are a myriad of other potential use cases for DSO given the > versatility and extensibility of this specification. I don't really like this sort of sentence. Either we have ideas about these potential use cases and we should write them down, or we don't and we should avoid this sort of very general words (after all, human imagination being what it is, we can be sure surprising use cases will be found.) > If the RCODE is set to any value other than NOERROR (0) or DSONOTIMP > (tentatively 11), then the client should assume that the server does > not support DSO. (Why "should" in lower case?) RFC 1035 being very clear that the rcode from a non-DSO server must be NOTIMP (this is also said in section 4.2.1 of the draft), I suggest to change that to: If the server does not handle DSO at all, it MUST reply with RCODE NOTIMP (4) (this is from RFC 1035, section 4.1.1). Because not all servers will be correct, if the client receives an answer with the RCODE set to any value other than NOERROR (0) or DSONOTIMP (tentatively 11), then the client should assume that the server does not support DSO. > DNS Stateful Operations uses "DSO request messages" and "DSO > response messages". DSO request messages are further subdivided > into two variants, "acknowledged request messages" (which generate a > corresponding response message) and "unacknowledged request > messages" (which do not generate any corresponding response > message). It seems to me that the draft uses "response-requiring messages" as a synonym of "acknowledged request messages" (and "non-response-requiring messages" as a synonym of "unacknowledged request messages"). If I'm correct, it would be better to state it clearly in the terminology section. > 7.1. MESSAGE ID > The table below illustrates the legal combinations: Since there are only four combinations, I do not find this table useful. Last, RFC 5226 (IANA considerations section) is now replaced by RFC 8126 From nobody Wed Feb 7 08:24:19 2018 Return-Path: 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 2DFE412D7F0 for ; Wed, 7 Feb 2018 08:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 fBeofPWBp5Du for ; Wed, 7 Feb 2018 08:24:02 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B981243FE for ; Wed, 7 Feb 2018 08:24:00 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id m11so2363683qtn.10 for ; Wed, 07 Feb 2018 08:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q9FMewqdQx+KfMnYzTh8rqGpFUQkCAz391L6Iio+MmE=; b=DXFZbL6ORZLr0d25Q/DPmcWeT87Vzk1/Gon9VpCetokCsnohDux92ac/QCFszR6/n+ i+Vn4qnyIiTv7yumrPTw7+HQ/hjGbJioW6UgIHwlez15Gc7FPF2pXCQoGRlMf05LR2q7 ao12CJK4YSja2fGnzJfQqTcMHU/t1uF5EbDjHA3OSVKkfuAfWkMxNe9kRM41gwFzz2+x 1oDq6NMEs+as4016H26cEuiPL41oEHTAVwb1mkXcYoJFEbLr6oP5Ke4FMHJnpGVZcf5G JkGlGDVLksbcr3p5o9oUhlPgyTaHSd7ZPvQ5T28NEauwP9f9EVUL5O26hCzoZN9Cqhx7 3HkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q9FMewqdQx+KfMnYzTh8rqGpFUQkCAz391L6Iio+MmE=; b=nngwXmveLCGqVdEIHJ/ht2rKH6qj+j/no9AX4JkX0SZVU/rBRA+xI+duLKDGyAP+kC cv29GE25/a0RSCte+pkYTsYz3P8HjQNRYhAb7ozf2oJ+cK090hv5YWayLkM4W82jXI5m isH0bnxdeM2FnBZTD4sZSNM5Vdt30bXVyZIpIlkSLUFu9Zp4vt+2gzoLLu+p6iUvX3+J ZkUm0Bpc+mwfrYiO2EVnXeOHerVmwFXYZC6w4vaPdxSEfxB1Aw3LtoNY95Rmc+DRTNtq vje+MSlSQK4TQ3vZvog0DsHSIu8V+LGbnngjW/qcE+uoU+oZm5o1NjiFnYfRI7FIxs6F 5deg== X-Gm-Message-State: APf1xPATHimA1OpgQVbXR0pEX3eLVp+RJkWM6XU9Q0Mw8P1kyC719bLo MIDDXvRk5RVPubjKIzdxFWcJKg== X-Google-Smtp-Source: AH8x225WJza/O7omwknq0HHwJiqV9HYORrxdiQDZvBpYgYEPnFuvJPm5KkRBI86M6Skna4HKt8wUzQ== X-Received: by 10.200.49.205 with SMTP id i13mr9633792qte.116.1518020639351; Wed, 07 Feb 2018 08:23:59 -0800 (PST) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d5sm1306334qtd.91.2018.02.07.08.23.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 08:23:58 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0F5470E6-7113-4A8D-8A8B-A299952359E5" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 7 Feb 2018 11:23:57 -0500 In-Reply-To: <20180207142201.e3mobmoal43wkh3c@nic.fr> Cc: Tim Wicinski , dnsop , doh@ietf.org, dnssd@ietf.org To: Stephane Bortzmeyer References: <20180207142201.e3mobmoal43wkh3c@nic.fr> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:24:04 -0000 --Apple-Mail=_0F5470E6-7113-4A8D-8A8B-A299952359E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 7, 2018, at 9:22 AM, Stephane Bortzmeyer = wrote: > The intention of this specification is to enable stateful information > (connection parameters and DNS data) directly related to the DSO > Session to be transmitted. This creates trackable state and prevents > queries from coming from successive privacy addresses, as could be the > case with regular DNS queries, for a privacy-conscious client. Before > using DSO (or any kind of long-lived DNS sessions), this consequence > should be taken into account. The risk is partially mitigated by using > encryption (which protects against sniffing by a third-party, but not > against logging by the server.) >=20 > The design of new TLV must also avoid adding any information that > could make this tracking easier. Thanks for this text. I am pretty happy with it; the only thing I'd be = tempted to change would be the last sentence, which I would state this = way instead: When designing new TLVs, the potential for the TLV to be used as a = tracking identifier should be taken into consideration, and should be = avoided when not required. I say this because in some cases it's perfectly fine to know who you're = talking to; e.g. in draft-sctl-dnssd-mdns-relay-02, I specified the use = of TLS client authentication, because hybrid relays are network = infrastructure. Although this is happening at the TLS layer and not = the session signaling layer, it's effectively the same thing. Your other comments all make sense to me=E2=80=94thanks for the thorough = review and particularly for suggesting text and not just saying "you = should change this text." :) --Apple-Mail=_0F5470E6-7113-4A8D-8A8B-A299952359E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 7, 2018, at 9:22 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> = wrote:
The intention of = this specification is to enable stateful information
(connection parameters and DNS data) directly = related to the DSO
Session to be = transmitted. This creates trackable state and prevents
queries from coming from successive privacy = addresses, as could be the
case with regular = DNS queries, for a privacy-conscious client. Before
using DSO (or any kind of long-lived DNS = sessions), this consequence
should be taken = into account. The risk is partially mitigated by using
encryption (which protects against sniffing by a = third-party, but not
against logging by = the server.)

The design of new = TLV must also avoid adding any information that
could make this tracking = easier.

Thanks for this text.   I am pretty happy with it; the = only thing I'd be tempted to change would be the last sentence, which I = would state this way instead:

When designing new TLVs, the potential = for the TLV to be used as a tracking identifier should be taken into = consideration, and should be avoided when not required.

I say this because in = some cases it's perfectly fine to know who you're talking to; e.g. = in draft-sctl-dnssd-mdns-relay-02, I specified the use of TLS = client authentication, because hybrid relays are network infrastructure. =   Although this is happening at the TLS layer and not the session = signaling layer, it's effectively the same thing.
Your other comments all make sense to = me=E2=80=94thanks for the thorough review and particularly for = suggesting text and not just saying "you should change this text." =   :)

= --Apple-Mail=_0F5470E6-7113-4A8D-8A8B-A299952359E5-- From nobody Thu Feb 8 10:05:27 2018 Return-Path: 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 F0A7B12D7E9 for ; Thu, 8 Feb 2018 10:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 y65GTuUDoRMA for ; Thu, 8 Feb 2018 10:05:23 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41491242F7 for ; Thu, 8 Feb 2018 10:05:22 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id u12so359350ite.0 for ; Thu, 08 Feb 2018 10:05:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=MDLGciv09gVblgmhwbLM3lt4HsSbARyRvsfKpcMyQ3k=; b=r9IfgN+wJuuey0ltr2r51rsDdWuDTfRSReRQOOy33ZQGdHIiBJeL6l4wRE2STBJnNd CJU68VqCGwvG1/BthY/855W1xJlp0a6W16s2FtTjd3J7UWtKEBvLFIixW0+Z45DtBAOn fNhKP5ZXU8yLzu5n01mrZz0ylvyaPJVj1XTSp1WOp9J0hANkxjUNcIOsymhgcsRoVeWe Q386f8GnLBT/2R5ZcZvYjsXNnKT1J4d4eFlUxkjQzvQXsXI+PG6mBeGhKZ9Lj2ubaQfd t6ci72navwrtmtNMMJ5nCb0QWXkLWxahrNCVJE5wdwqNvZSqY+rLE5E5iXSvbpBv+nyy pJ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=MDLGciv09gVblgmhwbLM3lt4HsSbARyRvsfKpcMyQ3k=; b=JcfYqVtD7T3LsizlEtxHS7yA44ydj76u8D55GCuBVd6U1Ht6A7erCCySC2wHJxk/QD ifeG1O74IlFxIyA0qaLic/liwyJrUwN8gLc2m/P0+NxvYY/2UQIp2m3Cf4nP/S1YglHH O6iaUfbSZpBhznRZZbsyKbjOvwXYRGcis4d0w/vQ6AhF2PJN88T+LDFT7eNTnp0ioaUY Akzq0HEGclDByJVDblqXh+YntuRZ8cKQvZsx9zw5cbueSokyuOzLfJ/mDJh+rp8f8q05 rrOsFBo+PVDsa6vys6pkYwF0FJ26SN6zAA9qPWXzxXVZd8QPX9ehUu2VmL1iRw6PsXL0 4uBQ== X-Gm-Message-State: APf1xPA8ysBPpv+2hlI6yHFyKniNJzudhWXByE5CuE2dZb8/CLlhstty 9TX5XA64Fjan7gPf+yauNLu2QqcSu+3Ze5Ho6cVqDfxHhNo= X-Google-Smtp-Source: AH8x226wjj8eKbgkgsft3m/yHI7OUJ5aVoBpF5/Zxw6SiQaNePNY2fj6anE6auOXinDXmRLRwV2w96B+ERVSpyGZkVc= X-Received: by 10.36.26.137 with SMTP id 131mr53915iti.25.1518113120861; Thu, 08 Feb 2018 10:05:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.160 with HTTP; Thu, 8 Feb 2018 10:05:11 -0800 (PST) From: Ben Schwartz Date: Thu, 8 Feb 2018 13:05:11 -0500 Message-ID: To: doh@ietf.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1143ea0a597f160564b74134" Archived-At: Subject: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:05:25 -0000 --001a1143ea0a597f160564b74134 Content-Type: multipart/alternative; boundary="001a1143ea0a4d110f0564b741a5" --001a1143ea0a4d110f0564b741a5 Content-Type: text/plain; charset="UTF-8" Hi all, The authors of draft-ietf-doh-dns-over-https have been making good progress, and a draft-03 is now ready with several changes and clarifications. One important difference is that draft-03 no longer proposes a ".well-known" entry. In draft-02 and prior, clients could check for the presence of a DOH service at the default path, given only the domain name of a server. In draft-03, there is no default path, so clients must be configured with the full URL of the DOH endpoint. Is this change compatible with your use cases? Would this alter the way users interact with your systems? How do you think DOH client configuration should work? Please respond with your thoughts, Ben Schwartz --001a1143ea0a4d110f0564b741a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

The authors of=C2=A0draft-ietf-= doh-dns-over-https have been making good progress, and a draft-03 is now re= ady with several changes and clarifications.

One i= mportant difference is that draft-03 no longer proposes a ".well-known= " entry.=C2=A0 In draft-02 and prior, clients could check for the pres= ence of a DOH service at the default path, given only the domain name of a = server.=C2=A0 In draft-03, there is no default path, so clients must be con= figured with the full URL of the DOH endpoint.

Is = this change compatible with your use cases?=C2=A0 Would this alter the way = users interact with your systems?=C2=A0 How do you think DOH client configu= ration should work?

Please respond with your thoug= hts,
Ben Schwartz
--001a1143ea0a4d110f0564b741a5-- --001a1143ea0a597f160564b74134 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAWzxfJKLyFofJ95pybjX2Z RDeF/0LLCjJXqeAq/si/4jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAyMDgxODA1MjFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAGSezFjOs37jw6qc51QLtlFMOc+Czw8s8+mpSokzB sqEi9ED7tXuOhQHPSAmZ308RwQ0nI+fu69S5bsMQ33S3oLSQdQskorCJKwCi+IXWi0FFS+lHADjp rdHyM+JhD62DHXd0OqG4xo5V4B0Yk1tmOeYTJs2mXscFDuC30z9YZJkA6coYSfOaHg3Kwe4j612g W4H6oy/YrRQJH6lQMXdaldx+nbIpdfWt7v4Z4EEuKFFBVikG5B9+tDjMf+FBzeGDId/1Jdt4lXpH mxSqs6gKo9ESW6b0ai0g1UP0EroHjezHIVR8cwPn1dfzNR/opIEgq+F4lkg7jxMbJvzQD0p7Zg== --001a1143ea0a597f160564b74134-- From nobody Thu Feb 8 10:11:15 2018 Return-Path: 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 499D51270AC for ; Thu, 8 Feb 2018 10:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 X5h92IV_44Mw for ; Thu, 8 Feb 2018 10:11:10 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0101.outbound.protection.outlook.com [104.47.32.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8702412706D for ; Thu, 8 Feb 2018 10:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8AaF7xXUlqE04cXZPYQnEyKBoi4Bn+/4OnByS4SkrDY=; b=kckH4GFLIPYZwYZOsSmOw5fPLcRItWauYouJLNG0M8863Dhw5hgJYs14wZooSzozuDLL6kk6BA2wToHwnizQcyBLWxqOQTf0yJ4LmxSAmVmDxRzj3URifL4UdVYRIvV7uu/WqA2ApZkHbzTlLcXCMHlByDYVqpwNp3YMKiYEpJM= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2574.namprd08.prod.outlook.com (10.173.230.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Thu, 8 Feb 2018 18:11:06 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f]) by MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f%16]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 18:11:06 +0000 From: Mike Bishop To: Ben Schwartz , "doh@ietf.org" Thread-Topic: [Doh] Seeking input on draft-03 Thread-Index: AQHToQdoE8grvM7S4U+nhExCLxbMRaOazTSg Date: Thu, 8 Feb 2018 18:11:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2574; 6:x3ZsFxQE2atvUo4bymlL3ID1+IUsbHoajeEpmDBkkntKQfxBoUqdHQpRq0pUTbbfq1OFo/pxcWfKukRIwQIGRKs2olHwIVNGYY5TCl0G/BScQkzZQhMdtEwxZpiuI6iAw5sB2Dn6uvZhQr2GuxqpNa5nTYnkJDFx1rNIO8cT41nZdnwFQ9h2p3iwdXq81EWNjSH2ae2zASTqcVBML//+8MTUx6sOFtsbZsE6sh3KTgjfVi+4WIxMTXCXKSJVjZGKhIupjMx2oSZm/GUiR4S8JefdP3EqMtpCVQnnmZboSZw1TT7tG8VFRt+9sXE7bXAfKYDJ8RdkfJQRaFiOoSNRjgPQGru8rfGz6j6cYfxgWyPbQor8fttlDAQcwWOtAbke; 5:DSm6Zs0WftnR9xhKMYs9Z6Ohc4DoNER7aGYKnExz/3eVZbNlF+4kc/dJhCZTgcc6sVlh9J44fnwMt7Of0TZNeLD8VYtikXKG+AP/Gt+zrig37pUODZj4I/3RpaaCTADSflrDCn6rMPINP18lQSPuOGbAqvNCdnn53uSRHrZ45BE=; 24:H3uscp+fS8c9oXcFP486YZx3Aiczjo21HhEiuKkwCXlRe7cmvJr9TboC0zwJrQu/e4QCr4D5F8DWdVdWCgIwoYhphaldl1PtEcDf5KPUUQ4=; 7:1OZqUiKQcLNaUruZqXHIkvgBGy1m5Kac1sM5UlthsYzh/L4nFGng5digOhYFz2LP9lEjgkcsjeC2stb87ILGIfFRqrgOPvIx6oGcSCC3PwPvA8PhpTJ2j73u5uTtQcU7PB2JWE85zd/dCMu0RxeqypVNnslaGllWg+EfcqZ0JujSh0z/XUmjoA9xX3pQetIbIYQvt5dauhP9sbmOOQaAC1ol40x+Pdt7oTU9wslnhX/lJMKEvjHGDN6MICB6sJ39 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: df1e4b63-2784-4bb1-b066-08d56f1f5281 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2574; x-ms-traffictypediagnostic: MWHPR08MB2574: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(35073007944872)(150554046322364)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6041288)(20161123562045)(2016111802025)(20161123558120)(20161123564045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2574; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2574; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39380400002)(39830400003)(366004)(189003)(199004)(53754006)(68736007)(5660300001)(53936002)(8676002)(81166006)(81156014)(186003)(2501003)(8936002)(9686003)(53546011)(2950100002)(6246003)(86362001)(5250100002)(102836004)(105586002)(3280700002)(2900100001)(55016002)(6306002)(25786009)(54896002)(229853002)(106356001)(7696005)(478600001)(74482002)(76176011)(14454004)(59450400001)(33656002)(6436002)(3660700001)(99286004)(2906002)(6506007)(790700001)(26005)(97736004)(3846002)(7736002)(74316002)(66066001)(316002)(110136005)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2574; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: MM0w2eTptDWjyeoJMRE6gjqADv21fIUOXI0DN42r88gypNH2AW3pXCTlonJCgKjkJukqSvrrzlhXsZNjU2K5AA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432FFCE097EBBB1279EAC2EDAF30MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: df1e4b63-2784-4bb1-b066-08d56f1f5281 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 18:11:05.8412 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2574 Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:11:13 -0000 --_000_MWHPR08MB2432FFCE097EBBB1279EAC2EDAF30MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaW5jbGluZWQgdG8gdGhpbmsgdGhpcyBpcyBhIHBvc2l0aXZlIGNoYW5nZS4gIFdl4oCZ cmUgdHJ5aW5nIHRvIGRvIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiB0aGUgY3VycmVudCB3b3JsZCBv ZiDigJx0cnVzdCB0aGUgbG9jYWwgRE5TIHNlcnZlciBiZWNhdXNlIHVuYXV0aGVudGljYXRlZCBE SENQIHNheXMgc2/igJ0sIGFuZCBwcm9taXNjdW91cyB0cnVzdCBqdXN0IGJlY2F1c2UgYSBzZXJ2 ZXIgY2xhaW1zIGl0IHN1cHBvcnQgRE9IIHZpYSBhIC53ZWxsLWtub3duIGVuZHBvaW50IGlzbuKA mXQgcmVhbGx5IGFueSBiZXR0ZXIuICBUaGUgY2xpZW50IHNob3VsZCBrbm93IHRoZSBob3N0bmFt ZShzKSBvZiB0aGUgRE9IIHNlcnZlcihzKSBpdCB3YW50cyB0byB1c2UsIGFuZCBpdCBzaG91bGQg YXV0aGVudGljYXRlIHRoZSBET0ggc2VydmVyIGFnYWluc3QgdGhhdCBob3N0bmFtZS4gIElmIGEg c2VydmVyIGhvc3RzIGNvbnRlbnQgYW5kIGFsc28gd2FudHMgdG8gYWxzbyBzZXJ2ZSBET0gsIHRo ZXJlIGFyZSB3YXlzIHRvIHByZXNlbnQgYSBob3N0bmFtZSB0aGF0IGNvdmVycyBib3RoIG5hbWVz IChvciBwcmVzZW50IHR3byBjZXJ0aWZpY2F0ZXMpIG9uIGFuIEhUVFAgY29ubmVjdGlvbi4NCg0K RnJvbTogRG9oIFttYWlsdG86ZG9oLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4g U2Nod2FydHoNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDEwOjA1IEFNDQpUbzog ZG9oQGlldGYub3JnDQpTdWJqZWN0OiBbRG9oXSBTZWVraW5nIGlucHV0IG9uIGRyYWZ0LTAzDQoN CkhpIGFsbCwNCg0KVGhlIGF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1kb2gtZG5zLW92ZXItaHR0cHMg aGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dyZXNzLCBhbmQgYSBkcmFmdC0wMyBpcyBub3cgcmVh ZHkgd2l0aCBzZXZlcmFsIGNoYW5nZXMgYW5kIGNsYXJpZmljYXRpb25zLg0KDQpPbmUgaW1wb3J0 YW50IGRpZmZlcmVuY2UgaXMgdGhhdCBkcmFmdC0wMyBubyBsb25nZXIgcHJvcG9zZXMgYSAiLndl bGwta25vd24iIGVudHJ5LiAgSW4gZHJhZnQtMDIgYW5kIHByaW9yLCBjbGllbnRzIGNvdWxkIGNo ZWNrIGZvciB0aGUgcHJlc2VuY2Ugb2YgYSBET0ggc2VydmljZSBhdCB0aGUgZGVmYXVsdCBwYXRo LCBnaXZlbiBvbmx5IHRoZSBkb21haW4gbmFtZSBvZiBhIHNlcnZlci4gIEluIGRyYWZ0LTAzLCB0 aGVyZSBpcyBubyBkZWZhdWx0IHBhdGgsIHNvIGNsaWVudHMgbXVzdCBiZSBjb25maWd1cmVkIHdp dGggdGhlIGZ1bGwgVVJMIG9mIHRoZSBET0ggZW5kcG9pbnQuDQoNCklzIHRoaXMgY2hhbmdlIGNv bXBhdGlibGUgd2l0aCB5b3VyIHVzZSBjYXNlcz8gIFdvdWxkIHRoaXMgYWx0ZXIgdGhlIHdheSB1 c2VycyBpbnRlcmFjdCB3aXRoIHlvdXIgc3lzdGVtcz8gIEhvdyBkbyB5b3UgdGhpbmsgRE9IIGNs aWVudCBjb25maWd1cmF0aW9uIHNob3VsZCB3b3JrPw0KDQpQbGVhc2UgcmVzcG9uZCB3aXRoIHlv dXIgdGhvdWdodHMsDQpCZW4gU2Nod2FydHoNCg== --_000_MWHPR08MB2432FFCE097EBBB1279EAC2EDAF30MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJltIGluY2xpbmVkIHRvIHRoaW5rIHRoaXMgaXMgYSBwb3NpdGl2ZSBjaGFuZ2Uu Jm5ic3A7IFdl4oCZcmUgdHJ5aW5nIHRvIGRvIHNvbWV0aGluZyBiZXR0ZXIgdGhhbiB0aGUgY3Vy cmVudCB3b3JsZCBvZiDigJx0cnVzdCB0aGUgbG9jYWwgRE5TIHNlcnZlciBiZWNhdXNlIHVuYXV0 aGVudGljYXRlZCBESENQIHNheXMgc2/igJ0sIGFuZCBwcm9taXNjdW91cyB0cnVzdCBqdXN0IGJl Y2F1c2UgYSBzZXJ2ZXIgY2xhaW1zIGl0IHN1cHBvcnQNCiBET0ggdmlhIGEgLndlbGwta25vd24g ZW5kcG9pbnQgaXNu4oCZdCByZWFsbHkgYW55IGJldHRlci4mbmJzcDsgVGhlIGNsaWVudCBzaG91 bGQga25vdyB0aGUgaG9zdG5hbWUocykgb2YgdGhlIERPSCBzZXJ2ZXIocykgaXQgd2FudHMgdG8g dXNlLCBhbmQgaXQgc2hvdWxkIGF1dGhlbnRpY2F0ZSB0aGUgRE9IIHNlcnZlciBhZ2FpbnN0IHRo YXQgaG9zdG5hbWUuJm5ic3A7IElmIGEgc2VydmVyIGhvc3RzIGNvbnRlbnQgYW5kIGFsc28gd2Fu dHMgdG8gYWxzbyBzZXJ2ZSBET0gsDQogdGhlcmUgYXJlIHdheXMgdG8gcHJlc2VudCBhIGhvc3Ru YW1lIHRoYXQgY292ZXJzIGJvdGggbmFtZXMgKG9yIHByZXNlbnQgdHdvIGNlcnRpZmljYXRlcykg b24gYW4gSFRUUCBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gRG9oIFttYWlsdG86ZG9oLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9i PkJlbiBTY2h3YXJ0ejxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAx OCAxMDowNSBBTTxicj4NCjxiPlRvOjwvYj4gZG9oQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFtEb2hdIFNlZWtpbmcgaW5wdXQgb24gZHJhZnQtMDM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhpIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZSBhdXRob3JzIG9mJm5ic3A7ZHJhZnQtaWV0Zi1kb2gtZG5zLW92ZXItaHR0cHMg aGF2ZSBiZWVuIG1ha2luZyBnb29kIHByb2dyZXNzLCBhbmQgYSBkcmFmdC0wMyBpcyBub3cgcmVh ZHkgd2l0aCBzZXZlcmFsIGNoYW5nZXMgYW5kIGNsYXJpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgaW1wb3J0YW50IGRp ZmZlcmVuY2UgaXMgdGhhdCBkcmFmdC0wMyBubyBsb25nZXIgcHJvcG9zZXMgYSAmcXVvdDsud2Vs bC1rbm93biZxdW90OyBlbnRyeS4mbmJzcDsgSW4gZHJhZnQtMDIgYW5kIHByaW9yLCBjbGllbnRz IGNvdWxkIGNoZWNrIGZvciB0aGUgcHJlc2VuY2Ugb2YgYSBET0ggc2VydmljZSBhdCB0aGUgZGVm YXVsdCBwYXRoLCBnaXZlbiBvbmx5IHRoZSBkb21haW4gbmFtZSBvZiBhIHNlcnZlci4mbmJzcDsg SW4gZHJhZnQtMDMsDQogdGhlcmUgaXMgbm8gZGVmYXVsdCBwYXRoLCBzbyBjbGllbnRzIG11c3Qg YmUgY29uZmlndXJlZCB3aXRoIHRoZSBmdWxsIFVSTCBvZiB0aGUgRE9IIGVuZHBvaW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGlz IGNoYW5nZSBjb21wYXRpYmxlIHdpdGggeW91ciB1c2UgY2FzZXM/Jm5ic3A7IFdvdWxkIHRoaXMg YWx0ZXIgdGhlIHdheSB1c2VycyBpbnRlcmFjdCB3aXRoIHlvdXIgc3lzdGVtcz8mbmJzcDsgSG93 IGRvIHlvdSB0aGluayBET0ggY2xpZW50IGNvbmZpZ3VyYXRpb24gc2hvdWxkIHdvcms/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBy ZXNwb25kIHdpdGggeW91ciB0aG91Z2h0cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlbiBTY2h3YXJ0ejxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR08MB2432FFCE097EBBB1279EAC2EDAF30MWHPR08MB2432namp_-- From nobody Thu Feb 8 10:18:22 2018 Return-Path: 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 CCB4712D80F for ; Thu, 8 Feb 2018 10:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FLe7IN0xDssc for ; Thu, 8 Feb 2018 10:18:18 -0800 (PST) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61BCD1242F7 for ; Thu, 8 Feb 2018 10:18:18 -0800 (PST) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 8 Feb 2018 10:18:16 -0800 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Thu, 8 Feb 2018 10:18:16 -0800 From: Paul Hoffman To: Mike Bishop CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] Seeking input on draft-03 Thread-Index: AQHToQg4JPRWKhdW8EC83B7aYTP4NqObVmkA Date: Thu, 8 Feb 2018 18:18:15 +0000 Message-ID: <914B79D6-A755-4672-BCE5-B63E99E4A71A@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: <9CD2B2946D8E16478A00856CD28A14A6@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:18:20 -0000 T24gRmViIDgsIDIwMTgsIGF0IDEwOjExIEFNLCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVm b3UuYmU+IHdyb3RlOg0KPiBJ4oCZbSBpbmNsaW5lZCB0byB0aGluayB0aGlzIGlzIGEgcG9zaXRp dmUgY2hhbmdlLiAgV2XigJlyZSB0cnlpbmcgdG8gZG8gc29tZXRoaW5nIGJldHRlciB0aGFuIHRo ZSBjdXJyZW50IHdvcmxkIG9mIOKAnHRydXN0IHRoZSBsb2NhbCBETlMgc2VydmVyIGJlY2F1c2Ug dW5hdXRoZW50aWNhdGVkIERIQ1Agc2F5cyBzb+KAnSwgYW5kIHByb21pc2N1b3VzIHRydXN0IGp1 c3QgYmVjYXVzZSBhIHNlcnZlciBjbGFpbXMgaXQgc3VwcG9ydCBET0ggdmlhIGEgLndlbGwta25v d24gZW5kcG9pbnQgaXNu4oCZdCByZWFsbHkgYW55IGJldHRlci4gIFRoZSBjbGllbnQgc2hvdWxk IGtub3cgdGhlIGhvc3RuYW1lKHMpIG9mIHRoZSBET0ggc2VydmVyKHMpIGl0IHdhbnRzIHRvIHVz ZSwgYW5kIGl0IHNob3VsZCBhdXRoZW50aWNhdGUgdGhlIERPSCBzZXJ2ZXIgYWdhaW5zdCB0aGF0 IGhvc3RuYW1lLg0KDQpUbyBiZSBjbGVhcjogdGhhdCdzIG5vdCB3aGF0IHRoZSBjdXJyZW50IGRy YWZ0IHNheXMuIEl0IHNheXMgdGhhdCB0aGUgY2xpZW50IG5lZWRzIHRvIGtub3cgKnRoZSBmdWxs IFVSTCB0byB0aGUgRE9IIHNlcnZpY2UqIG9mIHRoZSBET0ggc2VydmVyIGl0IHdhbnRzIHRvIHVz ZS4NCg0KVGhlIGVmZmVjdCBvZiB0aGlzIGlzIHRoYXQsIGlmIGEgdXNlciB3YW50cyB0byB0ZWxs IGl0cyBicm93c2VyIHRvIHVzZSBET0ggb24gZXhhbXBsZS5jb20sIHRoZXkgbmVlZCB0byBrbm93 IHRoZSBmdWxsIFVSTCBhbmQgdHlwZSBpdCBpbnRvIHNvbWUgY29uZmlnIGRpYWxvZyBmb3IgdGhl IGJyb3dzZXIuIE9yLCBwb3NzaWJseSB3b3JzZSwgYnJvd3NlcnMgdGhhdCB3YW50IHRvIGVuYWJs ZSBET0ggd2lsbCBoYXZlIHRvIGhhdmUgYSBsaXN0IG9mIHBvcHVsYXIgRE9IIHNlcnZlcnMgYW5k IHRoZSBVUkwgYXNzb2NpYXRlZCB3aXRoIGVhY2ggc2VydmVyLCBzb21ld2hhdCBha2luIHRvIHRo ZSBwcmVsb2FkZWQga2V5IHBpbm5pbmcgd2Ugc2VlIG5vdzsgdGhhdCBsaXN0IHdvdWxkIGFsc28g bmVlZCB0byBhbGxvdyB0aGUgdXNlciB0byBleHRlbmQgdGhlIGxpc3QuDQoNClVzaW5nIC53ZWxs LWtub3duLyBvciBzb21lIG90aGVyIGZpeGVkIHByZWZpeCB3b3VsZCBtYWtlIGl0IHNvIHRoYXQg Y29uZmlndXJpbmcgRE9IIHdhcyBsZXNzIG9uZXJvdXMgZm9yIHVzZXJzLg0KDQotLVBhdWwgSG9m Zm1hbg== From nobody Thu Feb 8 10:21:29 2018 Return-Path: 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 4FC23127023 for ; Thu, 8 Feb 2018 10:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 CX6BAUnmTVBi for ; Thu, 8 Feb 2018 10:21:25 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 474661242F7 for ; Thu, 8 Feb 2018 10:21:25 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id b198so6775765iof.6 for ; Thu, 08 Feb 2018 10:21:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=47m7NuTBq4vRa8bd6nXaqQyzmMnBVWQTWe5nA4nulPA=; b=N0xTUsKwcHRO5IoIGiJZNJ21Hhx+n3yI2Rg8NE7OXQBDuTjlx+gHRpJDCBtglmjEoY ZX5+ztehcN4X7q9/4ypN8RCxYDeW6br6n5T3IWXA8/lMTvbbVmSJm9JQWA7A9IevXUk/ vYEZ56Nm7/bdhTA81tcKxAsbUich6tiuGjGs7982Jb1LJ6114L7h4GFu/nBA8JhnUDke nCdt7oDdtQXMi+YXSmOOH2GyHnz8xZdMsI9DWwE1yPsldmcvHZN8/RKVyYExu8CCirM9 VA9EfNNOArv+sYHCk/2YxLvCsIJNlJjnqXkxNduovZZvM+qSt9H2K7lF4p/axoLTY7FL LsoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=47m7NuTBq4vRa8bd6nXaqQyzmMnBVWQTWe5nA4nulPA=; b=d24pwZuioucbyinM0CXlTa2EQc5zw6cY3N5miRGud38rG1dJbyXdYaSiL1Ni+swqM1 CQIg1TT4nYHbyh+Bo2LR/pfuemEUgfDJx2rOvlYahkuSlgqUKp/FKI8JLSpdKPcPsJp2 WazkPpDhy/5YJmnidONKk/xafEz/j9HhjXkwqRQC2sDfvwIPRdMFCpJbqG8eoKNzaEox YuFfAdn8mvKxPEuItNCM05xy1VdSh0cxNndISMkTNSwKmfGhvlOuVynlUvFhiL5JybEV RpbV7uF+WVJDiIH4uZxPKG4XikuZi5J3jcmkoN6xtUgPkY9i3I9HPA6pV/u3F5BeKbVP KpBA== X-Gm-Message-State: APf1xPBeuwfrCFk8GxMEBBp6kr4DNxHbKaXtgKDUz60RXJ8zXo4v9N+u edbQnfB2F5Akn6irowfD8ZE5tI8F6NO6GFSWFW/paWlyQ+I= X-Google-Smtp-Source: AH8x2271CRtaHZz2EqW5wVbeJf2co54WjdEHxGL+vjKpVFI8nQJ90d8g6lY5dhwdetqCMV+ozs+oyTOKOtnkX7SC6MA= X-Received: by 10.107.59.66 with SMTP id i63mr54912ioa.220.1518114084195; Thu, 08 Feb 2018 10:21:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.164.160 with HTTP; Thu, 8 Feb 2018 10:21:23 -0800 (PST) In-Reply-To: References: From: Ben Schwartz Date: Thu, 8 Feb 2018 13:21:23 -0500 Message-ID: To: Mike Bishop Cc: "doh@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c068686c1a71e0564b77a74" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:21:27 -0000 --94eb2c068686c1a71e0564b77a74 Content-Type: multipart/alternative; boundary="94eb2c068686b80c7f0564b77a39" --94eb2c068686b80c7f0564b77a39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop wrote: > I=E2=80=99m inclined to think this is a positive change. We=E2=80=99re t= rying to do > something better than the current world of =E2=80=9Ctrust the local DNS s= erver > because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust just= because a > server claims it support DOH via a .well-known endpoint isn=E2=80=99t rea= lly any > better. > To be clear, the draft never proposed promiscuous trust, which would indeed be highly problematic. However, draft-03 does include additional language clarifying this point. > The client should know the hostname(s) of the DOH server(s) it wants to u= se > In draft-03, "knowing the hostname" is not sufficient, because there is no default path for DOH. This is the change on which I am seeking input. > , and it should authenticate the DOH server against that hostname. > Yes, definitely. (I believe the draft is clear on this point, but feel free to suggest improvements.) > If a server hosts content and also wants to also serve DOH, there are > ways to present a hostname that covers both names (or present two > certificates) on an HTTP connection. > > > > *From:* Doh [mailto:doh-bounces@ietf.org] *On Behalf Of *Ben Schwartz > *Sent:* Thursday, February 8, 2018 10:05 AM > *To:* doh@ietf.org > *Subject:* [Doh] Seeking input on draft-03 > > > > Hi all, > > > > The authors of draft-ietf-doh-dns-over-https have been making good > progress, and a draft-03 is now ready with several changes and > clarifications. > > > > One important difference is that draft-03 no longer proposes a > ".well-known" entry. In draft-02 and prior, clients could check for the > presence of a DOH service at the default path, given only the domain name > of a server. In draft-03, there is no default path, so clients must be > configured with the full URL of the DOH endpoint. > > > > Is this change compatible with your use cases? Would this alter the way > users interact with your systems? How do you think DOH client > configuration should work? > > > > Please respond with your thoughts, > > Ben Schwartz > --94eb2c068686b80c7f0564b77a39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be> wrote:

I=E2=80=99m inclined to think this is a positive cha= nge.=C2=A0 We=E2=80=99re trying to do something better than the current wor= ld of =E2=80=9Ctrust the local DNS server because unauthenticated DHCP says= so=E2=80=9D, and promiscuous trust just because a server claims it support DOH via a .well-known endpoint isn=E2=80=99t really any better.

<= /div>

To be clear= , the draft never proposed promiscuous trust, which would indeed be highly = problematic.=C2=A0 However, draft-03 does include additional language clari= fying this point.
=C2=A0

The client shou= ld know the hostname(s) of the DOH server(s) it wants to use


In draft-03, "knowing the hostname&qu= ot; is not sufficient, because there is no default path for DOH.=C2=A0 This= is the change on which I am seeking input.
=C2=A0

, and= it should authenticate the DOH server against that hostname.


Yes, definitely.=C2=A0 (I believe the dr= aft is clear on this point, but feel free to suggest improvements.)
=C2=A0

=C2=A0 If a server hosts content and also want= s to also serve DOH, there are ways to present a hostname that covers both names (or present tw= o certificates) on an HTTP connection.

=C2=A0

From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz
Sent: Thursday, February 8, 2018 10:05 AM
To: doh@ietf.org
Subject: [Doh] Seeking input on draft-03


--94eb2c068686b80c7f0564b77a39-- --94eb2c068686c1a71e0564b77a74 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCClTUL2pNapzTV2/dosxkEC XQJP98Td7g0Czbq84f+S+DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODAyMDgxODIxMjRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAQJGO7R9rxnM2RCh+1JVuP9FzlH7QoO6JDckcY4hk xRTxMJsbWCDVxkIoULvtHivrOmo6YIn1HaVwWLZVYh3+kvsuyrqEcnmbPOYlW6kIqBAjKJLPS5su NA88h2lQ+qrzaKFfiShpgFo324VOKWxQR2d7qKZVIycT3nfP5aL1yzxQRTqqx6/lDuozH/nLirD5 NYkuLJg6x7W4+aKzgzsisMu1JzeIyuev31PDK0Lxwrvkw0Wpujqq9KhySBXidamv1TfQqCSuj6Rl mnMrMkRCjQNMuR8o/rY6eRYowczni8ahgAGnqMXEX01MeQBmO11KkPVV7otJ0ZWC9zRVr5J9Tw== --94eb2c068686c1a71e0564b77a74-- From nobody Thu Feb 8 10:56:15 2018 Return-Path: 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 7EF8F1270AC for ; Thu, 8 Feb 2018 10:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OQaLscJbT-Ku for ; Thu, 8 Feb 2018 10:56:02 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AADC12D969 for ; Thu, 8 Feb 2018 10:56:02 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id u12so489100ite.0 for ; Thu, 08 Feb 2018 10:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nR5iRBnrSfseY1bCtlr6VlB4jaCcGxwzDOg5EHSf0VI=; b=mg9toSX69h5nPt5oHlj7fUQ+/0pnblPDtKCAjxyDIouPeffqYN+fWSrS5CCcu/AQB9 GpeVUGfA7pkc6a+0Y01YiXLjsMcXegyOreNpcnOFEdIywwzfeEc2sYFzG/W0WvbaXWw7 WMoBQUlnBK4j3GRZI4kuJERTWLndmet+dI1nhncTJpWxQAZ+VhedrCYXa+6fWlM6uXs/ 0+ODDp5oASd8YipbRO3SAeCwqTnGp0YkdNQIuq9ATcQWMCJY/IgQqrJzECAjq5NOAkYL MNtKROO4CXSy57lBvTavCulV8NYS613e/+M8jf3mRGqX/xrKdQGAYsGo4mIKK3PELyTr TkIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nR5iRBnrSfseY1bCtlr6VlB4jaCcGxwzDOg5EHSf0VI=; b=MEZx7bq+3LVjCXhAy88ClDawFk32FnaNnXB0FhLhIV7y5iAR6v6vIYAbVhNkScxKiQ /IQioyWiW3rogEdQaLjO5gmord99G/C0XOQwSJpOeDgZxvD/jSfyl/D79DOk+J54/XSF UXmQlfQUopxLVErPvhzJow19SaZwY/BuNAjOLRPl29xNNpjLOUjyqvC51USC8tpkVgtB rmIUzBTplwHi2aI9lLZFtpj9umggdByzhQhIwuJ+/A+9SAGYuRIm6azWjR7qr6FQLuBn Mac7r+VF84lyplDwTOJS+fvTyRIY5XecyP+bOX/GEKgcKmGMPmFDr7Y/ySCiMBBymi58 t9Tw== X-Gm-Message-State: APf1xPA7EqnRx/Pxbu+t4j3eXMsu9I4fMdEljHefA6aFGjJzVgSZSeUY Z2JS9COWOAqSEoHWCI9GGsqv+iw6ONDNylg4JNKLK/9J X-Google-Smtp-Source: AH8x227DKTdBHi/eiyDJ1qx8NN5H1N6EaMpJPo/U3brUCooA5Aunf84nM50dPDYu/7wprRt0AtLvsiesZuVUluL4DDA= X-Received: by 10.36.221.18 with SMTP id t18mr192808itf.106.1518116161257; Thu, 08 Feb 2018 10:56:01 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Henck Date: Thu, 08 Feb 2018 18:55:50 +0000 Message-ID: To: Ben Schwartz Cc: mbishop@evequefou.be, doh@ietf.org Content-Type: multipart/alternative; boundary="001a1144e30a85b0410564b7f614" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:56:13 -0000 --001a1144e30a85b0410564b7f614 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like to see a way for clients to discover a DNS server hosted on a certain domain. Perhaps a .well-known/dns path that contains a relative pointer and other metadata. I'm imagining a use case whereby the user could choose to rely upon an organization that they find trustworthy which is offering DNS, without needing to do a significant amount of discovery (e.g. "maybe known.tld has a DNS server?"). You could of course also have an absolute pointer, but then you have to account for the situation whereby known.tld might delegate to unknown.tld. Justin Henck Google On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote: > On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop wrote: > >> I=E2=80=99m inclined to think this is a positive change. We=E2=80=99re = trying to do >> something better than the current world of =E2=80=9Ctrust the local DNS = server >> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust jus= t because a >> server claims it support DOH via a .well-known endpoint isn=E2=80=99t re= ally any >> better. >> > > To be clear, the draft never proposed promiscuous trust, which would > indeed be highly problematic. However, draft-03 does include additional > language clarifying this point. > > >> The client should know the hostname(s) of the DOH server(s) it wants to >> use >> > > In draft-03, "knowing the hostname" is not sufficient, because there is n= o > default path for DOH. This is the change on which I am seeking input. > > >> , and it should authenticate the DOH server against that hostname. >> > > Yes, definitely. (I believe the draft is clear on this point, but feel > free to suggest improvements.) > > >> If a server hosts content and also wants to also serve DOH, there are >> ways to present a hostname that covers both names (or present two >> certificates) on an HTTP connection. >> >> >> >> *From:* Doh [mailto:doh-bounces@ietf.org] *On Behalf Of *Ben Schwartz >> *Sent:* Thursday, February 8, 2018 10:05 AM >> *To:* doh@ietf.org >> *Subject:* [Doh] Seeking input on draft-03 >> >> >> >> Hi all, >> >> >> >> The authors of draft-ietf-doh-dns-over-https have been making good >> progress, and a draft-03 is now ready with several changes and >> clarifications. >> >> >> >> One important difference is that draft-03 no longer proposes a >> ".well-known" entry. In draft-02 and prior, clients could check for the >> presence of a DOH service at the default path, given only the domain nam= e >> of a server. In draft-03, there is no default path, so clients must be >> configured with the full URL of the DOH endpoint. >> >> >> >> Is this change compatible with your use cases? Would this alter the way >> users interact with your systems? How do you think DOH client >> configuration should work? >> >> >> >> Please respond with your thoughts, >> >> Ben Schwartz >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a1144e30a85b0410564b7f614 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to see a way for clients to discover a DNS se= rver hosted on a certain domain.=C2=A0 Perhaps a .well-known/dns path that = contains a relative pointer and other metadata.=C2=A0 I'm imagining a u= se case whereby the user could choose to rely upon an organization that the= y find trustworthy which is offering DNS, without needing to do a significa= nt amount of discovery (e.g. "maybe known.tld has a DNS server?")= .=C2=A0 You could of course also have an absolute pointer, but then you hav= e to account for the situation whereby known.tld might delegate to unknown.= tld.
<= div dir=3D"ltr">

Justin Henck
Google=C2=A0


On Thu, F= eb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be>= wrote:

I=E2=80=99m inclined to think this is a positive cha= nge.=C2=A0 We=E2=80=99re trying to do something better than the current wor= ld of =E2=80=9Ctrust the local DNS server because unauthenticated DHCP says= so=E2=80=9D, and promiscuous trust just because a server claims it support DOH via a .well-known endpoint isn=E2=80=99t really any better.

<= /div>

To be clear= , the draft never proposed promiscuous trust, which would indeed be highly = problematic.=C2=A0 However, draft-03 does include additional language clari= fying this point.
=C2=A0

The client should know the hostname(s) of the DOH server(s) it wants = to use


In draft-03, "kn= owing the hostname" is not sufficient, because there is no default pat= h for DOH.=C2=A0 This is the change on which I am seeking input.
=C2= =A0

, and it should authenticate the DOH= server against that hostname.


<= div>Yes, definitely.=C2=A0 (I believe the draft is clear on this point, but= feel free to suggest improvements.)
=C2=A0
<= div class=3D"m_7915354360324585554m_-3066104557813391296WordSection1">

=C2=A0 If a server hosts content and also wants to also s= erve DOH, there are ways to present a hostname that covers both names (or present tw= o certificates) on an HTTP connection.

=C2=A0

From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz
Sent: Thursday, February 8, 2018 10:05 AM
To: doh@ietf.org
Subject: [Doh] Seeking input on draft-03


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--001a1144e30a85b0410564b7f614-- From nobody Thu Feb 8 10:59:26 2018 Return-Path: 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 2539B126E3A for ; Thu, 8 Feb 2018 10:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 8feHwH_Rm-5Z for ; Thu, 8 Feb 2018 10:59:21 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64222126DFF for ; Thu, 8 Feb 2018 10:59:21 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id x62so3366430ywg.11 for ; Thu, 08 Feb 2018 10:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aGUA+DPNFq5VvazO1vwL14GJax3EjRrTyigkhzg1/HY=; b=EnFU4N7I7P2xScbPQSeKkVAdodTloYol1QYyh3hdOUD5dDEUuhzfmwFNwJxHMjE0RQ mlr3TvBB04xIIpepnl4B7ucC8oepy8yYAFNMMSwP4yD5S7G5ceANds9/c/hgYoOEDdhk AQmWPzzLz/jdv4lcGB1j1IgxRde+QvQXtDG1j+xKhU17/mBMqymwXxef/VHGhC5jzYHo d7hUojOxWAhLbR7aMj8hQV/AIgnDmrxITnERbvnjp9RZTOXdn4WOHKXwWqcdgJterVK5 rSRYzEWExL0yN3TBsGTj98YQ70u2eGNyqD3BNv+WazpvUumHg79pgNEDNXjjxQRms3TP 0UMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aGUA+DPNFq5VvazO1vwL14GJax3EjRrTyigkhzg1/HY=; b=d2rN5mvan1XLzE+JC+9U59b/U4V9Mzp0uZ8gjtaBp+gQBLuL7AVf9OMTTq6FLzQV9d 6f2OPLS3BafXsc8iCdWWeDcCSMVMh7gQpjmse00EEksAwQl2sZwcT2oqJ5VM8Bka3Azi ynEsNZlkgeW5AxHU+2+YvnN+oiZ4xB62/Ovc7YAbuEY6b44Fhgp7+ALGbhtPUEnAY6GY cp2ZfGGUPh/mHVX0uAh8emfC4N+0OlNtjfADXDq/IlfHloJZQiS8Fk+GPe99P8Tuyafd L21aauAu1VDWdAlDow+82EHMUu3CZys2AyiJQG6Vrl6qWi0phAC5TpI6RCQesCaCT6tV sDVg== X-Gm-Message-State: APf1xPC46oYfT8JtTySsxE9UuSmgVwl4wjOEzrUVmJvRucCW6zh6h3st vNm0KOs9GImTiV3IyGrsFJWZmhrBSm8j0/oUYGol0w== X-Google-Smtp-Source: AH8x226QqrPV92Pcr0XaoKQJ8hH6uIxWML8cQ3FTUD03l5E5xl6CX2a2HNai76RhHbyrySbaDjnnawOG4gPXDdod98o= X-Received: by 10.37.216.17 with SMTP id p17mr43167ybg.198.1518116360144; Thu, 08 Feb 2018 10:59:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.239.9 with HTTP; Thu, 8 Feb 2018 10:58:59 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Thu, 8 Feb 2018 10:58:59 -0800 Message-ID: To: Justin Henck Cc: Ben Schwartz , doh@ietf.org, mbishop@evequefou.be Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c068a146a18cc0564b80291" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:59:24 -0000 --94eb2c068a146a18cc0564b80291 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sounds like you might want a (TXT) record at the zone cut level? On 8 February 2018 at 10:55, Justin Henck wrote: > I would like to see a way for clients to discover a DNS server hosted on = a > certain domain. Perhaps a .well-known/dns path that contains a relative > pointer and other metadata. I'm imagining a use case whereby the user co= uld > choose to rely upon an organization that they find trustworthy which is > offering DNS, without needing to do a significant amount of discovery (e.= g. > "maybe known.tld has a DNS server?"). You could of course also have an > absolute pointer, but then you have to account for the situation whereby > known.tld might delegate to unknown.tld. > > Justin Henck > Google > > > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote: >> >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop wrote= : >>> >>> I=E2=80=99m inclined to think this is a positive change. We=E2=80=99re= trying to do >>> something better than the current world of =E2=80=9Ctrust the local DNS= server >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust ju= st because a >>> server claims it support DOH via a .well-known endpoint isn=E2=80=99t r= eally any >>> better. >> >> >> To be clear, the draft never proposed promiscuous trust, which would >> indeed be highly problematic. However, draft-03 does include additional >> language clarifying this point. >> >>> >>> The client should know the hostname(s) of the DOH server(s) it wants to >>> use >> >> >> In draft-03, "knowing the hostname" is not sufficient, because there is = no >> default path for DOH. This is the change on which I am seeking input. >> >>> >>> , and it should authenticate the DOH server against that hostname. >> >> >> Yes, definitely. (I believe the draft is clear on this point, but feel >> free to suggest improvements.) >> >>> >>> If a server hosts content and also wants to also serve DOH, there are >>> ways to present a hostname that covers both names (or present two >>> certificates) on an HTTP connection. >>> >>> >>> >>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz >>> Sent: Thursday, February 8, 2018 10:05 AM >>> To: doh@ietf.org >>> Subject: [Doh] Seeking input on draft-03 >>> >>> >>> >>> Hi all, >>> >>> >>> >>> The authors of draft-ietf-doh-dns-over-https have been making good >>> progress, and a draft-03 is now ready with several changes and >>> clarifications. >>> >>> >>> >>> One important difference is that draft-03 no longer proposes a >>> ".well-known" entry. In draft-02 and prior, clients could check for th= e >>> presence of a DOH service at the default path, given only the domain na= me of >>> a server. In draft-03, there is no default path, so clients must be >>> configured with the full URL of the DOH endpoint. >>> >>> >>> >>> Is this change compatible with your use cases? Would this alter the wa= y >>> users interact with your systems? How do you think DOH client configur= ation >>> should work? >>> >>> >>> >>> Please respond with your thoughts, >>> >>> Ben Schwartz >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --94eb2c068a146a18cc0564b80291 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg9ORMwwRDc97/r5ZXC6UfRXnSuDyiONox 7p3mqqpZWhowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMjA4 MTg1OTIwWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAFcj2owffln0wHqcshrOLavuOJvz4RoLeGGcIyVaxtTMhD0fP/ao 3FDkkfheSRCwnsd2EjPnCAW1pf3xd9Al5qWFbwZIEGmsXT/JmAv3lL5z/szdiZLWttXyDmKwup7j 0Gc0Id4U2O/TjXF18z+kzVL7NG7w57NlhiZroGk/aRID/PS2mO+wMrNkMW+vTBpTeD9p68RiggDp 73xZxYZJBJVf6wQHKG1R8/nA7oLeYYOrFs/gsrU6qftvhtKf9vQQf/ueVK4N4DTTcvdktHInhUxQ ObgSmhk+iS2qYUcH8YbRYR2YzUGKSHi7cPs0DqoXHJfn1m65GDo+6xrNRhY2kLs= --94eb2c068a146a18cc0564b80291-- From nobody Thu Feb 8 11:17:13 2018 Return-Path: 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 82C2C127337 for ; Thu, 8 Feb 2018 11:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 oO72MKuITmwC for ; Thu, 8 Feb 2018 11:17:09 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1FE1273B1 for ; Thu, 8 Feb 2018 11:17:08 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id t22so6952661ioa.7 for ; Thu, 08 Feb 2018 11:17:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bisI+qHi5WqbKtzAiU2M+Lae02NZmwhP25hTNCbhDA8=; b=BIkhlMK5R7Rg+KMO0AgQRMrfxh+ymeYhXu5Rhn7Ky0mAxe9xidy4US/+5eDithxsiZ 7S4R1aBqCDcj1wF6WphaaV3T2c6ZNX5pkkEEC5qvpfKeQ31fZODctP7UFJjJIFvwwFGC eZ3emchaMM1mwOnDKChIHHTW2Kv57cSO88tvwQwCoB1DBE+7O/VWPFWV63hMmb+R2P6n j3HXfN3qgFB2qLEzZBWbbhVxIxsNCrf7hizGLvkt8LcOxrKMGLbKCQgiudw8L3MmSp5S TLlvQqUhB1Ngkl0Z6JgsHN8KeuTUcRdnToxMnPeUKtlUERO1Okx2qvqj3S3Bujsetn/P srPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bisI+qHi5WqbKtzAiU2M+Lae02NZmwhP25hTNCbhDA8=; b=uENuIhS48ub6oIWGcZf6SM0HC+ZewvSAktltegg0hy/IRsvxIM4lqLpdu/cZ0iwkns 8bkBUjDoT7pt4WohWCQijbMOj40yLyDoSzgSQYyocvIoPAnK9L5DjVm4w8LL+FF36msV OFFET5NHUVOt7qfs8CT3zL0YrK2Svzw6QAplc7FV88JOcnxQXX5J7lPWS/x1/6HmWPAS Ygk23bm53eXXp7r5Sd4Iz84jO3t63dKcvYfCfvI4cH8ryWZsP9ohpcb6yigfsQjL0QFO lyI5uE99PiIUGoXF9xO8w++mSB2x3/QDvCNGDIIzYe4Qy1wwT6TW8OMedmVdNWbzUv38 9n1A== X-Gm-Message-State: APf1xPCoWS+7/AKpRDuxnT6tLXxk/C8ceB8yi4WARS0+fkdSA/6nzdWR QQ9TCcHEqSZs7EaizYGhZAdr5zb+rPaFaoy8AF3KK36G X-Google-Smtp-Source: AH8x224p7xYuvIVgrzst5FBY5v3ZjhLWSCWl9ukJOVn/L0oBbR0KKTMLGRaPDJAKPuFt6G7CPs3a803tVH2i9k8LqEg= X-Received: by 10.107.201.136 with SMTP id z130mr304912iof.257.1518117427523; Thu, 08 Feb 2018 11:17:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Henck Date: Thu, 08 Feb 2018 19:16:56 +0000 Message-ID: To: ek@google.com Cc: Ben Schwartz , doh@ietf.org, mbishop@evequefou.be Content-Type: multipart/alternative; boundary="94eb2c0b8cd8ff64fa0564b8410a" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:17:11 -0000 --94eb2c0b8cd8ff64fa0564b8410a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That would work for the situation I specified, but I think that a .well-known pointer provides the additional benefit of serving more technical users with an advanced configuration. (It is also in-line with the intended use of .well-known as I understand RFC 5785.) Specifically, if an implementer creates an advanced setting whereby you can configure a DOH server with both a domain and an IP (to eliminate the need for bootstrapping) then you have made the user's life easier. And, although a URI is not supposed to change, a .well-known/dns pointer requirement would ensure that capricious servers don't break manually-configured clients. Justin Henck Product Manager 212-565-9811 google.com/jigsaw PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B On Thu, Feb 8, 2018 at 1:59 PM Erik Kline wrote: > Sounds like you might want a (TXT) record at the zone cut level? > > On 8 February 2018 at 10:55, Justin Henck wrote: > > I would like to see a way for clients to discover a DNS server hosted o= n > a > > certain domain. Perhaps a .well-known/dns path that contains a relativ= e > > pointer and other metadata. I'm imagining a use case whereby the user > could > > choose to rely upon an organization that they find trustworthy which is > > offering DNS, without needing to do a significant amount of discovery > (e.g. > > "maybe known.tld has a DNS server?"). You could of course also have an > > absolute pointer, but then you have to account for the situation whereb= y > > known.tld might delegate to unknown.tld. > > > > Justin Henck > > Google > > > > > > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote: > >> > >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop > wrote: > >>> > >>> I=E2=80=99m inclined to think this is a positive change. We=E2=80=99= re trying to do > >>> something better than the current world of =E2=80=9Ctrust the local D= NS server > >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust = just > because a > >>> server claims it support DOH via a .well-known endpoint isn=E2=80=99t= really > any > >>> better. > >> > >> > >> To be clear, the draft never proposed promiscuous trust, which would > >> indeed be highly problematic. However, draft-03 does include addition= al > >> language clarifying this point. > >> > >>> > >>> The client should know the hostname(s) of the DOH server(s) it wants = to > >>> use > >> > >> > >> In draft-03, "knowing the hostname" is not sufficient, because there i= s > no > >> default path for DOH. This is the change on which I am seeking input. > >> > >>> > >>> , and it should authenticate the DOH server against that hostname. > >> > >> > >> Yes, definitely. (I believe the draft is clear on this point, but fee= l > >> free to suggest improvements.) > >> > >>> > >>> If a server hosts content and also wants to also serve DOH, there a= re > >>> ways to present a hostname that covers both names (or present two > >>> certificates) on an HTTP connection. > >>> > >>> > >>> > >>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz > >>> Sent: Thursday, February 8, 2018 10:05 AM > >>> To: doh@ietf.org > >>> Subject: [Doh] Seeking input on draft-03 > >>> > >>> > >>> > >>> Hi all, > >>> > >>> > >>> > >>> The authors of draft-ietf-doh-dns-over-https have been making good > >>> progress, and a draft-03 is now ready with several changes and > >>> clarifications. > >>> > >>> > >>> > >>> One important difference is that draft-03 no longer proposes a > >>> ".well-known" entry. In draft-02 and prior, clients could check for > the > >>> presence of a DOH service at the default path, given only the domain > name of > >>> a server. In draft-03, there is no default path, so clients must be > >>> configured with the full URL of the DOH endpoint. > >>> > >>> > >>> > >>> Is this change compatible with your use cases? Would this alter the > way > >>> users interact with your systems? How do you think DOH client > configuration > >>> should work? > >>> > >>> > >>> > >>> Please respond with your thoughts, > >>> > >>> Ben Schwartz > >> > >> > >> _______________________________________________ > >> Doh mailing list > >> Doh@ietf.org > >> https://www.ietf.org/mailman/listinfo/doh > > > > > > _______________________________________________ > > Doh mailing list > > Doh@ietf.org > > https://www.ietf.org/mailman/listinfo/doh > > > --94eb2c0b8cd8ff64fa0564b8410a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That would work for the situation I specified, but I think= that a .well-known pointer provides the additional benefit of serving more= technical users with an advanced configuration. (It is also in-line with t= he intended use of .well-known as I understand RFC 5785.)

Specifically, if an implementer creates an advanced setting whereby you c= an configure a DOH server with both a domain and an IP (to eliminate the ne= ed for bootstrapping) then you have made the user's life easier. And, a= lthough a URI is not supposed to change, a .well-known/dns pointer requirem= ent would ensure that capricious servers don't break manually-configure= d clients.


Justin Henck=C2=A0
Product Manage= r=C2=A0
212-565-= 9811=C2=A0
google.com/jigsaw

PGP: EA8E 8C27 = 2D75 974D B357 482B 1039 9F2D 869A 117B
<= /div>


On Thu, Feb 8, 2018 at 1:59 PM Erik Kline <= ;ek@google.com> wrote:
Sounds like you might want a (TXT) record at th= e zone cut level?

On 8 February 2018 at 10:55, Justin Henck <henck@google.com> wrote:
> I would like to see a way for clients to discover a DNS server hosted = on a
> certain domain.=C2=A0 Perhaps a .well-known/dns path that contains a r= elative
> pointer and other metadata.=C2=A0 I'm imagining a use case whereby= the user could
> choose to rely upon an organization that they find trustworthy which i= s
> offering DNS, without needing to do a significant amount of discovery = (e.g.
> "maybe known.tld has a DNS server?").=C2=A0 You could of cou= rse also have an
> absolute pointer, but then you have to account for the situation where= by
> known.tld might delegate to unknown.tld.
>
> Justin Henck
> Google
>
>
> On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <bemasc@google.com> wrote:
>>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be> wrote:=
>>>
>>> I=E2=80=99m inclined to think this is a positive change.=C2=A0= We=E2=80=99re trying to do
>>> something better than the current world of =E2=80=9Ctrust the = local DNS server
>>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous= trust just because a
>>> server claims it support DOH via a .well-known endpoint isn=E2= =80=99t really any
>>> better.
>>
>>
>> To be clear, the draft never proposed promiscuous trust, which wou= ld
>> indeed be highly problematic.=C2=A0 However, draft-03 does include= additional
>> language clarifying this point.
>>
>>>
>>> The client should know the hostname(s) of the DOH server(s) it= wants to
>>> use
>>
>>
>> In draft-03, "knowing the hostname" is not sufficient, b= ecause there is no
>> default path for DOH.=C2=A0 This is the change on which I am seeki= ng input.
>>
>>>
>>> , and it should authenticate the DOH server against that hostn= ame.
>>
>>
>> Yes, definitely.=C2=A0 (I believe the draft is clear on this point= , but feel
>> free to suggest improvements.)
>>
>>>
>>>=C2=A0 =C2=A0If a server hosts content and also wants to also s= erve DOH, there are
>>> ways to present a hostname that covers both names (or present = two
>>> certificates) on an HTTP connection.
>>>
>>>
>>>
>>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz
>>> Sent: Thursday, February 8, 2018 10:05 AM
>>> To: doh@ietf= .org
>>> Subject: [Doh] Seeking input on draft-03
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> The authors of draft-ietf-doh-dns-over-https have been making = good
>>> progress, and a draft-03 is now ready with several changes and=
>>> clarifications.
>>>
>>>
>>>
>>> One important difference is that draft-03 no longer proposes a=
>>> ".well-known" entry.=C2=A0 In draft-02 and prior, cl= ients could check for the
>>> presence of a DOH service at the default path, given only the = domain name of
>>> a server.=C2=A0 In draft-03, there is no default path, so clie= nts must be
>>> configured with the full URL of the DOH endpoint.
>>>
>>>
>>>
>>> Is this change compatible with your use cases?=C2=A0 Would thi= s alter the way
>>> users interact with your systems?=C2=A0 How do you think DOH c= lient configuration
>>> should work?
>>>
>>>
>>>
>>> Please respond with your thoughts,
>>>
>>> Ben Schwartz
>>
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org=
>> https://www.ietf.org/mailman/listinfo/doh
>
>
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>
--94eb2c0b8cd8ff64fa0564b8410a-- From nobody Thu Feb 8 11:19:20 2018 Return-Path: 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 8A5F01273B1 for ; Thu, 8 Feb 2018 11:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0Z8ypqlGKc9B for ; Thu, 8 Feb 2018 11:19:16 -0800 (PST) Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325C7127337 for ; Thu, 8 Feb 2018 11:19:16 -0800 (PST) Received: by mail-lf0-x241.google.com with SMTP id h78so779975lfg.6 for ; Thu, 08 Feb 2018 11:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=01a6SDvn8OHZVDHOwwNuIVVHfYRfCgKxqa0Yaff86wg=; b=tBZnyLBcNYtm2whw/eFOzv6BeaRE4ChdtRLayJRH3u9LNJP2pg10/mItF/nLO0u0Jp 0pAf3dpW6aMyqaDhZk4Gkz+dZprRgRi83UYAiuTurr83m7KZ9aM5LYuch61jOv/Iu/q0 ojeMek1ieV1cSlod1me4WTI0DwrrSs46WRl8H4npgmhCBCsZcb/5K5HIT0FyaPrg23XM TFwtPRPu8D8+Muv9hPX8Ax2SbjdJi1rvnLl31j7k0n/BQJdUAh2BG+qbKBoqUZ1KG9gb /s/G+1LTSlYh6mkPPLrYLtUaM0krjF1hVKvadeUFRo7SVWPi0AP3EzH0DD+CqYZc/6Vs Cosw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=01a6SDvn8OHZVDHOwwNuIVVHfYRfCgKxqa0Yaff86wg=; b=OycoP25B3bgblI3NRT8oRt7wWpojpuZdbPC4nGeTljr6MyBhYObmRguLYXzm71BSxR 7IgAAPUJYXXKbdNMH1/sAASS/mW3c1FjpsNoHnigAJUnxZuQYQYeqd4dAzmNBisldXpe bOyNWY1L43dB2rY7NIlCO4V+Oul/uQtFlpISOLGvTkpGyeSirIjErsBBOu2iBBQwO3fz /9uK7Twkk1MhhlWW5ig3I4ZU+Kdv/KDeUX6MXkJDRmnVV7MBL6ECQ2WV9hndgfOFMi2g 5CkcGIiBB7EKllR9MX3X0mTE2IGuvR10RnIn1yerRV41ZM8bQ3/d1OeAFqgzVdR1NvDb UNtA== X-Gm-Message-State: APf1xPCgH3hYJ39jHPqC7Wt50j83SsOvhoZrBcUb3rO7ZcSCT4/99bI2 lAvg3PsjeJEHOWxlPDFcuruH3yX4zegyXK+K03M= X-Google-Smtp-Source: AH8x224k6ANkhU3EKlduPCP6I/XVRCmX2LzDWe4lWLJNKO+UFGnpeL7ikBF9mhFRBk139rMxg5NhtqmRci9UD8YdKbE= X-Received: by 10.46.108.9 with SMTP id h9mr139934ljc.125.1518117554187; Thu, 08 Feb 2018 11:19:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.227.5 with HTTP; Thu, 8 Feb 2018 11:19:13 -0800 (PST) In-Reply-To: References: From: manu tman Date: Thu, 8 Feb 2018 11:19:13 -0800 Message-ID: To: Justin Henck Cc: Ben Schwartz , doh@ietf.org, mbishop@evequefou.be Content-Type: multipart/alternative; boundary="f4f5e80791188b730c0564b84938" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:19:18 -0000 --f4f5e80791188b730c0564b84938 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2018 at 10:55 AM, Justin Henck wrote: > I would like to see a way for clients to discover a DNS server hosted on = a > certain domain. Perhaps a .well-known/dns path that contains a relative > pointer and other metadata. > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/75 touches on discoverability. I am more in favor of a set of simple requirements, so simple client and server implementation can exist and provide the basics of DOH functionality. Optionally, discovery can be used to be more fancy and provide extensibility, but at the core of it, I would expect that knowing a domain and optionally an IP (to avoid the chicken and egg issue of being able to resolve the DOH server IP ) should be enough to be able to access DNS over HTTPS using GET at a well known endpoint. Enforcing discovery will most likely slow and prevent new implementations. Manu > I'm imagining a use case whereby the user could choose to rely upon an > organization that they find trustworthy which is offering DNS, without > needing to do a significant amount of discovery (e.g. "maybe known.tld ha= s > a DNS server?"). You could of course also have an absolute pointer, but > then you have to account for the situation whereby known.tld might delega= te > to unknown.tld. > > Justin Henck > Google > > > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote: > >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop wrote= : >> >>> I=E2=80=99m inclined to think this is a positive change. We=E2=80=99re= trying to do >>> something better than the current world of =E2=80=9Ctrust the local DNS= server >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust ju= st because a >>> server claims it support DOH via a .well-known endpoint isn=E2=80=99t r= eally any >>> better. >>> >> >> To be clear, the draft never proposed promiscuous trust, which would >> indeed be highly problematic. However, draft-03 does include additional >> language clarifying this point. >> >> >>> The client should know the hostname(s) of the DOH server(s) it wants to >>> use >>> >> >> In draft-03, "knowing the hostname" is not sufficient, because there is >> no default path for DOH. This is the change on which I am seeking input= . >> >> >>> , and it should authenticate the DOH server against that hostname. >>> >> >> Yes, definitely. (I believe the draft is clear on this point, but feel >> free to suggest improvements.) >> >> >>> If a server hosts content and also wants to also serve DOH, there are >>> ways to present a hostname that covers both names (or present two >>> certificates) on an HTTP connection. >>> >>> >>> >>> *From:* Doh [mailto:doh-bounces@ietf.org] *On Behalf Of *Ben Schwartz >>> *Sent:* Thursday, February 8, 2018 10:05 AM >>> *To:* doh@ietf.org >>> *Subject:* [Doh] Seeking input on draft-03 >>> >>> >>> >>> Hi all, >>> >>> >>> >>> The authors of draft-ietf-doh-dns-over-https have been making good >>> progress, and a draft-03 is now ready with several changes and >>> clarifications. >>> >>> >>> >>> One important difference is that draft-03 no longer proposes a >>> ".well-known" entry. In draft-02 and prior, clients could check for th= e >>> presence of a DOH service at the default path, given only the domain na= me >>> of a server. In draft-03, there is no default path, so clients must be >>> configured with the full URL of the DOH endpoint. >>> >>> >>> >>> Is this change compatible with your use cases? Would this alter the wa= y >>> users interact with your systems? How do you think DOH client >>> configuration should work? >>> >>> >>> >>> Please respond with your thoughts, >>> >>> Ben Schwartz >>> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --f4f5e80791188b730c0564b84938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 8, 2018 at 10:55 AM, Justin Henck <henck@google.com> wrote:
I would like to see a way for clients to discover a DNS server hosted= on a certain domain.=C2=A0 Perhaps a .well-known/dns path that contains a = relative pointer and other metadata.=C2=A0

I am more in favor of a set of simple requirements, so simple = client and server implementation can exist and provide the basics of DOH fu= nctionality.=C2=A0
Optionally, discovery can be used to be more fancy an= d provide extensibility, but at the core of it, I would expect that knowing= a domain and optionally an IP (to avoid the chicken and egg issue of being= able to resolve the DOH server IP ) should be enough to be able to access = DNS over HTTPS using GET at a well known endpoint.
Enforcing disc= overy will most likely slow and prevent new implementations.

=
Manu

=C2=A0
I'm imagining a use case whereby the user= could choose to rely upon an organization that they find trustworthy which= is offering DNS, without needing to do a significant amount of discovery (= e.g. "maybe known.tld has a DNS server?").=C2=A0 You could of cou= rse also have an absolute pointer, but then you have to account for the sit= uation whereby known.tld might delegate to unknown.tld.

Justin Henck
Google=C2= =A0
=


On Thu, Feb 8, 2018= at 1:21 PM Ben Schwartz <bemasc@google.com> wrote:
On Thu, Feb = 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be> wr= ote:

I=E2=80=99m inclined to think this is a positive cha= nge.=C2=A0 We=E2=80=99re trying to do something better than the current wor= ld of =E2=80=9Ctrust the local DNS server because unauthenticated DHCP says= so=E2=80=9D, and promiscuous trust just because a server claims it support DOH via a .well-known endpoint isn=E2=80=99t really any better.

<= /div>

To be clear= , the draft never proposed promiscuous trust, which would indeed be highly = problematic.=C2=A0 However, draft-03 does include additional language clari= fying this point.
=C2=A0

The client should know the hostname(s) of the DOH server(= s) it wants to use


In draft-= 03, "knowing the hostname" is not sufficient, because there is no= default path for DOH.=C2=A0 This is the change on which I am seeking input= .
=C2=A0

, and it shoul= d authenticate the DOH server against that hostname.


Yes, definitely.=C2=A0 (I believe the draft is cl= ear on this point, but feel free to suggest improvements.)
=C2=A0=

=C2=A0 If a server host= s content and also wants to also serve DOH, there are ways to present a hostname that covers both names (or present tw= o certificates) on an HTTP connection.

=C2=A0

From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz
Sent: Thursday, February 8, 2018 10:05 AM
To: doh@ietf.org
Subject: [Doh] Seeking input on draft-03


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--f4f5e80791188b730c0564b84938-- From nobody Thu Feb 8 11:22:38 2018 Return-Path: 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 A002B1270AC for ; Thu, 8 Feb 2018 11:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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=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 2Nioq1STfMJE for ; Thu, 8 Feb 2018 11:22:34 -0800 (PST) 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 D66EB126CF6 for ; Thu, 8 Feb 2018 11:22:33 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w18JH9A0012143; Thu, 8 Feb 2018 19:22:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=9nNQ9w3GJU95pmKlQzlYU4bL82hD/aVzEqn6gJN1fk4=; b=laHBoR/59Lfb3kiVo5yi0nyZoxDuuggdQii25eL8meydyEt6eG1y5AO8iGA/tF1yMqoC cFeJbRFZETEv6kd3F1l9QM6T2kRO3Yrot/wkYp8vep5vy6gkK0fkP/XAwQYa2U+Oc6pQ vUro/i3bX/fsju6FdziLfaJePLmJOgvl/K0xLL/Hi8iIOV5gppYyEWeZlY29XXFuAee7 12RZykLWiGQF0VoRaryD8KWE6uxiAGngv79i4hb2TM8V6OZmjy003g5fLwdz+8B7A2id Sxk1ZY4MfZPk5pmELB0e4/Czgdnz0JfLZ+8g/jMqbAe9vI2EBIQbuIdrPvY5xuQlX9mT rw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2g051xkr95-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 19:22:28 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w18JKpOZ011951; Thu, 8 Feb 2018 14:22:27 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fw9a0aq91-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 14:22:26 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Feb 2018 14:22:25 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1263.000; Thu, 8 Feb 2018 14:22:25 -0500 From: "Hewitt, Rory" To: Justin Henck , "ek@google.com" CC: Ben Schwartz , "doh@ietf.org" , "mbishop@evequefou.be" Thread-Topic: [Doh] Seeking input on draft-03 Thread-Index: AQHToQduweN2QsT0vEuAdp25IbWfnaObIiGAgAAC4YCAAAmgAIAAAOGAgAAFBAD//6ydYA== Date: Thu, 8 Feb 2018 19:22:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.242] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0371_01D3A0CF.1767F640" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_10:, , 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-1711220000 definitions=main-1802080224 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_10:, , 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-1711220000 definitions=main-1802080223 Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:22:37 -0000 ------=_NextPart_000_0371_01D3A0CF.1767F640 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0372_01D3A0CF.1767F640" ------=_NextPart_001_0372_01D3A0CF.1767F640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Additionally, using /.well-known/ would allow for URI Template = discovery, if required - client retrieves URI Template from e.g. = /.well-known/doh.template and then uses that to build DNS request URI. =20 See = https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 for = @mnot's suggestion. =20 Thanks, =20 Rory =20 Rory Hewitt Senior Solutions Architect Global Services & Support Akamai Technologies Tel: (408) 650-0035 =20 From: Justin Henck [mailto:henck@google.com]=20 Sent: Thursday, February 8, 2018 11:17 AM To: ek@google.com Cc: Ben Schwartz ; doh@ietf.org; mbishop@evequefou.be Subject: Re: [Doh] Seeking input on draft-03 =20 That would work for the situation I specified, but I think that a = .well-known pointer provides the additional benefit of serving more = technical users with an advanced configuration. (It is also in-line with = the intended use of .well-known as I understand RFC 5785.) =20 Specifically, if an implementer creates an advanced setting whereby you = can configure a DOH server with both a domain and an IP (to eliminate = the need for bootstrapping) then you have made the user's life easier. = And, although a URI is not supposed to change, a .well-known/dns pointer = requirement would ensure that capricious servers don't break = manually-configured clients. =20 =20 Justin Henck=20 Product Manager=20 212-565-9811=20 = google.com/jigsaw =20 PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B =20 On Thu, Feb 8, 2018 at 1:59 PM Erik Kline > wrote: Sounds like you might want a (TXT) record at the zone cut level? On 8 February 2018 at 10:55, Justin Henck > wrote: > I would like to see a way for clients to discover a DNS server hosted = on a > certain domain. Perhaps a .well-known/dns path that contains a = relative > pointer and other metadata. I'm imagining a use case whereby the user = could > choose to rely upon an organization that they find trustworthy which = is > offering DNS, without needing to do a significant amount of discovery = (e.g. > "maybe known.tld has a DNS server?"). You could of course also have = an > absolute pointer, but then you have to account for the situation = whereby > known.tld might delegate to unknown.tld. > > Justin Henck > Google > > > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz > wrote: >> >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop > wrote: >>> >>> I=E2=80=99m inclined to think this is a positive change. = We=E2=80=99re trying to do >>> something better than the current world of =E2=80=9Ctrust the local = DNS server >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust = just because a >>> server claims it support DOH via a .well-known endpoint = isn=E2=80=99t really any >>> better. >> >> >> To be clear, the draft never proposed promiscuous trust, which would >> indeed be highly problematic. However, draft-03 does include = additional >> language clarifying this point. >> >>> >>> The client should know the hostname(s) of the DOH server(s) it wants = to >>> use >> >> >> In draft-03, "knowing the hostname" is not sufficient, because there = is no >> default path for DOH. This is the change on which I am seeking = input. >> >>> >>> , and it should authenticate the DOH server against that hostname. >> >> >> Yes, definitely. (I believe the draft is clear on this point, but = feel >> free to suggest improvements.) >> >>> >>> If a server hosts content and also wants to also serve DOH, there = are >>> ways to present a hostname that covers both names (or present two >>> certificates) on an HTTP connection. >>> >>> >>> >>> From: Doh [mailto:doh-bounces@ietf.org = ] On Behalf Of Ben Schwartz >>> Sent: Thursday, February 8, 2018 10:05 AM >>> To: doh@ietf.org =20 >>> Subject: [Doh] Seeking input on draft-03 >>> >>> >>> >>> Hi all, >>> >>> >>> >>> The authors of draft-ietf-doh-dns-over-https have been making good >>> progress, and a draft-03 is now ready with several changes and >>> clarifications. >>> >>> >>> >>> One important difference is that draft-03 no longer proposes a >>> ".well-known" entry. In draft-02 and prior, clients could check for = the >>> presence of a DOH service at the default path, given only the domain = name of >>> a server. In draft-03, there is no default path, so clients must be >>> configured with the full URL of the DOH endpoint. >>> >>> >>> >>> Is this change compatible with your use cases? Would this alter the = way >>> users interact with your systems? How do you think DOH client = configuration >>> should work? >>> >>> >>> >>> Please respond with your thoughts, >>> >>> Ben Schwartz >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org =20 >> https://www.ietf.org/mailman/listinfo/doh = =20 > > > _______________________________________________ > Doh mailing list > Doh@ietf.org =20 > https://www.ietf.org/mailman/listinfo/doh = =20 > ------=_NextPart_001_0372_01D3A0CF.1767F640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= Additionally, using /.well-known/ would allow for URI Template = discovery, if required - client retrieves URI Template from e.g. = /.well-known/doh.template and then uses that to build DNS request = URI.

=  

= See https://github= .com/dohwg/draft-ietf-doh-dns-over-https/issues/74= for @mnot's suggestion.

=  

= Thanks,

=  

= Rory

=  

= Rory Hewitt

= Senior Solutions Architect

= Global Services & Support=

= Akamai Technologies

= Tel: (408) 650-0035

=  

From: Justin Henck [mailto:henck@google.com] =
Sent: Thursday, February 8, 2018 11:17 AM
To: = ek@google.com
Cc: Ben Schwartz <bemasc@google.com>; = doh@ietf.org; mbishop@evequefou.be
Subject: Re: [Doh] Seeking = input on draft-03

 

That = would work for the situation I specified, but I think that a .well-known = pointer provides the additional benefit of serving more technical users = with an advanced configuration. (It is also in-line with the intended = use of .well-known as I understand RFC 5785.)

 

Specifically, if an implementer creates an advanced = setting whereby you can configure a DOH server with both a domain and an = IP (to eliminate the need for bootstrapping) then you have made the = user's life easier. And, although a URI is not supposed to change, a = .well-known/dns pointer requirement would ensure that capricious servers = don't break manually-configured clients.


<= div>

 

<= img border=3D0 width=3D45 height=3D45 = style=3D'width:.4666in;height:.4666in' id=3D"_x0000_i1025" = src=3D"https://www.gstatic.com/jigsaw/Jigsaw_logo.png">=

J= ustin Henck&= nbsp;
Product Manager 

2= 12-565-9811 

<= a = href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__google.com= _jigsaw&d=3DDwMFaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3Dh4goE6gK_Za= Rrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=3DKrH6cYm-gcGpqevreKzpdpsMm-hErKTC= NEthg2TBsTU&s=3DN-RLQbYhldj1naDovU3jQQtWdiNb5pbKuxXJJ3p663Y&e=3D"= target=3D"_blank">google.com/jigsaw

 

PGP: EA8E 8C27 2D75 974D = B357 482B 1039 9F2D 869A = 117B

=

 

On Thu, Feb 8, 2018 at 1:59 PM Erik Kline <ek@google.com> = wrote:

Sounds = like you might want a (TXT) record at the zone cut level?

On 8 = February 2018 at 10:55, Justin Henck <henck@google.com> wrote:
> I would like = to see a way for clients to discover a DNS server hosted on a
> = certain domain.  Perhaps a .well-known/dns path that contains a = relative
> pointer and other metadata.  I'm imagining a use = case whereby the user could
> choose to rely upon an organization = that they find trustworthy which is
> offering DNS, without = needing to do a significant amount of discovery (e.g.
> = "maybe known.tld has a DNS server?").  You could of = course also have an
> absolute pointer, but then you have to = account for the situation whereby
> known.tld might delegate to = unknown.tld.
>
> Justin Henck
> = Google
>
>
> On Thu, Feb 8, 2018 at 1:21 PM Ben = Schwartz <bemasc@google.com> = wrote:
>>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike = Bishop <mbishop@evequefou.be> = wrote:
>>>
>>> I=E2=80=99m inclined to think = this is a positive change.  We=E2=80=99re trying to = do
>>> something better than the current world of = =E2=80=9Ctrust the local DNS server
>>> because = unauthenticated DHCP says so=E2=80=9D, and promiscuous trust just = because a
>>> server claims it support DOH via a .well-known = endpoint isn=E2=80=99t really any
>>> = better.
>>
>>
>> To be clear, the draft never = proposed promiscuous trust, which would
>> indeed be highly = problematic.  However, draft-03 does include additional
>> = language clarifying this = point.
>>
>>>
>>> The client should = know the hostname(s) of the DOH server(s) it wants to
>>> = use
>>
>>
>> In draft-03, "knowing the = hostname" is not sufficient, because there is no
>> = default path for DOH.  This is the change on which I am seeking = input.
>>
>>>
>>> , and it should = authenticate the DOH server against that = hostname.
>>
>>
>> Yes, definitely.  (I = believe the draft is clear on this point, but feel
>> free to = suggest improvements.)
>>
>>>
>>>  =  If a server hosts content and also wants to also serve DOH, there = are
>>> ways to present a hostname that covers both names = (or present two
>>> certificates) on an HTTP = connection.
>>>
>>>
>>>
>>&g= t; From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben = Schwartz
>>> Sent: Thursday, February 8, 2018 10:05 = AM
>>> To: doh@ietf.org
>>> Subject: [Doh] = Seeking input on = draft-03
>>>
>>>
>>>
>>> = Hi all,
>>>
>>>
>>>
>>> = The authors of draft-ietf-doh-dns-over-https have been making = good
>>> progress, and a draft-03 is now ready with several = changes and
>>> = clarifications.
>>>
>>>
>>>
>&g= t;> One important difference is that draft-03 no longer proposes = a
>>> ".well-known" entry.  In draft-02 and = prior, clients could check for the
>>> presence of a DOH = service at the default path, given only the domain name = of
>>> a server.  In draft-03, there is no default = path, so clients must be
>>> configured with the full URL of = the DOH = endpoint.
>>>
>>>
>>>
>>>= Is this change compatible with your use cases?  Would this alter = the way
>>> users interact with your systems?  How do = you think DOH client configuration
>>> should = work?
>>>
>>>
>>>
>>> = Please respond with your thoughts,
>>>
>>> Ben = Schwartz
>>
>>
>> = _______________________________________________
>> Doh mailing = list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>>
> _______________________________________________
> = Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>

------=_NextPart_001_0372_01D3A0CF.1767F640-- ------=_NextPart_000_0371_01D3A0CF.1767F640 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDIwODE5MjIyM1owIwYJKoZIhvcNAQkEMRYEFGcQuYsVIRKwoOlGNp1ZvfSfJcdJMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBABTd4SiOFf/uZjCPDosVqfoErv9cQg/jemhE7wQJvBIITPWYs7URW8GJhj83 uTh4P3xnyPym0MoUA0eZdkKLnB+tRosKrXB3mu1Md4iYmzAy1X+fCA9McHn8i5jLhjo1eq/T/ft1 mwXdAtcZ7KIDJvNbk8wLqUgAakrXputes+RHMd0GvOz4jJKFhhxZ9bNbZFpR1WaJjC2QcJ8VX/w3 zhGqRYu6+KFoyPX8YS4PyL3ohy5BXFzGns2Aou7RMfVT0Q2ru7Sco1J8FDAUIyVFWdvl56VW0B47 zA8X4AER2yXdFtVGmNVid8GDIegCvIXAkTcTQMWjw8aYKo4+elPPjuIAAAAAAAA= ------=_NextPart_000_0371_01D3A0CF.1767F640-- From nobody Thu Feb 8 11:24:13 2018 Return-Path: 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 3370A12706D for ; Thu, 8 Feb 2018 11:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Tuqp-5zi5w0t for ; Thu, 8 Feb 2018 11:24:08 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBB0126CF6 for ; Thu, 8 Feb 2018 11:24:08 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id o13so7907788ito.2 for ; Thu, 08 Feb 2018 11:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=izt2+6TEzeBeszuHuybxg+ZAt8hM8O6xGMqV8MOa/8k=; b=gYU7RzNjZo9WMfdW8EhirX3HYaf9DMUxnMIxxj1s63J5E/vEB7+HzBBbo6LNv7XhqF tu5cjs2LqexIguOc9TdLVP1EFgd+z67y9dK0sKEnLkaa9Yut0/lr2XS8BP/B5DfnMVZR 2oK+hLwktQh+JNzroScuc7RLV/NMD1jNDDxnGsEZ602FZ5AyL7WqYvjDyulNwtNYDIib t0u61uexqAGRpfvlr5eqKafSE3poU7/uUEDnYJhsy2vTCRXS7pRSA9USpvCvSAGPLRkx pEtRySfHuKJJ13Tt1RfZjXE+U+LRzFUQ7smmWa3GUD/53qK9TgxzmEHxtvyiWqNeeCVO Ix9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=izt2+6TEzeBeszuHuybxg+ZAt8hM8O6xGMqV8MOa/8k=; b=egXV4EzYQv01hRMzWx0kLo2AIzoSG0eYoG7Exd9GVCYyKGpQpaYRMhB3aXdnh1voF1 Zm8f733GYiBacVC59jAJJawTlykUQT3Ph3ll2jYhvwA7JUXfQ427ntZX/ZnB5vljP9EK h11XI3t13NBbZQEWIyqYf6xRmUHHS2lkOTS9sli/N03u5+q/+oe8vj1b/r0lGkmfMIA5 SC6NrOoIR8P/fn8p76Jkf6nXQRTLfm8pikQp9woPKwdOLlDF67w51TeA5Luc4+PFsB04 57Ze5pybp4KVCm1FkPRGNoHRzELALtj+jl/WuoI2FUzpeb0QNRAth5D/o6XXFZ1eD/uv aReg== X-Gm-Message-State: APf1xPAX7Ye3ZiKLxhOT+RYV793sBAIRGtSOA4j6zfV+7CbE8tjV2Gnt FZsTQ2D5RuDsCEJyCCLswIGfrEt4zV7gUZgoN6zqWA== X-Google-Smtp-Source: AH8x225vLOtckGSnUl9/smP3Ci/JasukT392R45Dd/0PPX1iu8ZWMX2dQzniQCYJtHdbcdQteofmJ3N5e0685eLuVPk= X-Received: by 10.36.224.141 with SMTP id c135mr310152ith.144.1518117847293; Thu, 08 Feb 2018 11:24:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Henck Date: Thu, 08 Feb 2018 19:23:56 +0000 Message-ID: To: rhewitt@akamai.com Cc: ek@google.com, Ben Schwartz , doh@ietf.org, mbishop@evequefou.be Content-Type: multipart/alternative; boundary="94eb2c19e7660467680564b85bf0" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:24:12 -0000 --94eb2c19e7660467680564b85bf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > I am more in favor of a set of simple requirements, so simple client and > server implementation can exist and provide the basics of DOH > functionality. > Optionally, discovery can be used to be more fancy and provide > extensibility, but at the core of it, I would expect that knowing a domai= n > and optionally an IP (to avoid the chicken and egg issue of being able to > resolve the DOH server IP ) should be enough to be able to access DNS ove= r > HTTPS using GET at a well known endpoint. I may be misunderstanding, but doesn't this imply either a fixed path, or a discoverable path via another (e.g. .well-known/dns)? On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory wrote: > Additionally, using /.well-known/ would allow for URI Template discovery, > if required - client retrieves URI Template from e.g. > /.well-known/doh.template and then uses that to build DNS request URI. > > > > See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 for > @mnot's suggestion. > > > > Thanks, > > > > Rory > > > > *Rory Hewitt* > > Senior Solutions Architect > > Global Services & Support > > Akamai Technologies > > Tel: (408) 650-0035 > > > > *From:* Justin Henck [mailto:henck@google.com] > *Sent:* Thursday, February 8, 2018 11:17 AM > *To:* ek@google.com > *Cc:* Ben Schwartz ; doh@ietf.org; mbishop@evequefou.b= e > *Subject:* Re: [Doh] Seeking input on draft-03 > > > > That would work for the situation I specified, but I think that a > .well-known pointer provides the additional benefit of serving more > technical users with an advanced configuration. (It is also in-line with > the intended use of .well-known as I understand RFC 5785.) > > > > Specifically, if an implementer creates an advanced setting whereby you > can configure a DOH server with both a domain and an IP (to eliminate the > need for bootstrapping) then you have made the user's life easier. And, > although a URI is not supposed to change, a .well-known/dns pointer > requirement would ensure that capricious servers don't break > manually-configured clients. > > > > > *Justin Henck* > Product Manager > > 212-565-9811 > > google.com/jigsaw > > > > > PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B > > > > On Thu, Feb 8, 2018 at 1:59 PM Erik Kline wrote: > > Sounds like you might want a (TXT) record at the zone cut level? > > On 8 February 2018 at 10:55, Justin Henck wrote: > > I would like to see a way for clients to discover a DNS server hosted o= n > a > > certain domain. Perhaps a .well-known/dns path that contains a relativ= e > > pointer and other metadata. I'm imagining a use case whereby the user > could > > choose to rely upon an organization that they find trustworthy which is > > offering DNS, without needing to do a significant amount of discovery > (e.g. > > "maybe known.tld has a DNS server?"). You could of course also have an > > absolute pointer, but then you have to account for the situation whereb= y > > known.tld might delegate to unknown.tld. > > > > Justin Henck > > Google > > > > > > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote: > >> > >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop > wrote: > >>> > >>> I=E2=80=99m inclined to think this is a positive change. We=E2=80=99= re trying to do > >>> something better than the current world of =E2=80=9Ctrust the local D= NS server > >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust = just > because a > >>> server claims it support DOH via a .well-known endpoint isn=E2=80=99t= really > any > >>> better. > >> > >> > >> To be clear, the draft never proposed promiscuous trust, which would > >> indeed be highly problematic. However, draft-03 does include addition= al > >> language clarifying this point. > >> > >>> > >>> The client should know the hostname(s) of the DOH server(s) it wants = to > >>> use > >> > >> > >> In draft-03, "knowing the hostname" is not sufficient, because there i= s > no > >> default path for DOH. This is the change on which I am seeking input. > >> > >>> > >>> , and it should authenticate the DOH server against that hostname. > >> > >> > >> Yes, definitely. (I believe the draft is clear on this point, but fee= l > >> free to suggest improvements.) > >> > >>> > >>> If a server hosts content and also wants to also serve DOH, there a= re > >>> ways to present a hostname that covers both names (or present two > >>> certificates) on an HTTP connection. > >>> > >>> > >>> > >>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz > >>> Sent: Thursday, February 8, 2018 10:05 AM > >>> To: doh@ietf.org > >>> Subject: [Doh] Seeking input on draft-03 > >>> > >>> > >>> > >>> Hi all, > >>> > >>> > >>> > >>> The authors of draft-ietf-doh-dns-over-https have been making good > >>> progress, and a draft-03 is now ready with several changes and > >>> clarifications. > >>> > >>> > >>> > >>> One important difference is that draft-03 no longer proposes a > >>> ".well-known" entry. In draft-02 and prior, clients could check for > the > >>> presence of a DOH service at the default path, given only the domain > name of > >>> a server. In draft-03, there is no default path, so clients must be > >>> configured with the full URL of the DOH endpoint. > >>> > >>> > >>> > >>> Is this change compatible with your use cases? Would this alter the > way > >>> users interact with your systems? How do you think DOH client > configuration > >>> should work? > >>> > >>> > >>> > >>> Please respond with your thoughts, > >>> > >>> Ben Schwartz > >> > >> > >> _______________________________________________ > >> Doh mailing list > >> Doh@ietf.org > >> https://www.ietf.org/mailman/listinfo/doh > > > > > > > _______________________________________________ > > Doh mailing list > > Doh@ietf.org > > https://www.ietf.org/mailman/listinfo/doh > > > > > --94eb2c19e7660467680564b85bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am more in favor of a set of simple requirements, so s= imple client and server implementation can exist and provide the basics of = DOH functionality.=C2=A0
Optionally, discov= ery can be used to be more fancy and provide extensibility, but at the core= of it, I would expect that knowing a domain and optionally an IP (to avoid= the chicken and egg issue of being able to resolve the DOH server IP ) sho= uld be enough to be able to access DNS over HTTPS using GET at a well known= endpoint.

I may be misunderstanding= , but doesn't this imply either a fixed path, or a discoverable path vi= a another (e.g. .well-known/dns)?=C2=A0


On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory <rhewitt@akamai.com> wrote:

Additi= onally, using /.well-known/ would allow for URI Template discovery, if requ= ired - client retrieves URI Template from e.g. /.well-known/doh.template an= d then uses that to build DNS request URI.

=C2=A0

See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues= /74 for @mnot's sugg= estion.

=C2=A0

<= span style=3D"font-size:9.0pt;font-family:"Verdana",sans-serif;co= lor:#1f3864">Thanks,

= =C2=A0

Rory

=C2=A0

Rory Hewitt=

Senior Solutions Arch= itect

Global Services & Support=

Akamai = Technologies

Tel: (408) 650= -0035

=C2=A0

From: Justin Henck [mailto:henck@google.com]
Sent: Thursday, February = 8, 2018 11:17 AM
To: ek@google.com
Cc: Ben Schwartz <bemasc@google.com>; doh@ietf.org; mbishop@evequefou.be
Subje= ct: Re: [Doh] Seeking input on draft-03

=C2=A0

That would wor= k for the situation I specified, but I think that a .well-known pointer pro= vides the additional benefit of serving more technical users with an advanc= ed configuration. (It is also in-line with the intended use of .well-known = as I understand RFC 5785.)

= =C2=A0

Specifically, if an = implementer creates an advanced setting whereby you can configure a DOH ser= ver with both a domain and an IP (to eliminate the need for bootstrapping) = then you have made the user's life easier. And, although a URI is not s= upposed to change, a .well-known/dns pointer requirement would ensure that = capricious servers don't break manually-configured clients.


=C2= =A0

Justin Henck=C2=A0
Product Manager=C2=A0

=

212-565-9811=C2=A0

google.com/jigsaw

= =C2=A0

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B<= u>

=C2= =A0

On Thu, Feb 8, 2018 at 1:59 = PM Erik Kline <ek@goo= gle.com> wrote:

Sounds like you might want a = (TXT) record at the zone cut level?

On 8 February 2018 at 10:55, Jus= tin Henck <henck@g= oogle.com> wrote:
> I would like to see a way for clients to d= iscover a DNS server hosted on a
> certain domain.=C2=A0 Perhaps a .w= ell-known/dns path that contains a relative
> pointer and other metad= ata.=C2=A0 I'm imagining a use case whereby the user could
> choo= se to rely upon an organization that they find trustworthy which is
>= offering DNS, without needing to do a significant amount of discovery (e.g= .
> "maybe known.tld has a DNS server?").=C2=A0 You could o= f course also have an
> absolute pointer, but then you have to accoun= t for the situation whereby
> known.tld might delegate to unknown.tld= .
>
> Justin Henck
> Google
>
>
> On Th= u, Feb 8, 2018 at 1:21 PM Ben Schwartz <bemasc@google.com> wrote:
>>
>= > On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be> wrote:
= >>>
>>> I=E2=80=99m inclined to think this is a positi= ve change.=C2=A0 We=E2=80=99re trying to do
>>> something bette= r than the current world of =E2=80=9Ctrust the local DNS server
>>= > because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust j= ust because a
>>> server claims it support DOH via a .well-know= n endpoint isn=E2=80=99t really any
>>> better.
>>
= >>
>> To be clear, the draft never proposed promiscuous trus= t, which would
>> indeed be highly problematic.=C2=A0 However, dra= ft-03 does include additional
>> language clarifying this point.>>
>>>
>>> The client should know the hostn= ame(s) of the DOH server(s) it wants to
>>> use
>>
= >>
>> In draft-03, "knowing the hostname" is not s= ufficient, because there is no
>> default path for DOH.=C2=A0 This= is the change on which I am seeking input.
>>
>>>
= >>> , and it should authenticate the DOH server against that hostn= ame.
>>
>>
>> Yes, definitely.=C2=A0 (I believe = the draft is clear on this point, but feel
>> free to suggest impr= ovements.)
>>
>>>
>>>=C2=A0 =C2=A0If a ser= ver hosts content and also wants to also serve DOH, there are
>>&g= t; ways to present a hostname that covers both names (or present two
>= ;>> certificates) on an HTTP connection.
>>>
>>&= gt;
>>>
>>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of= Ben Schwartz
>>> Sent: Thursday, February 8, 2018 10:05 AM
= >>> To: doh@ietf= .org
>>> Subject: [Doh] Seeking input on draft-03
>&g= t;>
>>>
>>>
>>> Hi all,
>>&= gt;
>>>
>>>
>>> The authors of draft-ie= tf-doh-dns-over-https have been making good
>>> progress, and a= draft-03 is now ready with several changes and
>>> clarificati= ons.
>>>
>>>
>>>
>>> One im= portant difference is that draft-03 no longer proposes a
>>> &q= uot;.well-known" entry.=C2=A0 In draft-02 and prior, clients could che= ck for the
>>> presence of a DOH service at the default path, g= iven only the domain name of
>>> a server.=C2=A0 In draft-03, t= here is no default path, so clients must be
>>> configured with= the full URL of the DOH endpoint.
>>>
>>>
>&= gt;>
>>> Is this change compatible with your use cases?=C2= =A0 Would this alter the way
>>> users interact with your syste= ms?=C2=A0 How do you think DOH client configuration
>>> should = work?
>>>
>>>
>>>
>>> Pleas= e respond with your thoughts,
>>>
>>> Ben Schwartz<= br>>>
>>
>> _______________________________________= ________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh
>
>
&= gt; _______________________________________________
> Doh mailing lis= t
> Doh@ietf.org
> https://www.ietf.org/mailman/listin= fo/doh
>

--94eb2c19e7660467680564b85bf0-- From nobody Thu Feb 8 11:57:05 2018 Return-Path: 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 573A5126C25 for ; Thu, 8 Feb 2018 11:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 258fHBqqQ955 for ; Thu, 8 Feb 2018 11:57:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013351267BB for ; Thu, 8 Feb 2018 11:57:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 86FE4BE39; Thu, 8 Feb 2018 19:56:59 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fe-sxGtMmzJ7; Thu, 8 Feb 2018 19:56:58 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E7ADBDCC; Thu, 8 Feb 2018 19:56:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518119818; bh=FPs9unAiDwrxgqUMzc5dGgvAwAoAMEzOKroThID+cvk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=N3STpI3VDqlNdDfY8a5mg9TBzDahay65B6YS1RrFIok7CxhXTUNxHaOlhSXGd0iyA oHbYoqiB9U5BcxMZoGdYixA8MAl0a0eQS5yei0brMUYL7nCVn5+aGiWoitF78310Cn ajGaFjYiHw3TrcwIWw/wJ9/o2dFKASyfZD8CFmm8= To: Ben Schwartz , doh@ietf.org References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> Date: Thu, 8 Feb 2018 19:56:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="s2mv8zxOBaM9kS7fN5mcKMqchlxEfJBmS" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:57:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s2mv8zxOBaM9kS7fN5mcKMqchlxEfJBmS Content-Type: multipart/mixed; boundary="xmj9kSPvKqWJEd5YCNzKfsTRMXga7OV8u"; protected-headers="v1" From: Stephen Farrell To: Ben Schwartz , doh@ietf.org Message-ID: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> Subject: Re: [Doh] Seeking input on draft-03 References: In-Reply-To: --xmj9kSPvKqWJEd5YCNzKfsTRMXga7OV8u Content-Type: multipart/mixed; boundary="------------FB5876D8DE95C751E1963901" Content-Language: en-GB This is a multi-part message in MIME format. --------------FB5876D8DE95C751E1963901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/02/18 18:05, Ben Schwartz wrote: >=20 > One important difference is that draft-03 no longer proposes a > ".well-known" entry. In draft-02 and prior, clients could check for th= e > presence of a DOH service at the default path, given only the domain na= me > of a server. In draft-03, there is no default path, so clients must be= > configured with the full URL of the DOH endpoint. Apologies if I'm forgetting a thread where this was discussed, but what's the reason for dropping .well-known? (If there is a thread, a pointer to that is a sufficient answer.) Thanks, S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------FB5876D8DE95C751E1963901 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------FB5876D8DE95C751E1963901-- --xmj9kSPvKqWJEd5YCNzKfsTRMXga7OV8u-- --s2mv8zxOBaM9kS7fN5mcKMqchlxEfJBmS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJafKuKAAoJEFqy+vF7FyvqjeMQAIE9PYywS2AT3jUfzSVhjV3c znbuiNLmGiK8ofQUuduskQXOA8IwPNtajcrYz+/MtGQh9a7ZZTHMizStz2G7SCYQ Bnl8jsBsBclbHVwRbcSfKKuucHDCHiLUPmSXsOib4ZYV6aq4jJmtO7Nufrs9juck WevUtISVR43qiUblHPV4ntyHtvlsYctykYp9BNPQYt0s6FbD+zsSyZmD/9qYWyCV Ezo5dkuu7oFaWL5eYQGt+n6gZTXRGTQixREJ1NJmjricicZYmvISZWzKENPx6Xb+ nBvMM8hrQZVZqhLcSntLQYEtCItoFL1UmUrevgnhd07475CSj1J2a9eqZFZ6A1Mf U9J8wwCczpvDl1HV81A0+utCUY/5Dpp1TTHVpBGwzWsaz/MwQGDaOUGz5MxQfU6e GQXjx+E5TmphBRBpx6RrguYGLMy0Mu8AIiF5i+LqBDVbYbJZQg+elJbLeUqK7EQj UIQI5CLMz7+fqRwsrPo2GGLfiw6Aj+emPO615LOFpEzqvFSoBw/JaDGITOXThyhQ uGK1mKBb+cTgfNeWw/sQTcaFPHy0Ie16II7R3oa3f/gTnK3aIzNKShFlfTTJR+yx vSb7pbf2mJ8SKkUk/fhlD5iKQScnaft7qYgw644DN2u+gOoPZ4G9zKeHmWx22Ppj feFBbxYco1sZc/rWiMjY =4w5M -----END PGP SIGNATURE----- --s2mv8zxOBaM9kS7fN5mcKMqchlxEfJBmS-- From nobody Thu Feb 8 12:24:24 2018 Return-Path: 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 234F2127275 for ; Thu, 8 Feb 2018 12:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 zLph5V_SMgLf for ; Thu, 8 Feb 2018 12:24:20 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 673FF127076 for ; Thu, 8 Feb 2018 12:24:20 -0800 (PST) Received: from mail-ot0-f182.google.com (mail-ot0-f182.google.com [74.125.82.182]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6008E3A054 for ; Thu, 8 Feb 2018 15:24:18 -0500 (EST) Received: by mail-ot0-f182.google.com with SMTP id r23so5555669ote.8 for ; Thu, 08 Feb 2018 12:24:18 -0800 (PST) X-Gm-Message-State: APf1xPCFr+NLRdMUDtXOJ635nCwfZc0+ZrmbrYpYt5oe+O6q2rLSucf5 m3Wj3sOcX0FlplFtOJdX3pBepZeIlZbvpbFBO5Y= X-Google-Smtp-Source: AH8x226BTyPoIbSkgZ9236rI2XfpWEafedmhFdQDwubVj0mq0Ye39UNScmdYXbz5OLTZTizP/mSDjwtqUkjtjKz/HJ8= X-Received: by 10.157.81.197 with SMTP id d5mr396062oth.300.1518121457995; Thu, 08 Feb 2018 12:24:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.95.80 with HTTP; Thu, 8 Feb 2018 12:24:17 -0800 (PST) In-Reply-To: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> References: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> From: Patrick McManus Date: Thu, 8 Feb 2018 15:24:17 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Stephen Farrell Cc: Ben Schwartz , doh@ietf.org Content-Type: multipart/alternative; boundary="f403043d7ef03aee320564b93248" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 20:24:23 -0000 --f403043d7ef03aee320564b93248 Content-Type: text/plain; charset="UTF-8" WRT the removal of .wk: * its previous presence had never been meant as a discovery mechanism of the form "I know a hostname, therefore I know the URL". origin is a security primitive for http, but its not an addressing primitive for http services such as a DoH endpoint.. indeed the DoH server might sensibly wish to offer multiple URIs on the same host (in the same way some free dns providers make a variety of resolution policies available with different IP addresses). The configuration primitive for a DoH server is the URI - not origin. * I had originally included .wk as a bit of future proofing for a use case not part of the DoH charter (not to enable it, but being sure not to preclude it at a later time). I have been convinced that .wk is not necessary for that - and so it was removed from the draft. I regret that these two things were confused by readers of <= -02 due to my own composition skills (or lack thereof). As to Stephen's query - this was both discussed f2f in singapore and https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/24 . Of course there hasn't been consensus declared on the issue - the editors are just trying to make the newer drafts as closely aligned with the group's discussion as we can manage as part of the process. -P On Thu, Feb 8, 2018 at 2:56 PM, Stephen Farrell wrote: > > > On 08/02/18 18:05, Ben Schwartz wrote: > > > > One important difference is that draft-03 no longer proposes a > > ".well-known" entry. In draft-02 and prior, clients could check for the > > presence of a DOH service at the default path, given only the domain name > > of a server. In draft-03, there is no default path, so clients must be > > configured with the full URL of the DOH endpoint. > > Apologies if I'm forgetting a thread where this was discussed, > but what's the reason for dropping .well-known? (If there is a > thread, a pointer to that is a sufficient answer.) > > Thanks, > S. > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --f403043d7ef03aee320564b93248 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
WRT the removal of .wk:

* its previous presence had never been meant as a discovery mechanism of t= he form "I know a hostname, therefore I know the URL". origin is = a security primitive for http, but its not an addressing primitive for http= services such as a DoH endpoint.. indeed the DoH server might sensibly wis= h to offer multiple URIs on the same host (in the same way some free dns pr= oviders make a variety of resolution policies available with different IP a= ddresses).=C2=A0 The configuration primitive for a DoH server is the URI - = not origin.

* I had originally included .wk as= a bit of future proofing for a use case not part of the DoH charter (not t= o enable it, but being sure not to preclude it at a later time). I have bee= n convinced that .wk is not necessary for that - and so it was removed from= the draft. I regret that these two things were confused by readers of <= =3D -02 due to my own composition skills (or lack thereof).
<= br>
As to Stephen's query - this was both discussed f2f in si= ngapore and https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues= /24 . Of course there hasn't been consensus declared on the issue -= the editors are just trying to make the newer drafts as closely aligned wi= th the group's discussion as we can manage as part of the process.
<= /div>

-P


On Thu, Feb 8, 2018 at 2:56 PM, Stephe= n Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 08/02/18 18:05, Ben Schwartz wrote:
>
> One important difference is that draft-03 no longer proposes a
> ".well-known" entry.=C2=A0 In draft-02 and prior, clients co= uld check for the
> presence of a DOH service at the default path, given only the domain n= ame
> of a server.=C2=A0 In draft-03, there is no default path, so clients m= ust be
> configured with the full URL of the DOH endpoint.

Apologies if I'm forgetting a thread where this was discussed, but what's the reason for dropping .well-known? (If there is a
thread, a pointer to that is a sufficient answer.)

Thanks,
S.

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--f403043d7ef03aee320564b93248-- From nobody Thu Feb 8 13:36:20 2018 Return-Path: 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 6C96012D7E5 for ; Thu, 8 Feb 2018 13:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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=gmail.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 as2lys-Y2Lk1 for ; Thu, 8 Feb 2018 13:36:15 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5405112751F for ; Thu, 8 Feb 2018 13:36:14 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id a204so8432338lfa.2 for ; Thu, 08 Feb 2018 13:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EptNbqgwVYxbWL2Bof59m09oVfdaCnfsz44ZLy/yJ4Q=; b=TaZhv5997u/RRZZvDyyY25pskZX7wO98uptwoyLEedVZp72ao7QxW8Ta+gepnyxVqJ swCGVBXkDTpFCBWFJsOzE3hlVp+wX40Av/oZ33q1pGvpslN/8+PhmJlbcKTZYsiJd/+C FZ+xGWNopaHj/37ayXWaKfD9FYl6VhZkSCnbLI29QGdz5Xok+hp33Tk1KTV3v2Jk5IBT dMxnuG+s12fXO+war7J1WD7+/d9KqqSaksKHILA+gX7Zt2Ad4u0PJ5k2ctJqRWuRryfO cuh/TkEW4mJFX0i5xC5ttFT9Kd4P7QFW88qzlW79wZiNi7IEuX/RRcNQGDTTV1wd1zqS JTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EptNbqgwVYxbWL2Bof59m09oVfdaCnfsz44ZLy/yJ4Q=; b=Q0h2yy9c264vZ0Ht0vIVGklF+ltFpS2DHG+B7PH8A0yvSkvtsLzEN8Sy9sL05z1br7 OMZC3JDGIqhRZqs7LP70b5IORUdnF9KIYFbayk2M/nv/6zpHiLbD3XRA4AgcDnpd3muM Ktn6MGegwfvj7ueEWoE7cGlgz1ukQRWMBfemuVKs9+/BQ33RZC4gZvO/daTw7H1SxSvS mFaqFHuvpASwXJgXWJO6PjiWDpq79hz5yFct8AeMw1qBI60bYJ3Tw5lKBONHFT98L+5M hGIZQso8gXS5b+2rsYj4uTtsbZuZBReZzSeaTyXLWX/NFWz+hL1e9+PkKkQrhxAs/QVS VszQ== X-Gm-Message-State: APf1xPA2cvr7V+oEBFJ7FGrzui6VQqNEmg3JTJNQMvJOm7/eTE/JALeS RBCZT9YO/eJmJirRtxHoqF1o+8PSwP4KBT+pUjw= X-Google-Smtp-Source: AH8x226g8gSVy+j30cl3hNOT3t/jGLXlcK8yQv6xmkBba0ejWHoEvUBDi51DlLLTBXTmxiuwIJaW/ORpn+Q/zaHJxQA= X-Received: by 10.46.17.91 with SMTP id f88mr382664lje.54.1518125772397; Thu, 08 Feb 2018 13:36:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.227.5 with HTTP; Thu, 8 Feb 2018 13:36:11 -0800 (PST) In-Reply-To: References: From: manu tman Date: Thu, 8 Feb 2018 13:36:11 -0800 Message-ID: To: Justin Henck Cc: rhewitt@akamai.com, Ben Schwartz , ek@google.com, doh@ietf.org, mbishop@evequefou.be Content-Type: multipart/alternative; boundary="94eb2c1c0a1c6361050564ba332f" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 21:36:18 -0000 --94eb2c1c0a1c6361050564ba332f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2018 at 11:23 AM, Justin Henck wrote: > I am more in favor of a set of simple requirements, so simple client and >> server implementation can exist and provide the basics of DOH >> functionality. >> Optionally, discovery can be used to be more fancy and provide >> extensibility, but at the core of it, I would expect that knowing a doma= in >> and optionally an IP (to avoid the chicken and egg issue of being able t= o >> resolve the DOH server IP ) should be enough to be able to access DNS ov= er >> HTTPS using GET at a well known endpoint. > > > I may be misunderstanding, but doesn't this imply either a fixed path, or > a discoverable path via another (e.g. .well-known/dns)? > Yes, I mean to have a fixed well-known path that provides DOH service (as in actual DNS queries) that can be used universally. So, any clients, given a domain, can use DOH without having to go through the steps of service discovery indirections. What I understood from you original comment was to use this as an entry point to discover alternate locations, delegation... I think it is worth it but should be optional. At the end of the day, either accessing a discovery endpoint or DOH service endpoint, the client will need to be told where to get it. Having a predefined entry point would make this easier. > > > On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory wrote: > >> Additionally, using /.well-known/ would allow for URI Template discovery= , >> if required - client retrieves URI Template from e.g. >> /.well-known/doh.template and then uses that to build DNS request URI. >> >> >> >> See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 for >> @mnot's suggestion. >> >> >> >> Thanks, >> >> >> >> Rory >> >> >> >> *Rory Hewitt* >> >> Senior Solutions Architect >> >> Global Services & Support >> >> Akamai Technologies >> >> Tel: (408) 650-0035 >> >> >> >> *From:* Justin Henck [mailto:henck@google.com] >> *Sent:* Thursday, February 8, 2018 11:17 AM >> *To:* ek@google.com >> *Cc:* Ben Schwartz ; doh@ietf.org; >> mbishop@evequefou.be >> *Subject:* Re: [Doh] Seeking input on draft-03 >> >> >> >> That would work for the situation I specified, but I think that a >> .well-known pointer provides the additional benefit of serving more >> technical users with an advanced configuration. (It is also in-line with >> the intended use of .well-known as I understand RFC 5785.) >> >> >> >> Specifically, if an implementer creates an advanced setting whereby you >> can configure a DOH server with both a domain and an IP (to eliminate th= e >> need for bootstrapping) then you have made the user's life easier. And, >> although a URI is not supposed to change, a .well-known/dns pointer >> requirement would ensure that capricious servers don't break >> manually-configured clients. >> >> >> >> >> *Justin Henck* >> Product Manager >> >> 212-565-9811 <(212)%20565-9811> >> >> google.com/jigsaw >> >> >> >> >> PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B >> >> >> >> On Thu, Feb 8, 2018 at 1:59 PM Erik Kline wrote: >> >> Sounds like you might want a (TXT) record at the zone cut level? >> >> On 8 February 2018 at 10:55, Justin Henck wrote: >> > I would like to see a way for clients to discover a DNS server hosted >> on a >> > certain domain. Perhaps a .well-known/dns path that contains a relati= ve >> > pointer and other metadata. I'm imagining a use case whereby the user >> could >> > choose to rely upon an organization that they find trustworthy which i= s >> > offering DNS, without needing to do a significant amount of discovery >> (e.g. >> > "maybe known.tld has a DNS server?"). You could of course also have a= n >> > absolute pointer, but then you have to account for the situation where= by >> > known.tld might delegate to unknown.tld. >> > >> > Justin Henck >> > Google >> > >> > >> > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote: >> >> >> >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop >> wrote: >> >>> >> >>> I=E2=80=99m inclined to think this is a positive change. We=E2=80= =99re trying to do >> >>> something better than the current world of =E2=80=9Ctrust the local = DNS server >> >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trust= just >> because a >> >>> server claims it support DOH via a .well-known endpoint isn=E2=80=99= t really >> any >> >>> better. >> >> >> >> >> >> To be clear, the draft never proposed promiscuous trust, which would >> >> indeed be highly problematic. However, draft-03 does include >> additional >> >> language clarifying this point. >> >> >> >>> >> >>> The client should know the hostname(s) of the DOH server(s) it wants >> to >> >>> use >> >> >> >> >> >> In draft-03, "knowing the hostname" is not sufficient, because there >> is no >> >> default path for DOH. This is the change on which I am seeking input= . >> >> >> >>> >> >>> , and it should authenticate the DOH server against that hostname. >> >> >> >> >> >> Yes, definitely. (I believe the draft is clear on this point, but fe= el >> >> free to suggest improvements.) >> >> >> >>> >> >>> If a server hosts content and also wants to also serve DOH, there >> are >> >>> ways to present a hostname that covers both names (or present two >> >>> certificates) on an HTTP connection. >> >>> >> >>> >> >>> >> >>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz >> >>> Sent: Thursday, February 8, 2018 10:05 AM >> >>> To: doh@ietf.org >> >>> Subject: [Doh] Seeking input on draft-03 >> >>> >> >>> >> >>> >> >>> Hi all, >> >>> >> >>> >> >>> >> >>> The authors of draft-ietf-doh-dns-over-https have been making good >> >>> progress, and a draft-03 is now ready with several changes and >> >>> clarifications. >> >>> >> >>> >> >>> >> >>> One important difference is that draft-03 no longer proposes a >> >>> ".well-known" entry. In draft-02 and prior, clients could check for >> the >> >>> presence of a DOH service at the default path, given only the domain >> name of >> >>> a server. In draft-03, there is no default path, so clients must be >> >>> configured with the full URL of the DOH endpoint. >> >>> >> >>> >> >>> >> >>> Is this change compatible with your use cases? Would this alter the >> way >> >>> users interact with your systems? How do you think DOH client >> configuration >> >>> should work? >> >>> >> >>> >> >>> >> >>> Please respond with your thoughts, >> >>> >> >>> Ben Schwartz >> >> >> >> >> >> _______________________________________________ >> >> Doh mailing list >> >> Doh@ietf.org >> >> https://www.ietf.org/mailman/listinfo/doh >> >> > >> > >> > _______________________________________________ >> > Doh mailing list >> > Doh@ietf.org >> > https://www.ietf.org/mailman/listinfo/doh >> >> > >> >> > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --94eb2c1c0a1c6361050564ba332f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 11:23 AM, Justin Henck <henck@google.com>= wrote:
I am more in favor of a set of simple requirements, so simple cli= ent and server implementation can exist and provide the basics of DOH funct= ionality.=C2=A0
Optionally, discovery can b= e used to be more fancy and provide extensibility, but at the core of it, I= would expect that knowing a domain and optionally an IP (to avoid the chic= ken and egg issue of being able to resolve the DOH server IP ) should be en= ough to be able to access DNS over HTTPS using GET at a well known endpoint= .

I may be misunderstanding, = but doesn't this imply either a fixed path, or a discoverable path via = another (e.g. .well-known/dns)?=C2=A0

Yes, I mean to have a fixed well-known path that provides DOH servic= e (as in actual DNS queries) that can be used universally. So, any clients,= given a domain, can use DOH without having to go through the steps of serv= ice discovery indirections.
What I understood from you original c= omment was to use this as an entry point to discover alternate locations, d= elegation... I think it is worth it but should be optional.

At the end of the day, either accessing a discovery endpoint or DOH serv= ice endpoint, the client will need to be told where to get it. Having a pre= defined entry point would make this easier.
=C2=A0


On Thu, Feb 8, 2018 at 2:22 PM Hewit= t, Rory <rhewitt= @akamai.com> wrote:

A= dditionally, using /.well-known/ would allow for URI Template discovery, if= required - client retrieves URI Template from e.g. /.well-known/doh.templa= te and then uses that to build DNS request URI.

=C2=A0

See https://github.com/dohwg/draft-ietf-doh-dns-over-ht= tps/issues/74 for @= mnot's suggestion.

=C2=A0

Thanks,

=C2=A0

Rory

=C2=A0

Rory Hewitt=

Senior= Solutions Architect

= Global Services & Support

Akamai Technologies

Tel: (408) 650-0035

=C2=A0

From: Justin Henck [mailto:henck@google.com]
Sent:= Thursday, February 8, 2018 11:17 AM
To: ek@google.com
Cc: Ben Schwartz <= ;bemasc@google.com>; doh@ietf.org;= mbishop@evequefo= u.be
Subject: Re: [Doh] Seeking input on draft-03

=C2=A0

That would work for the situation I specified, but I think that a .we= ll-known pointer provides the additional benefit of serving more technical = users with an advanced configuration. (It is also in-line with the intended= use of .well-known as I understand RFC 5785.)

=C2=A0

= Specifically, if an implementer creates an advanced setting whereby you can= configure a DOH server with both a domain and an IP (to eliminate the need= for bootstrapping) then you have made the user's life easier. And, alt= hough a URI is not supposed to change, a .well-known/dns pointer requiremen= t would ensure that capricious servers don't break manually-configured = clients.


=C2=A0

=

Justin = Henck=C2=A0
Product Manager=C2=A0<= /span>

212-565-9811=C2=A0=

google.com/jigsaw=

=C2=A0

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B

<= /div>

=C2=A0

On Thu, Feb 8, 2= 018 at 1:59 PM Erik Kline <ek@google.com> wrote:

Sounds like you m= ight want a (TXT) record at the zone cut level?

On 8 February 2018 a= t 10:55, Justin Henck <henck@google.com> wrote:
> I would like to see a way for = clients to discover a DNS server hosted on a
> certain domain.=C2=A0 = Perhaps a .well-known/dns path that contains a relative
> pointer and= other metadata.=C2=A0 I'm imagining a use case whereby the user could<= br>> choose to rely upon an organization that they find trustworthy whic= h is
> offering DNS, without needing to do a significant amount of di= scovery (e.g.
> "maybe known.tld has a DNS server?").=C2=A0= You could of course also have an
> absolute pointer, but then you ha= ve to account for the situation whereby
> known.tld might delegate to= unknown.tld.
>
> Justin Henck
> Google
>
>> On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <bemasc@google.com> wrote:
>= >
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <mbishop@evequefou.be>= ; wrote:
>>>
>>> I=E2=80=99m inclined to think this= is a positive change.=C2=A0 We=E2=80=99re trying to do
>>> som= ething better than the current world of =E2=80=9Ctrust the local DNS server=
>>> because unauthenticated DHCP says so=E2=80=9D, and promisc= uous trust just because a
>>> server claims it support DOH via = a .well-known endpoint isn=E2=80=99t really any
>>> better.
= >>
>>
>> To be clear, the draft never proposed prom= iscuous trust, which would
>> indeed be highly problematic.=C2=A0 = However, draft-03 does include additional
>> language clarifying t= his point.
>>
>>>
>>> The client should kn= ow the hostname(s) of the DOH server(s) it wants to
>>> use
= >>
>>
>> In draft-03, "knowing the hostname&qu= ot; is not sufficient, because there is no
>> default path for DOH= .=C2=A0 This is the change on which I am seeking input.
>>
>= >>
>>> , and it should authenticate the DOH server agains= t that hostname.
>>
>>
>> Yes, definitely.=C2=A0= (I believe the draft is clear on this point, but feel
>> free to = suggest improvements.)
>>
>>>
>>>=C2=A0 = =C2=A0If a server hosts content and also wants to also serve DOH, there are=
>>> ways to present a hostname that covers both names (or pres= ent two
>>> certificates) on an HTTP connection.
>>>= ;
>>>
>>>
>>> From: Doh [mailto:doh-bounces@ietf.org= ] On Behalf Of Ben Schwartz
>>> Sent: Thursday, February 8, 201= 8 10:05 AM
>>> To: doh@ietf.org
>>> Subject: [Doh] Seeking input on draf= t-03
>>>
>>>
>>>
>>> Hi all= ,
>>>
>>>
>>>
>>> The autho= rs of draft-ietf-doh-dns-over-https have been making good
>>> p= rogress, and a draft-03 is now ready with several changes and
>>&g= t; clarifications.
>>>
>>>
>>>
>&= gt;> One important difference is that draft-03 no longer proposes a
&= gt;>> ".well-known" entry.=C2=A0 In draft-02 and prior, cli= ents could check for the
>>> presence of a DOH service at the d= efault path, given only the domain name of
>>> a server.=C2=A0 = In draft-03, there is no default path, so clients must be
>>> c= onfigured with the full URL of the DOH endpoint.
>>>
>>= ;>
>>>
>>> Is this change compatible with your u= se cases?=C2=A0 Would this alter the way
>>> users interact wit= h your systems?=C2=A0 How do you think DOH client configuration
>>= > should work?
>>>
>>>
>>>
>&g= t;> Please respond with your thoughts,
>>>
>>> B= en Schwartz
>>
>>
>> ___________________________= ____________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh=
>
>
> _________________________________________= ______
> Doh mailing list
> Doh@ietf.org
> https= ://www.ietf.org/mailman/listinfo/doh
>


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--94eb2c1c0a1c6361050564ba332f-- From nobody Thu Feb 8 14:55:32 2018 Return-Path: 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 A5CDB1270A7 for ; Thu, 8 Feb 2018 14:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 QMdVS_VshToA for ; Thu, 8 Feb 2018 14:55:26 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32D41205F0 for ; Thu, 8 Feb 2018 14:55:26 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id t22so7601871ioa.7 for ; Thu, 08 Feb 2018 14:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0zkAlAAL2hmhm0NWCwVnAgcE1Vt6uxuPUfi90kn6g8A=; b=pI7SCb6P7K7oKsR98hONf2jJ2L76L15NN15B6DXTBdON1G2ra9hrJzAZwgtnUIv6x3 k4qGASy+TfbPVeKimINqhYiPVZQf+0nFjM4OIF8Zwrh5usOy2WiduSo3k+GDeBOmTl6f wwIibYHuqicNQ4tRp5ciFGWw0U8H6Ki4Xq8QUQOGFawaqAay57m2/8UCSeHD6npZO7La I3kMvXEEkFZ0WPDFp3nLnuBREFHAHiSF+CQbgf/PD1MgZ4wy7eudLjN4MPyH7kQJ78mr /neiFSDKfrtvB4zNsqqvut5hrVcss+YZ4UGGbugigh9p/VXlmnilGwL6abp/6nnW9xEC CStA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0zkAlAAL2hmhm0NWCwVnAgcE1Vt6uxuPUfi90kn6g8A=; b=ZBNjObUI9e94ZkslpSwBFYz83rKnm2onBwPCFQxhjvvHFGx5fdbW5B9vOIycpoNN/f +KG74U+bCdTyT7tkgoKdUMLSPhbUxemwKh5FPCKxpUq/iLn9jH6VgrZbC32Aarn80E/F rP/Iyk3eEtCPmjiLhLszz6mZSWhi/Gf9g5QaMtnqxd4VDPmnuYojACKK7V/NNilEm403 2gqS4WtZSOJ8jbTDVPWXcq9KvQhtyPfy50aAW0QqV+YiV9eL0k13/vBCMXNOykgKsXcj ePWWlOSwkdSh2TpY9JfP0gjilxTGayOZMFr3bkmMMSdUlMSK+sr6aFgw92wzAlZYoJRm HHdA== X-Gm-Message-State: APf1xPClVvjKTvKt9RUE0J4eoQEWo32c4jOxcQZS2AD79edG/xQQ0CoV XLjt3OJqTVRTmi2OXmgpbAgEEFeenGOZCKyIXKNUfw== X-Google-Smtp-Source: AH8x224xlYuyo8DcV3ZI+H/dY3mM5DBKErxoQmgvoVjCTuXRj6rt0+KMiFneb0pHRAqbEAfeSIhVy5JmB3n0cml9UxE= X-Received: by 10.107.201.136 with SMTP id z130mr1041966iof.257.1518130525267; Thu, 08 Feb 2018 14:55:25 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Justin Henck Date: Thu, 08 Feb 2018 22:55:14 +0000 Message-ID: To: chantr4@gmail.com Cc: rhewitt@akamai.com, Ben Schwartz , ek@google.com, doh@ietf.org, mbishop@evequefou.be Content-Type: multipart/alternative; boundary="94eb2c0b8cd8af42490564bb4e4d" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 22:55:31 -0000 --94eb2c0b8cd8af42490564bb4e4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > What I understood from you original comment was to use this as an entry > point to discover alternate locations, delegation... I think it is worth = it > but should be optional. Got it. I understand the desire for simplicity, and would also prefer to avoid complex solutions. My specific goal is to enable users to reliably and easily configure a trusted DOH server of their choice without bootstrapping. On Thu, Feb 8, 2018 at 4:36 PM manu tman wrote: > > > On Thu, Feb 8, 2018 at 11:23 AM, Justin Henck wrote: > >> I am more in favor of a set of simple requirements, so simple client and >>> server implementation can exist and provide the basics of DOH >>> functionality. >>> Optionally, discovery can be used to be more fancy and provide >>> extensibility, but at the core of it, I would expect that knowing a dom= ain >>> and optionally an IP (to avoid the chicken and egg issue of being able = to >>> resolve the DOH server IP ) should be enough to be able to access DNS o= ver >>> HTTPS using GET at a well known endpoint. >> >> >> I may be misunderstanding, but doesn't this imply either a fixed path, o= r >> a discoverable path via another (e.g. .well-known/dns)? >> > > Yes, I mean to have a fixed well-known path that provides DOH service (as > in actual DNS queries) that can be used universally. So, any clients, giv= en > a domain, can use DOH without having to go through the steps of service > discovery indirections. > What I understood from you original comment was to use this as an entry > point to discover alternate locations, delegation... I think it is worth = it > but should be optional. > > At the end of the day, either accessing a discovery endpoint or DOH > service endpoint, the client will need to be told where to get it. Having= a > predefined entry point would make this easier. > > >> >> >> On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory wrote: >> >>> Additionally, using /.well-known/ would allow for URI Template >>> discovery, if required - client retrieves URI Template from e.g. >>> /.well-known/doh.template and then uses that to build DNS request URI. >>> >>> >>> >>> See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 >>> for @mnot's suggestion. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Rory >>> >>> >>> >>> *Rory Hewitt* >>> >>> Senior Solutions Architect >>> >>> Global Services & Support >>> >>> Akamai Technologies >>> >>> Tel: (408) 650-0035 >>> >>> >>> >>> *From:* Justin Henck [mailto:henck@google.com] >>> *Sent:* Thursday, February 8, 2018 11:17 AM >>> *To:* ek@google.com >>> *Cc:* Ben Schwartz ; doh@ietf.org; >>> mbishop@evequefou.be >>> *Subject:* Re: [Doh] Seeking input on draft-03 >>> >>> >>> >>> That would work for the situation I specified, but I think that a >>> .well-known pointer provides the additional benefit of serving more >>> technical users with an advanced configuration. (It is also in-line wit= h >>> the intended use of .well-known as I understand RFC 5785.) >>> >>> >>> >>> Specifically, if an implementer creates an advanced setting whereby you >>> can configure a DOH server with both a domain and an IP (to eliminate t= he >>> need for bootstrapping) then you have made the user's life easier. And, >>> although a URI is not supposed to change, a .well-known/dns pointer >>> requirement would ensure that capricious servers don't break >>> manually-configured clients. >>> >>> >>> >>> >>> *Justin Henck* >>> Product Manager >>> >>> 212-565-9811 <(212)%20565-9811> >>> >>> google.com/jigsaw >>> >>> >>> >>> >>> PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B >>> >>> >>> >>> On Thu, Feb 8, 2018 at 1:59 PM Erik Kline wrote: >>> >>> Sounds like you might want a (TXT) record at the zone cut level? >>> >>> On 8 February 2018 at 10:55, Justin Henck wrote: >>> > I would like to see a way for clients to discover a DNS server hosted >>> on a >>> > certain domain. Perhaps a .well-known/dns path that contains a >>> relative >>> > pointer and other metadata. I'm imagining a use case whereby the use= r >>> could >>> > choose to rely upon an organization that they find trustworthy which = is >>> > offering DNS, without needing to do a significant amount of discovery >>> (e.g. >>> > "maybe known.tld has a DNS server?"). You could of course also have = an >>> > absolute pointer, but then you have to account for the situation >>> whereby >>> > known.tld might delegate to unknown.tld. >>> > >>> > Justin Henck >>> > Google >>> > >>> > >>> > On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz wrote= : >>> >> >>> >> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop >>> wrote: >>> >>> >>> >>> I=E2=80=99m inclined to think this is a positive change. We=E2=80= =99re trying to do >>> >>> something better than the current world of =E2=80=9Ctrust the local= DNS >>> server >>> >>> because unauthenticated DHCP says so=E2=80=9D, and promiscuous trus= t just >>> because a >>> >>> server claims it support DOH via a .well-known endpoint isn=E2=80= =99t really >>> any >>> >>> better. >>> >> >>> >> >>> >> To be clear, the draft never proposed promiscuous trust, which would >>> >> indeed be highly problematic. However, draft-03 does include >>> additional >>> >> language clarifying this point. >>> >> >>> >>> >>> >>> The client should know the hostname(s) of the DOH server(s) it want= s >>> to >>> >>> use >>> >> >>> >> >>> >> In draft-03, "knowing the hostname" is not sufficient, because there >>> is no >>> >> default path for DOH. This is the change on which I am seeking inpu= t. >>> >> >>> >>> >>> >>> , and it should authenticate the DOH server against that hostname. >>> >> >>> >> >>> >> Yes, definitely. (I believe the draft is clear on this point, but >>> feel >>> >> free to suggest improvements.) >>> >> >>> >>> >>> >>> If a server hosts content and also wants to also serve DOH, there >>> are >>> >>> ways to present a hostname that covers both names (or present two >>> >>> certificates) on an HTTP connection. >>> >>> >>> >>> >>> >>> >>> >>> From: Doh [mailto:doh-bounces@ietf.org] On Behalf Of Ben Schwartz >>> >>> Sent: Thursday, February 8, 2018 10:05 AM >>> >>> To: doh@ietf.org >>> >>> Subject: [Doh] Seeking input on draft-03 >>> >>> >>> >>> >>> >>> >>> >>> Hi all, >>> >>> >>> >>> >>> >>> >>> >>> The authors of draft-ietf-doh-dns-over-https have been making good >>> >>> progress, and a draft-03 is now ready with several changes and >>> >>> clarifications. >>> >>> >>> >>> >>> >>> >>> >>> One important difference is that draft-03 no longer proposes a >>> >>> ".well-known" entry. In draft-02 and prior, clients could check fo= r >>> the >>> >>> presence of a DOH service at the default path, given only the domai= n >>> name of >>> >>> a server. In draft-03, there is no default path, so clients must b= e >>> >>> configured with the full URL of the DOH endpoint. >>> >>> >>> >>> >>> >>> >>> >>> Is this change compatible with your use cases? Would this alter th= e >>> way >>> >>> users interact with your systems? How do you think DOH client >>> configuration >>> >>> should work? >>> >>> >>> >>> >>> >>> >>> >>> Please respond with your thoughts, >>> >>> >>> >>> Ben Schwartz >>> >> >>> >> >>> >> _______________________________________________ >>> >> Doh mailing list >>> >> Doh@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/doh >>> >>> > >>> > >>> > _______________________________________________ >>> > Doh mailing list >>> > Doh@ietf.org >>> > https://www.ietf.org/mailman/listinfo/doh >>> >>> > >>> >>> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> >> > --94eb2c0b8cd8af42490564bb4e4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What I understood from you original comment was to use t= his as an entry point to discover alternate locations, delegation... I thin= k it is worth it but should be optional.

=
Got it.=C2=A0 I understand the desire for simplicity, and would also p= refer to avoid complex solutions.=C2=A0 My specific goal is to enable users= to reliably and easily configure a trusted DOH server of their choice with= out bootstrapping.


On Thu, Feb 8, 2018 at 4:36 PM manu tman <chantr4@gmail.com> wrote:
<= /div>


On Thu, Feb 8, 2018 at 11:23 AM, Ju= stin Henck <henck@google.com> wrote:
I am more in favor of a set of simple re= quirements, so simple client and server implementation can exist and provid= e the basics of DOH functionality.=C2=A0
Op= tionally, discovery can be used to be more fancy and provide extensibility,= but at the core of it, I would expect that knowing a domain and optionally= an IP (to avoid the chicken and egg issue of being able to resolve the DOH= server IP ) should be enough to be able to access DNS over HTTPS using GET= at a well known endpoint.

I = may be misunderstanding, but doesn't this imply either a fixed path, or= a discoverable path via another (e.g. .well-known/dns)?=C2=A0
<= /blockquote>

Yes, I mean to have a fixed well-known path= that provides DOH service (as in actual DNS queries) that can be used univ= ersally. So, any clients, given a domain, can use DOH without having to go = through the steps of service discovery indirections.
What I under= stood from you original comment was to use this as an entry point to discov= er alternate locations, delegation... I think it is worth it but should be = optional.

At the end of the day, either accessing a disco= very endpoint or DOH service endpoint, the client will need to be told wher= e to get it. Having a predefined entry point would make this easier.
<= div>=C2=A0


On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Ro= ry <rhewitt@akam= ai.com> wrote:
Additionally, using /.well-known/ would allow for URI Template disco= very, if required - client retrieves URI Template from e.g. /.well-known/do= h.template and then uses that to build DNS request URI.

=C2=A0

See https://github.com/dohwg/draft-ietf-doh-dns-over= -https/issues/74 for @mn= ot's suggestion.

= =C2=A0

Thanks,

=C2=A0

Rory

=C2=A0

Rory Hewitt=

Senior= Solutions Architect

= Global Services & Support

Akamai Technologies

Tel: (408) 650-0035

=C2=A0

From: Justin Henck [mailto:henck@google.com]
Sent:= Thursday, February 8, 2018 11:17 AM
To: ek@google.com
Cc: Ben Schwartz <= ;bemasc@google.com>; doh@ietf.org;= mbishop@evequefo= u.be
Subject: Re: [Doh] Seeking input on draft-03

=C2=A0

That would work for the situation I specified, but I think that a .we= ll-known pointer provides the additional benefit of serving more technical = users with an advanced configuration. (It is also in-line with the intended= use of .well-known as I understand RFC 5785.)

=C2=A0

= Specifically, if an implementer creates an advanced setting whereby you can= configure a DOH server with both a domain and an IP (to eliminate the need= for bootstrapping) then you have made the user's life easier. And, alt= hough a URI is not supposed to change, a .well-known/dns pointer requiremen= t would ensure that capricious servers don't break manually-configured = clients.


=C2=A0

<= td style=3D"padding:0in 0in 0in 0in">

Justin Henck=C2=A0
Product Manager=C2=A0

212-565-9811= =C2=A0

google.com/jigsaw

=C2=A0

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 86= 9A 117B

<= /div>

=C2=A0

On Thu,= Feb 8, 2018 at 1:59 PM Erik Kline <ek@google.com> wrote:

Sounds l= ike you might want a (TXT) record at the zone cut level?

On 8 Februa= ry 2018 at 10:55, Justin Henck <henck@google.com> wrote:
> I would like to see a= way for clients to discover a DNS server hosted on a
> certain domai= n.=C2=A0 Perhaps a .well-known/dns path that contains a relative
> po= inter and other metadata.=C2=A0 I'm imagining a use case whereby the us= er could
> choose to rely upon an organization that they find trustwo= rthy which is
> offering DNS, without needing to do a significant amo= unt of discovery (e.g.
> "maybe known.tld has a DNS server?"= ;).=C2=A0 You could of course also have an
> absolute pointer, but th= en you have to account for the situation whereby
> known.tld might de= legate to unknown.tld.
>
> Justin Henck
> Google
><= br>>
> On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <bemasc@google.com> wrote= :
>>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <<= a href=3D"mailto:mbishop@evequefou.be" target=3D"_blank">mbishop@evequefou.= be> wrote:
>>>
>>> I=E2=80=99m inclined to t= hink this is a positive change.=C2=A0 We=E2=80=99re trying to do
>>= ;> something better than the current world of =E2=80=9Ctrust the local D= NS server
>>> because unauthenticated DHCP says so=E2=80=9D, an= d promiscuous trust just because a
>>> server claims it support= DOH via a .well-known endpoint isn=E2=80=99t really any
>>> be= tter.
>>
>>
>> To be clear, the draft never prop= osed promiscuous trust, which would
>> indeed be highly problemati= c.=C2=A0 However, draft-03 does include additional
>> language cla= rifying this point.
>>
>>>
>>> The client = should know the hostname(s) of the DOH server(s) it wants to
>>>= ; use
>>
>>
>> In draft-03, "knowing the ho= stname" is not sufficient, because there is no
>> default pat= h for DOH.=C2=A0 This is the change on which I am seeking input.
>>= ;
>>>
>>> , and it should authenticate the DOH serv= er against that hostname.
>>
>>
>> Yes, definite= ly.=C2=A0 (I believe the draft is clear on this point, but feel
>>= free to suggest improvements.)
>>
>>>
>>>= =C2=A0 =C2=A0If a server hosts content and also wants to also serve DOH, th= ere are
>>> ways to present a hostname that covers both names (= or present two
>>> certificates) on an HTTP connection.
>= >>
>>>
>>>
>>> From: Doh [mailto:= doh-bounces@ietf.= org] On Behalf Of Ben Schwartz
>>> Sent: Thursday, February= 8, 2018 10:05 AM
>>> To: doh@ietf.org
>>> Subject: [Doh] Seeking input = on draft-03
>>>
>>>
>>>
>>>= Hi all,
>>>
>>>
>>>
>>> Th= e authors of draft-ietf-doh-dns-over-https have been making good
>>= ;> progress, and a draft-03 is now ready with several changes and
>= ;>> clarifications.
>>>
>>>
>>>>>> One important difference is that draft-03 no longer proposes= a
>>> ".well-known" entry.=C2=A0 In draft-02 and pri= or, clients could check for the
>>> presence of a DOH service a= t the default path, given only the domain name of
>>> a server.= =C2=A0 In draft-03, there is no default path, so clients must be
>>= ;> configured with the full URL of the DOH endpoint.
>>>
= >>>
>>>
>>> Is this change compatible with= your use cases?=C2=A0 Would this alter the way
>>> users inter= act with your systems?=C2=A0 How do you think DOH client configuration
&= gt;>> should work?
>>>
>>>
>>>>>> Please respond with your thoughts,
>>>
>>= ;> Ben Schwartz
>>
>>
>> ____________________= ___________________________
>> Doh mailing list
>> Doh@ietf.org
>> https://www.ietf.org/mailman/listinfo/doh<= br>>
>
> _______________________________________________
= > Doh mailing list
> Doh@ietf.org
> https://www.iet= f.org/mailman/listinfo/doh
>

=

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--94eb2c0b8cd8af42490564bb4e4d-- From nobody Fri Feb 9 01:24:11 2018 Return-Path: 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 05A2A12422F for ; Fri, 9 Feb 2018 01:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 S9snsGfteiEF for ; Fri, 9 Feb 2018 01:23:59 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D503D12420B for ; Fri, 9 Feb 2018 01:23:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 378EABE4D; Fri, 9 Feb 2018 09:23:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h9n2E65AjbT; Fri, 9 Feb 2018 09:23:54 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55E7CBE49; Fri, 9 Feb 2018 09:23:54 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1518168234; bh=vAKdT7mer22fn6W4AaESwSo6Xcytpd2DwGhAYXma7MM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M01zAhEd4ylSFmtpEIZGC6WiRwxTTt3RtKyljugKjVN9UPZEaHSCf92liaL90icAP dHlFLSL9Dn4auOJyfD+/6oSuO99OvY1H6lVxbpHVW1+adFMneO7RNUvYEREDXHnVQy FJEoda+kUXT/i9Ms6+/YBoCS4mI0Sdm6uFKNEwoc= To: Patrick McManus Cc: Ben Schwartz , doh@ietf.org References: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <7f5075cc-60c3-adb1-54b1-dccb8ba13240@cs.tcd.ie> Date: Fri, 9 Feb 2018 09:23:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3zP56FoX6pmdaVUyaUUZEUkvvhxW6joUp" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 09:24:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3zP56FoX6pmdaVUyaUUZEUkvvhxW6joUp Content-Type: multipart/mixed; boundary="FyMqVj0DcKIfHmyLPz5pl9GOMARVsRDXv"; protected-headers="v1" From: Stephen Farrell To: Patrick McManus Cc: Ben Schwartz , doh@ietf.org Message-ID: <7f5075cc-60c3-adb1-54b1-dccb8ba13240@cs.tcd.ie> Subject: Re: [Doh] Seeking input on draft-03 References: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> In-Reply-To: --FyMqVj0DcKIfHmyLPz5pl9GOMARVsRDXv Content-Type: multipart/mixed; boundary="------------F335288ECAAF0DFD225DAFAF" Content-Language: en-GB This is a multi-part message in MIME format. --------------F335288ECAAF0DFD225DAFAF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Patrick, On 08/02/18 20:24, Patrick McManus wrote: > WRT the removal of .wk: >=20 > * its previous presence had never been meant as a discovery mechanism o= f > the form "I know a hostname, therefore I know the URL". origin is a > security primitive for http, but its not an addressing primitive for ht= tp > services such as a DoH endpoint.. indeed the DoH server might sensibly = wish > to offer multiple URIs on the same host (in the same way some free dns Fair point. > providers make a variety of resolution policies available with differen= t IP > addresses). The configuration primitive for a DoH server is the URI - = not > origin. >=20 > * I had originally included .wk as a bit of future proofing for a use c= ase > not part of the DoH charter (not to enable it, but being sure not to > preclude it at a later time). I have been convinced that .wk is not > necessary for that - and so it was removed from the draft. I regret tha= t > these two things were confused by readers of <=3D -02 due to my own > composition skills (or lack thereof). >=20 > As to Stephen's query - this was both discussed f2f in singapore and > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/24 . Of I read that and it's overall convincing enough for me. I do also wonder about the point raised there about doing surveys of doh deployments - as one poster (willscott) said though, I'm not sure if I think enabling that is a good thing or not. (The downside being that censors discover deployments too.) I'd not argue that's reason enough to retain well-known in the draft. Cheers, S. > course there hasn't been consensus declared on the issue - the editors = are > just trying to make the newer drafts as closely aligned with the group'= s > discussion as we can manage as part of the proces> -P >=20 >=20 > On Thu, Feb 8, 2018 at 2:56 PM, Stephen Farrell > wrote: >=20 >> >> >> On 08/02/18 18:05, Ben Schwartz wrote: >>> >>> One important difference is that draft-03 no longer proposes a >>> ".well-known" entry. In draft-02 and prior, clients could check for = the >>> presence of a DOH service at the default path, given only the domain = name >>> of a server. In draft-03, there is no default path, so clients must = be >>> configured with the full URL of the DOH endpoint. >> >> Apologies if I'm forgetting a thread where this was discussed, >> but what's the reason for dropping .well-known? (If there is a >> thread, a pointer to that is a sufficient answer.) >> >> Thanks, >> S. >> >> -- >> PGP key change time for me. >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >> NewWithOld sigs in keyservers. >> Sorry if that mucks something up;-) >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> >> >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------F335288ECAAF0DFD225DAFAF Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------F335288ECAAF0DFD225DAFAF-- --FyMqVj0DcKIfHmyLPz5pl9GOMARVsRDXv-- --3zP56FoX6pmdaVUyaUUZEUkvvhxW6joUp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJafWipAAoJEFqy+vF7Fyvq0x4QAMrLc6nVkCHVTspvDeeNrzmO Cld0ERkEmBfZ9HHNgGnFq8040wGoui6w8d5h+81MUJY/dFypEMElmtIxu0J3v/+w t8xXwaWrnPv3jdQeF2KX9x1wcIzQ2t5e5ElzE3vKn7niuirmo7iORjFqjUI0oSMS AxWvxquTv2wykNuXQg8Sx0TxHD4ii7l1Wck9StuDi3Ux3mTt4szv21O9u1EZW/Am nGyCe6et3OzxqHIGTsVC2k1IiTJWg4+ZQ94MTP2Sz77Y6KlzmOwNK+PAC5oN8AR/ 2/hNSkSWOaGIle3hpTZr8o9zVIj0vmpnrdfpNjYQ9304JBVlIH/d6gXUTVaavwNd iy4pIXwlGvTZkaAQESohv3buRZ6OCFDYh/ZXNaEK4fizBDAWGcwUrVnpNJqYtxfj nHsa+lAp/18tZM4jzUNonPBpMvGinX9+iI0paFzsRfnZ0Sr8218wSE7m8kV30qEC msTz0DaplwC7ZuyNxLEI6b/UK4arbTZjSemITRqwZdCQ916gxkNgF7rlzfRoymb3 rwNlCuC019SSYMRucro8yP5n1lzRxFThPZEl3JghXvgVcvCsJnny+129To4LfnV2 o+EHLymRhKnYiCVKZfRo/+Ds1jf0WgWqyoFFaNDRAvEcuncbhe4H1TaTyVNcXipY y0vT2pwrJqzbElVDqrx9 =u4uA -----END PGP SIGNATURE----- --3zP56FoX6pmdaVUyaUUZEUkvvhxW6joUp-- From nobody Fri Feb 9 07:04:31 2018 Return-Path: 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 351CA129C5D for ; Fri, 9 Feb 2018 07:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PRDYaTgzBKso for ; Fri, 9 Feb 2018 07:04:27 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D28A124205 for ; Fri, 9 Feb 2018 07:04:27 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id 196so10971610iti.5 for ; Fri, 09 Feb 2018 07:04:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=spL7C07Y+asFgrYB4zvzRunrZMk1mmZ9zF/aSx2i2NM=; b=u2sTTj5H73jii+ZIH12wKrjwbsdH+Bt/m307+kqFNQjjXi02MHgL0O4FVjDrIvq7a+ QIPL3jl1ggcIo6cU3dStIT4Glu+OxEX5VvtEYUI8j9D+yxYVfOiNTfr6GySKVbeCsLPT YPmZtAD+kpAP23gMVyhGCk8aHurOKuPvetlQDrY8YzcwvBTl9FNdcJ608sMNYQrBmxHB rjUomlKCecjDSVWoGDw8AV4RRASTJN1a+8PvJOZbz1Q2vICGMYopOV8dV/mUu9lf0Sgq hVq8X4VndaOma2PVIsSXra3d0dJkSvYX49RyvI0ZnPYD0BDGYbTbwNKzGgK/ylf270VI sjcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=spL7C07Y+asFgrYB4zvzRunrZMk1mmZ9zF/aSx2i2NM=; b=GxceU1+NG3xT08ZBQIyrsfCC0PjoZcOkIwdzRng1ndaevgog9xZPxRf/D02HT7tTej UM3VB4zXdXmaWPdD2DBSCoexV1mUHCzC6sBpMNS6XA8SMbPfS/zZ2DRKbCgwTnwj6gRa UocYgK9TuxbdtajPVucjZH2rAa6ZlynR4prwN4jboAF4ZC4HPE9Tz/AcEhi4mbOYDpqP n+5oyFjj/AFUWiY72WpEz7wQWvtMBv694NQLNlBmu/ypDJSwfn+/IANWaOaehRK2EP1D hr+SmkZ2Xc5IyrLEUAqjzrPURPRck4RD1b6gy0DgsWoJk4MGpPtSiBUOEMOsVP5CZrbp Qf9Q== X-Gm-Message-State: APf1xPC990wM4w8KC6+k42RoXo/vTjfaK9BfAOsZCVKH316W/ehhmXta x2L6bdUAXdNjOKc80tW/nAgWZMuldBIorcWxV+GAGQ== X-Google-Smtp-Source: AH8x227uvB4JNbpfGPjMXp744HdN29pHzyzEJeIccSRTGlQzKN9YTxrpyXgs4sIqi2/cw8BAAXAVSQMWE02MCvCeKfs= X-Received: by 10.36.221.18 with SMTP id t18mr3947923itf.106.1518188666158; Fri, 09 Feb 2018 07:04:26 -0800 (PST) MIME-Version: 1.0 References: <5855fc09-0518-7fb0-56b6-07a8667cbf31@cs.tcd.ie> <7f5075cc-60c3-adb1-54b1-dccb8ba13240@cs.tcd.ie> In-Reply-To: <7f5075cc-60c3-adb1-54b1-dccb8ba13240@cs.tcd.ie> From: Justin Henck Date: Fri, 09 Feb 2018 15:04:14 +0000 Message-ID: To: stephen.farrell@cs.tcd.ie Cc: pmcmanus@mozilla.com, Ben Schwartz , doh@ietf.org Content-Type: multipart/alternative; boundary="001a1144e30a26a0100564c8d845" Archived-At: Subject: Re: [Doh] Seeking input on draft-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 15:04:30 -0000 --001a1144e30a26a0100564c8d845 Content-Type: text/plain; charset="UTF-8" I can still see a lot of use cases for allowing discovery with just the origin, and think it's an important feature to allow both performance enhancements and drive user adoption: - Without the need for additional standards, a client on an HTTP/2 connection could discover a DNS resolver on that origin and use it for all queries related to content on that origin - If the certificate frame is adopted, a client could make DNS queries to all open connections, to see if they host an origin (preventing round-robin DNS from messing up multiplexing) - People can configure a bootstrapping-free DNS server with fewer variables (IP + origin) - People can survey DNS servers, even if the dns endpoint itself is access-restricted. This would allow us to track adoption, and though it could be used to block servers it could also be used to find ones returning non-canonical results. It may be that .well-known/dns metadata would solve many of these purposes by being optional, or by only being required to point to at least one instance; that would account for the desire to host multiple resolvers. On Fri, Feb 9, 2018 at 4:24 AM Stephen Farrell wrote: > > Thanks Patrick, > > On 08/02/18 20:24, Patrick McManus wrote: > > WRT the removal of .wk: > > > > * its previous presence had never been meant as a discovery mechanism of > > the form "I know a hostname, therefore I know the URL". origin is a > > security primitive for http, but its not an addressing primitive for http > > services such as a DoH endpoint.. indeed the DoH server might sensibly > wish > > to offer multiple URIs on the same host (in the same way some free dns > > Fair point. > > > providers make a variety of resolution policies available with different > IP > > addresses). The configuration primitive for a DoH server is the URI - > not > > origin. > > > > * I had originally included .wk as a bit of future proofing for a use > case > > not part of the DoH charter (not to enable it, but being sure not to > > preclude it at a later time). I have been convinced that .wk is not > > necessary for that - and so it was removed from the draft. I regret that > > these two things were confused by readers of <= -02 due to my own > > composition skills (or lack thereof). > > > > As to Stephen's query - this was both discussed f2f in singapore and > > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/24 . Of > > I read that and it's overall convincing enough for me. > > I do also wonder about the point raised there about doing surveys of > doh deployments - as one poster (willscott) said though, I'm not sure > if I think enabling that is a good thing or not. (The downside being > that censors discover deployments too.) I'd not argue that's reason > enough to retain well-known in the draft. > > Cheers, > S. > > > course there hasn't been consensus declared on the issue - the editors > are > > just trying to make the newer drafts as closely aligned with the group's > > discussion as we can manage as part of the proces> -P > > > > > > On Thu, Feb 8, 2018 at 2:56 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> > >> On 08/02/18 18:05, Ben Schwartz wrote: > >>> > >>> One important difference is that draft-03 no longer proposes a > >>> ".well-known" entry. In draft-02 and prior, clients could check for > the > >>> presence of a DOH service at the default path, given only the domain > name > >>> of a server. In draft-03, there is no default path, so clients must be > >>> configured with the full URL of the DOH endpoint. > >> > >> Apologies if I'm forgetting a thread where this was discussed, > >> but what's the reason for dropping .well-known? (If there is a > >> thread, a pointer to that is a sufficient answer.) > >> > >> Thanks, > >> S. > >> > >> -- > >> PGP key change time for me. > >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > >> NewWithOld sigs in keyservers. > >> Sorry if that mucks something up;-) > >> > >> _______________________________________________ > >> Doh mailing list > >> Doh@ietf.org > >> https://www.ietf.org/mailman/listinfo/doh > >> > >> > > > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a1144e30a26a0100564c8d845 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can still see a lot of use cases for allowing discovery = with just the origin, and think it's an important feature to allow both= performance enhancements and drive user adoption:
  • Without the = need for additional=C2=A0standards, a client on an HTTP/2 connection could = discover a DNS resolver on that origin and use it for all queries related t= o content on that origin
  • If the certificate frame is adopted, a cli= ent could make DNS queries to all open connections, to see if they host an = origin (preventing round-robin DNS from messing up multiplexing)
  • Pe= ople can configure a bootstrapping-free DNS server with fewer variables (IP= + origin)
  • People can survey DNS servers, even if the dns endpoint = itself is access-restricted. This would allow us to track adoption, and tho= ugh it could be used to block servers it could also be used to find ones re= turning non-canonical results.
It may be that .well-known/dns= metadata would solve many of these purposes by being optional, or by only = being required to point to at least one instance; that would account for th= e desire to host multiple resolvers.

On Fri, Feb 9, 2018 at 4:24 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:

Thanks Patrick,

On 08/02/18 20:24, Patrick McManus wrote:
> WRT the removal of .wk:
>
> * its previous presence had never been meant as a discovery mechanism = of
> the form "I know a hostname, therefore I know the URL". orig= in is a
> security primitive for http, but its not an addressing primitive for h= ttp
> services such as a DoH endpoint.. indeed the DoH server might sensibly= wish
> to offer multiple URIs on the same host (in the same way some free dns=

Fair point.

> providers make a variety of resolution policies available with differe= nt IP
> addresses).=C2=A0 The configuration primitive for a DoH server is the = URI - not
> origin.
>
> * I had originally included .wk as a bit of future proofing for a use = case
> not part of the DoH charter (not to enable it, but being sure not to > preclude it at a later time). I have been convinced that .wk is not > necessary for that - and so it was removed from the draft. I regret th= at
> these two things were confused by readers of <=3D -02 due to my own=
> composition skills (or lack thereof).
>
> As to Stephen's query - this was both discussed f2f in singapore a= nd
> https://github.com/dohwg/draft-= ietf-doh-dns-over-https/issues/24 . Of

I read that and it's overall convincing enough for me.

I do also wonder about the point raised there about doing surveys of
doh deployments - as one poster (willscott) said though, I'm not sure if I think enabling that is a good thing or not. (The downside being
that censors discover deployments too.) I'd not argue that's reason=
enough to retain well-known in the draft.

Cheers,
S.

> course there hasn't been consensus declared on the issue - the edi= tors are
> just trying to make the newer drafts as closely aligned with the group= 's
> discussion as we can manage as part of the proces> -P
>
>
> On Thu, Feb 8, 2018 at 2:56 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie&= gt;
> wrote:
>
>>
>>
>> On 08/02/18 18:05, Ben Schwartz wrote:
>>>
>>> One important difference is that draft-03 no longer proposes a=
>>> ".well-known" entry.=C2=A0 In draft-02 and prior, cl= ients could check for the
>>> presence of a DOH service at the default path, given only the = domain name
>>> of a server.=C2=A0 In draft-03, there is no default path, so c= lients must be
>>> configured with the full URL of the DOH endpoint.
>>
>> Apologies if I'm forgetting a thread where this was discussed,=
>> but what's the reason for dropping .well-known? (If there is a=
>> thread, a pointer to that is a sufficient answer.)
>>
>> Thanks,
>> S.
>>
>> --
>> PGP key change time for me.
>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
>> NewWithOld sigs in keyservers.
>> Sorry if that mucks something up;-)
>>
>> _______________________________________________
>> Doh mailing list
>> Doh@ietf.org=
>> https://www.ietf.org/mailman/listinfo/doh
>>
>>
>

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--001a1144e30a26a0100564c8d845-- From nobody Fri Feb 9 14:12:02 2018 Return-Path: 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 E9E54126D3F; Fri, 9 Feb 2018 14:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Xbu1J-P7tP5j; Fri, 9 Feb 2018 14:11:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D0D1270FC; Fri, 9 Feb 2018 14:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2998; q=dns/txt; s=iport; t=1518214309; x=1519423909; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mPnNDbqQGTBp5Rgak10YSqvyVMVwH6NoFOwTCdqQWK4=; b=QvfPOnFYpkasFDm6MeFZykfkL8gHbhk16Rbfm34DAd8Tr3JkSDJgECZI t7nY6W61/SRHh8RGM4dccAkOnZmNyMXwIhnmo6tX8Hys9xxk/NJ/NFk5o kvoMFo+NSI9KaEQunGGMsm81ZmjkE25wS8TVovSq3DrLUAZNTyl4zChu5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DzAAATHH5a/4gNJK1eARgBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDUmZwKAqDW4okjiSZWYIYChgNhRYCGoIgVBgBAgEBAQEBAQJ?= =?us-ascii?q?rHQuFJAIEAQEhEToLEAIBCBoCJgICAiULFRACBA4FijUQrweCJ4UBg3WCDQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2BD4NtghWBV4IRgwWDLwEBAgEBF4FWgxcxgjQ?= =?us-ascii?q?FkkyRYAkCiB2NYoIeZ4VBi3mOAIlmAhEZAYE7AR85gVBwFRkkKgGCGwmEbQF4i?= =?us-ascii?q?1qBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,485,1511827200"; d="scan'208";a="343781528" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2018 22:11:49 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w19MBnlI020678 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Feb 2018 22:11:49 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 9 Feb 2018 16:11:48 -0600 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1320.000; Fri, 9 Feb 2018 16:11:48 -0600 From: "Jan Komissar (jkomissa)" To: "dnsop@ietf.org" CC: "dnssd@ietf.org" , "doh@ietf.org" Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-05.txt Thread-Index: AQHTlzNpJxjKaNAGUEaGwSQBUMUP1KOcyE8A Date: Fri, 9 Feb 2018 22:11:48 +0000 Message-ID: <2637A488-46BB-4AA1-8BE6-281DA594A5CC@cisco.com> References: <151703250881.23521.17253380316887973737@ietfa.amsl.com> In-Reply-To: <151703250881.23521.17253380316887973737@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.252.146] Content-Type: text/plain; charset="utf-8" Content-ID: <48D9772AC1BB9342A8A4C59989ED325C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-05.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 22:11:52 -0000 SSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGl0IGxvb2tzIGZpbmUgdG8gbWUuDQoNCisx DQoNCkphbiBLb21pc3Nhcg0KDQpPbiAxLzI3LzE4LCAxMjo1NSBBTSwgIkROU09QIG9uIGJlaGFs ZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxkbnNvcC1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgDQogICAg QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KICAgIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIERvbWFpbiBOYW1lIFN5c3RlbSBPcGVyYXRpb25zIFdHIG9mIHRoZSBJRVRGLg0KICAgIA0K ICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogRE5TIFN0YXRlZnVsIE9wZXJhdGlvbnMNCiAg ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJheSBCZWxsaXMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFN0dWFydCBDaGVzaGlyZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgSm9obiBEaWNraW5zb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNhcmEgRGlj a2luc29uDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbGxpc29uIE1hbmtpbg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgVG9tIFB1c2F0ZXJpDQogICAgCUZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWlldGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwtMDUudHh0DQogICAgCVBhZ2Vz ICAgICAgICAgICA6IDUwDQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTgtMDEtMjYNCiAgICAN CiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgRE5TIE9Q Q09ERSBmb3IgRE5TIFN0YXRlZnVsIE9wZXJhdGlvbnMNCiAgICAgICAoRFNPKS4gIERTTyBtZXNz YWdlcyBjb21tdW5pY2F0ZSBvcGVyYXRpb25zIHdpdGhpbiBwZXJzaXN0ZW50DQogICAgICAgc3Rh dGVmdWwgc2Vzc2lvbnMsIHVzaW5nIHR5cGUtbGVuZ3RoLXZhbHVlIChUTFYpIHN5bnRheC4gIFRo cmVlIFRMVnMNCiAgICAgICBhcmUgZGVmaW5lZCB0aGF0IG1hbmFnZSBzZXNzaW9uIHRpbWVvdXRz LCB0ZXJtaW5hdGlvbiwgYW5kIGVuY3J5cHRpb24NCiAgICAgICBwYWRkaW5nLCBhbmQgYSBmcmFt ZXdvcmsgaXMgZGVmaW5lZCBmb3IgZXh0ZW5zaW9ucyB0byBlbmFibGUgbmV3DQogICAgICAgc3Rh dGVmdWwgb3BlcmF0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCiAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRuc29wLXNlc3Npb24tc2lnbmFsLw0KICAgIA0KICAgIFRo ZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbC0wNQ0K ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kbnNv cC1zZXNzaW9uLXNpZ25hbC0wNQ0KICAgIA0KICAgIEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2 ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtaWV0Zi1kbnNvcC1zZXNzaW9uLXNpZ25hbC0wNQ0KICAgIA0KICAgIA0KICAg IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgRE5TT1AgbWFpbGluZyBsaXN0 DQogICAgRE5TT1BAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Ruc29wDQogICAgDQoNCg== From nobody Mon Feb 12 16:15:54 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1FA12DA0C; Mon, 12 Feb 2018 16:15:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lflynn@amsl.com, doh@ietf.org, adam@nostrum.com, doh-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151848095315.22226.17793672516150709116.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 16:15:53 -0800 Archived-At: Subject: [Doh] doh - Update to a Meeting Session Request for IETF 101 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 00:15:53 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the doh working group. --------------------------------------------------------- Working Group Name: DNS Over HTTPS Area Name: Applications and Real-Time Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: dnsop dnssd dprive httpbis Second Priority: capport quic v6ops hrpc homenet People who must be present: Paul E. Hoffman Adam Roach Patrick McManus Benjamin M. Schwartz David C Lawrence Resources Requested: Special Requests: I think 45 minutes is probably enough. --------------------------------------------------------- From nobody Wed Feb 14 14:12:39 2018 Return-Path: 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 CEDCE1201FA; Wed, 14 Feb 2018 14:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mThmdqFvivG2; Wed, 14 Feb 2018 14:12:30 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A681812426E; Wed, 14 Feb 2018 14:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3662; q=dns/txt; s=iport; t=1518646350; x=1519855950; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t66nqsmZK2Y/v6sKPnCM+pQcWyQOXDJbxmLknPgZ20s=; b=WozJXNxe20tOjduI43WH8ahUF7Q8WQvHLGnEX5j7i83+THY6rd1Utda5 EjI67Cm8NY1ynCS8YVf9A1z3D2nWDbYR3NbpngCTgHf+OORyvGYuTbkJ0 2qQtHSeZbFpsWaHiIUKab5SArBDoXojqa2hySRJgtAK7SPVvbRR5h0ZAX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAwDns4Ra/5hdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCoNbmCiBW4E+lkKCGAoYC4UYAhqCY1YWAQIBAQEBAQE?= =?us-ascii?q?CayiFJAIEAQEhEToLEAIBCBoCJgICAiULFRACBAENBYo1EK98gieFAYQDghMBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg3OCFYFXgWgpDIJ5gy8BAYFxgxcxgjQ?= =?us-ascii?q?BBKQvCQKMJoldlEWXbAIRGQGBOwEmBS2BUHAVPSoBghuEd3iMaQGBGAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,514,1511827200"; d="scan'208";a="70408039" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 22:12:29 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1EMCTrt004967 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2018 22:12:29 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 16:12:29 -0600 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1320.000; Wed, 14 Feb 2018 16:12:29 -0600 From: "Jan Komissar (jkomissa)" To: Paul Hoffman , dnsop CC: "dnssd@ietf.org" , "doh@ietf.org" Thread-Topic: [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal Thread-Index: AQHTm5D+P8Hdt54fVUSceurV+Y+5IKOSDxkAgBKMVQA= Date: Wed, 14 Feb 2018 22:12:29 +0000 Message-ID: <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> In-Reply-To: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.67.103] Content-Type: text/plain; charset="utf-8" Content-ID: <3418F09B43B37245AD8991243B55ABFB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:12:33 -0000 DQpUd28gaXRlbXMgcmVsYXRlZCB0byB0aGlzOg0KDQoxOiBJIHRoaW5rIHRoYXQgaXQgd291bGQg YmUgYmV0dGVyIHRvIHJlcXVpcmUgVExTIGZvciBhbGwgRFNPIGNvbm5lY3Rpb25zLiBUaGlzIGRv Y3VtZW50IChEU08pIHNwZWNpZmllcyB0aGF0IGl0IHNob3VsZCB1c2UgVENQIG9yIFRMUyBmb3Ig Y29ubmVjdGlvbnMsIGJ1dCB0aGUgRE5TIFB1c2ggTm90aWZpY2F0aW9uIChEUE4pIGRyYWZ0IHJl cXVpcmVzIFRMUy4gVGhpcyB3b3VsZCBjb21wbGljYXRlIG1hdHRlcnMgaWYgYSBzdGFuZGFyZCBU Q1AgY29ubmVjdGlvbiB3YXMgb3BlbmVkIGZvciBvbmUgcHVycG9zZSBhbmQgbGF0ZXIgYSBEUE4g b3BlcmF0aW9uIG92ZXIgdGhlIHNhbWUgY29ubmVjdGlvbiB3YXMgYXR0ZW1wdGVkLiBBbHNvLCBp dCBpbXByb3ZlcyBzZWN1cml0eSBmb3IgYWxsIERTTyBvcGVyYXRpb25zLg0KDQoyOiBJIGFsc28g YmVsaWV2ZSB0aGlzIGRvY3VtZW50IHNob3VsZCBvbmx5IHN1cHBvcnQgRFNPIG92ZXIgVExTLCBu b3Qgc2Vzc2lvbiBiYXNlZCBwcm90b2NvbHMgaW4gZ2VuZXJhbC4gSWYgdGhlcmUgaXMgYSBuZWVk L2Rlc2lyZSBmb3IgZG9pbmcgRFNPIG92ZXIgb3RoZXIgcHJvdG9jb2xzLCBhIG5ldyBSRkMgYWxs b3dpbmcgZWFjaCBwcm90b2NvbCB3b3VsZCBiZSByZXF1aXJlZC4gVGhpcyByZXF1aXJlbWVudCB3 aWxsIGVuc3VyZSB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhpcyBkcmFmdCB3b3VsZCBp bnRlcm9wZXJhdGUuIChJZiBEU08tb3Zlci1YIGFuZCBEU08tb3Zlci1ZIGJvdGggYXJlIGNvbXBs aWFudCB3aXRoIHRoaXMgZG9jdW1lbnQsIHRoZXkgYXJlIG5vdCBsaWtlbHkgdG8gaW50ZXJvcGVy YXRlIGV2ZW4gaWYgYm90aCBYIGFuZCBZIGFyZSBzZXNzaW9uIGJhc2VkLCB3aGljaCB3b3VsZCBk ZWZlYXQgdGhlIHB1cnBvc2Ugb2YgYSBzdGFuZGFyZC4pDQoNClJlZ2FyZHMsDQoNCkphbi4NCg0K T24gMi8yLzE4LCA0OjU4IFBNLCAiRE5TT1Agb24gYmVoYWxmIG9mIFBhdWwgSG9mZm1hbiIgPGRu c29wLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHBhdWwuaG9mZm1hbkB2cG5jLm9yZz4g d3JvdGU6DQoNCiAgICBUaGUgY3VycmVudCBkcmFmdCBpcyBoYW5kLXdhdnkgd2hlbiBpdCBjb21l cyB0byB3aGljaCB0cmFuc3BvcnRzIERTTyBjYW4gDQogICAgcnVuIG9uLg0KICAgIA0KICAgIFNl Y3Rpb24gMiBzYXlzICJzdWNoIGFzIjoNCiAgICAgICAgVGhlIHRlcm0gImNvbm5lY3Rpb24iIG1l YW5zIGEgYmlkaXJlY3Rpb25hbCBieXRlIHN0cmVhbSBvZiByZWxpYWJsZSwNCiAgICAgICAgaW4t b3JkZXIgbWVzc2FnZXMsIHN1Y2ggYXMgcHJvdmlkZWQgYnkgdXNpbmcgRE5TIG92ZXIgVENQDQog ICAgICAgIFtSRkMxMDM1XVtSRkM3NzY2XSBvciBETlMgb3ZlciBUTFMgW1JGQzc4NThdLg0KICAg IFNlY3Rpb24gNC4xIHNheXMgImFyZSBzdWl0YWJsZSI6DQogICAgICAgIFN0YW5kYXJkIEROUyBv dmVyIFRDUCBbUkZDMTAzNV1bUkZDNzc2Nl0sIGFuZCBETlMgb3ZlciBUTFMgW1JGQzc4NThdDQog ICAgICAgIGFyZSBzdWl0YWJsZSBwcm90b2NvbHMuDQogICAgDQogICAgVGhlIGRvY3VtZW50IHNo b3VsZCBleHBsaWNpdGx5IGxpc3Qgd2hpY2ggcHJvdG9jb2xzIGFyZSBjdXJyZW50bHkgDQogICAg YWNjZXB0YWJsZSwgYW5kIHNheSB0aGF0IHRoZSBsaXN0IGNhbiBjaGFuZ2UgaW4gdGhlIGZ1dHVy ZSBiYXNlZCBvbiANCiAgICBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnRzLiBQcm9wb3NlZCB3b3Jk aW5nIGZvciBib3RoIG9mIHRoZXNlIGFib3ZlIGFyZToNCiAgICANCiAgICBTZWN0aW9uIDI6DQog ICAgICAgIFRoZSB0ZXJtICJjb25uZWN0aW9uIiBtZWFucyBhIGJpZGlyZWN0aW9uYWwgYnl0ZSBz dHJlYW0gb2YgcmVsaWFibGUsDQogICAgICAgIGluLW9yZGVyIG1lc3NhZ2VzLg0KICAgIFNlY3Rp b24gNC4xIHNheXMgImFyZSBzdWl0YWJsZSI6DQogICAgICAgIERTTyBNVVNUIGJlIHJ1biBhcyBz dGFuZGFyZCBETlMgb3ZlciBUQ1AgW1JGQzEwMzVdW1JGQzc3NjZdDQogICAgICAgIG9yIEROUyBv dmVyIFRMUyBbUkZDNzg1OF0uIFRoaXMgbGlzdCBtaWdodCBleHBhbmQgaW4gdGhlIGZ1dHVyZSwg DQogICAgc3VjaA0KICAgICAgICBhbiBleHBhbnNpb24gTVVTVCBiZSBpbiBzdGFuZGFyZHMtdHJh Y2sgUkZDcy4NCiAgICANCiAgICBIYXZpbmcgZGV2ZWxvcGVycyBrbm93IGV4YWN0bHkgd2hpY2gg cHJvdG9jb2xzIGNhbiBiZSB1c2VkIGlzIGltcG9ydGFudCANCiAgICBzbyB0aGF0IHRoZXkgZG8g bm90IHVzZSBwcm90b2NvbHMgdGhhdCB0aGV5IGFjY2lkZW50YWxseSB0aGluayBhcmUgDQogICAg cmVsaWFibGUgYW5kIGluLW9yZGVyLiBGb3IgZXhhbXBsZSwgdGhlIERPSCBXRyBpcyB3b3JraW5n IG9uIGEgcHJvdG9jb2wgDQogICAgdGhhdCBtaWdodCBpbml0aWFsbHkgc2VlbSBhdHRyYWN0aXZl LCBidXQgaXQgZG9lcyAqbm90KiBxdWFsaWZ5IGZvciBEU08uDQogICAgDQogICAgLS1QYXVsIEhv ZmZtYW4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KICAgIEROU09QIG1haWxpbmcgbGlzdA0KICAgIEROU09QQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNvcA0KICAgIA0KDQo= From nobody Wed Feb 14 14:22:49 2018 Return-Path: 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 69C651201FA for ; Wed, 14 Feb 2018 14:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 9-rcLud9NUq2 for ; Wed, 14 Feb 2018 14:22:43 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764EC126B6E for ; Wed, 14 Feb 2018 14:22:41 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s198so12541902qke.5 for ; Wed, 14 Feb 2018 14:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Va/WnRcXkAVQ7RmBTM2qWR0Jt7LMH1XDRxKLreaKw8Y=; b=ajep751TJKDRT0Wa21TH7que9tRmEDdbR3HOCq3+0Yyi0XIX73MAy+Fa3/nkz6cC9J 4sVY2WfqRo++tgDpVjx46alWa3h6S9hZhZn62m5OOhth22kZzgm3tyOPm0MufvJD6Zkh YwrgnP2QQkTTWU3sfn/wSK/bHju4KwSZiFr1HmPuUdjd1891uLlABbY+pzDKO+FRSHY/ DzNKBeCTJG5+AUQ2kBpl2sTW0KxWF2HAtu0Bbvm5r16Ib8C9QIgvyHYaOIIgb2FJgaY5 XW1s8k15YITSkpSrYEgJB/h5+TFLY5j/WSXiRrD0LKc2suWI+dwl7X//RBYarT/tZp6o Ebxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Va/WnRcXkAVQ7RmBTM2qWR0Jt7LMH1XDRxKLreaKw8Y=; b=EVyHabk6UsDe1+xipkiyqTX3LpH1cEMS30kbwa1UXk7Z4gIuqEF5chDJHP0gZdRlFh x5CEMmAPN2XBRxQrbgsjwhCgHvFGdc4NrulO6+poPqAXxdGxrzitf0+V431ZpON+G3oD wrUz+dPqJivuGpEi0yQ6soj16LbyLKxpD0FLVUh9FQrF9OjQXkoh5u1Dylpb/7BkzfiY nmtsc54uB0mKPaOaTz5RD61lg3XfhmFe2Di8P3haC29x35B6KZ/CrTli1iQ5T6m4pFCj jMiBz7pQ3U36rGhrQO7BVBWdIjxDCY2lYJWDfQmVEKfEQQviMV2d5AT4FdYQC4pLNkE+ lhfw== X-Gm-Message-State: APf1xPATj7gLCggKuoXEPFTLozILveAIHdxJGoHQRbkBeE1dHIZFcul7 z8nsr+FNJaGkykwIIIw4ayJ2JA== X-Google-Smtp-Source: AH8x226x9yEXS91ogH/bJ60toKV6PCc+/yRoVhhGQ6CymFupAzKkFQ+zX2tj/YchSceR8iju/YII+w== X-Received: by 10.55.102.134 with SMTP id a128mr1021837qkc.122.1518646960576; Wed, 14 Feb 2018 14:22:40 -0800 (PST) Received: from [10.0.1.16] ([8.20.190.66]) by smtp.gmail.com with ESMTPSA id g42sm1044260qtb.96.2018.02.14.14.22.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 14:22:40 -0800 (PST) From: Ted Lemon Message-Id: <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7307901A-0BFE-4C86-8B0D-9CEB69592114" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 14 Feb 2018 17:22:38 -0500 In-Reply-To: <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> Cc: Paul Hoffman , dnsop , "dnssd@ietf.org" , "doh@ietf.org" To: "Jan Komissar (jkomissa)" References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 22:22:44 -0000 --Apple-Mail=_7307901A-0BFE-4C86-8B0D-9CEB69592114 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2018, at 5:12 PM, Jan Komissar (jkomissa) = wrote: > 1: I think that it would be better to require TLS for all DSO = connections. This document (DSO) specifies that it should use TCP or TLS = for connections, but the DNS Push Notification (DPN) draft requires TLS. = This would complicate matters if a standard TCP connection was opened = for one purpose and later a DPN operation over the same connection was = attempted. Also, it improves security for all DSO operations. Jan, I'm having trouble following your reasoning here. The client that = makes the connection presumably knows whether or not it's going to do = DPN. Why would there be any confusion? DNS-over-TCP and DNS-over-TLS are standards. It's hard to see where = the interop issue would be. Can you expand on that? Also, do you think that DNS-over-TCP should be formally deprecated? If = so, perhaps that's the right way to address this. If not, can you say = why DSO is special and requires TLS, when DNS-over-TCP does not? --Apple-Mail=_7307901A-0BFE-4C86-8B0D-9CEB69592114 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Feb 14, 2018, at 5:12 PM, Jan Komissar (jkomissa) <jkomissa@cisco.com> = wrote:
1: I think that it = would be better to require TLS for all DSO connections. This document = (DSO) specifies that it should use TCP or TLS for connections, but the = DNS Push Notification (DPN) draft requires TLS. This would complicate = matters if a standard TCP connection was opened for one purpose and = later a DPN operation over the same connection was attempted. Also, it = improves security for all DSO = operations.

Jan, I'm having trouble following your reasoning here.   = The client that makes the connection presumably knows whether or not = it's going to do DPN.   Why would there be any confusion?

DNS-over-TCP and = DNS-over-TLS are standards.   It's hard to see where the interop = issue would be.   Can you expand on that?

Also, do you think that DNS-over-TCP = should be formally deprecated?   If so, perhaps that's the right = way to address this.   If not, can you say why DSO is special and = requires TLS, when DNS-over-TCP does not?

= --Apple-Mail=_7307901A-0BFE-4C86-8B0D-9CEB69592114-- From nobody Wed Feb 14 15:07:06 2018 Return-Path: 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 33CFA12700F; Wed, 14 Feb 2018 15:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 QZoaubZDB1tx; Wed, 14 Feb 2018 15:06:58 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1855512704A; Wed, 14 Feb 2018 15:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11714; q=dns/txt; s=iport; t=1518649618; x=1519859218; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J6G+VX0rxrp4D1kfjqb54u3X5v0S92NI+wVlCYFm2tk=; b=Ij9wm9Zucn5q4UbI7KViwccxpTUoVjyFhTXv0JjJvfor14DuDP+DIrOp ip1uL1n0JJNrN94NDz/OPLvcooY8HZjTsiR7eEUHAHzO+ySbEiBMUX1g+ USFX9ZKYCz46bcC43DJFjIvZ+kCdrhEd9UWOX+lMliKm24Ornr/Qfd9C1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CcAgDVwIRa/4cNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaeGZwKAqDW5goggKBF5BnhVuCGAqFOwIagmNWFgECAQEBAQE?= =?us-ascii?q?BAmsohSMBAQEEI1YQAgEIDgMDAQIoAwICAjAUCQgCBA4FiVFksAaCJyaIYYITA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYUCghWBV4FoKYMFhQw2FoJhMYI0BaQvCQK?= =?us-ascii?q?WA5RFl2wCERkBgTsBJgsngVBwFWcBghuEd3iMaQGBGAEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,514,1511827200"; d="scan'208,217"; a="70392283" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 23:06:43 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1EN6hDl019437 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 14 Feb 2018 23:06:43 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 17:06:42 -0600 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1320.000; Wed, 14 Feb 2018 17:06:42 -0600 From: "Jan Komissar (jkomissa)" To: Ted Lemon CC: Paul Hoffman , dnsop , "dnssd@ietf.org" , "doh@ietf.org" Thread-Topic: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal Thread-Index: AQHTm5D+P8Hdt54fVUSceurV+Y+5IKOSDxkAgBKMVQCAAFapAP//uH4A Date: Wed, 14 Feb 2018 23:06:42 +0000 Message-ID: <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> In-Reply-To: <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.67.103] Content-Type: multipart/alternative; boundary="_000_5AFBBFBECF5A4F7A9AC9F7E0040BBABDciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:07:00 -0000 --_000_5AFBBFBECF5A4F7A9AC9F7E0040BBABDciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KDQpJ4oCZbGwgdHJ5IHRvIGNsYXJpZnk6DQoNCkN1cnJlbnRseSwgdGhlcmUgYXJl IG9ubHkgcGxhbnMgZm9yIERQTiwgYW5kIHRoYXQgd291bGQgZm9yY2UgZXZlcnkgY29ubmVjdGlv biB0byBiZSBUTFMuIEhvd2V2ZXIsIGlmIGEgZnV0dXJlIHByb3RvY29sIOKAnFotb3Zlci1EU0/i gJ0gZG9lcyBub3QgcmVxdWlyZSBUTFMsIGl0IGlzIHBvc3NpYmxlIHRoYXQgYSBjbGllbnQgd291 bGQgY3JlYXRlIGEgVENQIGNvbm5lY3Rpb24gZm9yIFogYW5kIGxhdGVyIHdvdWxkIHdhbnQgdG8g c2VuZCBEUE4gb3BlcmF0aW9uIHRvIHRoZSBzYW1lIHNlcnZlci4gTm90ZSB0aGF0IHRoZSBEU08g Y2xpZW50IG1heSByZXByZXNlbnQgYSBzaW5nbGUgY29tcHV0ZXIsIHdoaWxlIHRoZSBaIGFuZCBE UE4gcmVxdWVzdHMgcmVwcmVzZW50IGFwcGxpY2F0aW9ucyBvbiB0aGF0IGNvbXB1dGVyIHRoYXQg aW1wbGljaXRseSBkZXBlbmQgb24gdGhvc2UgdHdvIHByb3RvY29scy4gSSBndWVzcyBhIG5ldyBj b25uZWN0aW9uIGNvdWxkIGJlIGNyZWF0ZWQsIGJ1dCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgbm90 IG5lY2Vzc2FyeS4NCg0KVGhlIGludGVyb3AgaXNzdWUgaXMgcmVsYXRlZCB0byBzZWN0aW9uIDQu MSB0aGF0IHNheXMgdGhhdCBhbnkgc2Vzc2lvbiBiYXNlZCBwcm90b2NvbCBpcyBzdWl0YWJsZSBm b3IgRFNPLiBJZiB5b3UgbWFrZSBhIHNlcnZlciB0aGF0IG9ubHkgc3VwcG9ydHMgRFNPIG92ZXIg VENQIGFuZCBJIG1ha2UgYSBjbGllbnQgdGhhdCBvbmx5IHN1cHBvcnRzIERTTyBvdmVyIFFVSUMs IHRoZXkgYXJlIGJvdGggY29tcGxpYW50IHdpdGggdGhlIGRyYWZ0LCBidXQgdGhleSBjYW5ub3Qg Y29tbXVuaWNhdGUgd2l0aCBlYWNoIG90aGVyLiBUbyBhdm9pZCB0aGlzLCBJIHN1Z2dlc3QgdGhh dCB0aGlzIGRyYWZ0IG9ubHkgc3VwcG9ydHMgVExTIChhbmQgcG9zc2libHkgVENQKSwgYW5kIHN1 cHBvcnRpbmcgRFNPIG9uIGFueSBvdGhlciB1bmRlcmx5aW5nIHByb3RvY29sIHdvdWxkIHJlcXVp cmUgYSBuZXcgZG9jdW1lbnQuDQoNCkJldHRlcj8NCg0KVGhhbmtzLA0KDQpKYW4uDQoNCg0KRnJv bTogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPg0KRGF0ZTogV2VkbmVzZGF5LCBGZWJydWFy eSAxNCwgMjAxOCBhdCA1OjIyIFBNDQpUbzogIkphbiBLb21pc3NhciAoamtvbWlzc2EpIiA8amtv bWlzc2FAY2lzY28uY29tPg0KQ2M6IFBhdWwgSG9mZm1hbiA8cGF1bC5ob2ZmbWFuQHZwbmMub3Jn PiwgZG5zb3AgPGRuc29wQGlldGYub3JnPiwgImRuc3NkQGlldGYub3JnIiA8ZG5zc2RAaWV0Zi5v cmc+LCAiZG9oQGlldGYub3JnIiA8ZG9oQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtkbnNzZF0g W0ROU09QXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCAtIGRyYWZ0LWlldGYtZG5zb3Atc2Vzc2lv bi1zaWduYWwNCg0KT24gRmViIDE0LCAyMDE4LCBhdCA1OjEyIFBNLCBKYW4gS29taXNzYXIgKGpr b21pc3NhKSA8amtvbWlzc2FAY2lzY28uY29tPG1haWx0bzpqa29taXNzYUBjaXNjby5jb20+PiB3 cm90ZToNCjE6IEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcmVxdWlyZSBUTFMg Zm9yIGFsbCBEU08gY29ubmVjdGlvbnMuIFRoaXMgZG9jdW1lbnQgKERTTykgc3BlY2lmaWVzIHRo YXQgaXQgc2hvdWxkIHVzZSBUQ1Agb3IgVExTIGZvciBjb25uZWN0aW9ucywgYnV0IHRoZSBETlMg UHVzaCBOb3RpZmljYXRpb24gKERQTikgZHJhZnQgcmVxdWlyZXMgVExTLiBUaGlzIHdvdWxkIGNv bXBsaWNhdGUgbWF0dGVycyBpZiBhIHN0YW5kYXJkIFRDUCBjb25uZWN0aW9uIHdhcyBvcGVuZWQg Zm9yIG9uZSBwdXJwb3NlIGFuZCBsYXRlciBhIERQTiBvcGVyYXRpb24gb3ZlciB0aGUgc2FtZSBj b25uZWN0aW9uIHdhcyBhdHRlbXB0ZWQuIEFsc28sIGl0IGltcHJvdmVzIHNlY3VyaXR5IGZvciBh bGwgRFNPIG9wZXJhdGlvbnMuDQoNCkphbiwgSSdtIGhhdmluZyB0cm91YmxlIGZvbGxvd2luZyB5 b3VyIHJlYXNvbmluZyBoZXJlLiAgIFRoZSBjbGllbnQgdGhhdCBtYWtlcyB0aGUgY29ubmVjdGlv biBwcmVzdW1hYmx5IGtub3dzIHdoZXRoZXIgb3Igbm90IGl0J3MgZ29pbmcgdG8gZG8gRFBOLiAg IFdoeSB3b3VsZCB0aGVyZSBiZSBhbnkgY29uZnVzaW9uPw0KDQpETlMtb3Zlci1UQ1AgYW5kIERO Uy1vdmVyLVRMUyBhcmUgc3RhbmRhcmRzLiAgIEl0J3MgaGFyZCB0byBzZWUgd2hlcmUgdGhlIGlu dGVyb3AgaXNzdWUgd291bGQgYmUuICAgQ2FuIHlvdSBleHBhbmQgb24gdGhhdD8NCg0KQWxzbywg ZG8geW91IHRoaW5rIHRoYXQgRE5TLW92ZXItVENQIHNob3VsZCBiZSBmb3JtYWxseSBkZXByZWNh dGVkPyAgIElmIHNvLCBwZXJoYXBzIHRoYXQncyB0aGUgcmlnaHQgd2F5IHRvIGFkZHJlc3MgdGhp cy4gICBJZiBub3QsIGNhbiB5b3Ugc2F5IHdoeSBEU08gaXMgc3BlY2lhbCBhbmQgcmVxdWlyZXMg VExTLCB3aGVuIEROUy1vdmVyLVRDUCBkb2VzIG5vdD8NCg0K --_000_5AFBBFBECF5A4F7A9AC9F7E0040BBABDciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUZWQsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPknigJlsbCB0cnkgdG8gY2xhcmlmeTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q3VycmVu dGx5LCB0aGVyZSBhcmUgb25seSBwbGFucyBmb3IgRFBOLCBhbmQgdGhhdCB3b3VsZCBmb3JjZSBl dmVyeSBjb25uZWN0aW9uIHRvIGJlIFRMUy4gSG93ZXZlciwgaWYgYSBmdXR1cmUgcHJvdG9jb2wg 4oCcWi1vdmVyLURTT+KAnSBkb2VzIG5vdCByZXF1aXJlIFRMUywgaXQgaXMgcG9zc2libGUgdGhh dCBhIGNsaWVudCB3b3VsZCBjcmVhdGUgYSBUQ1AgY29ubmVjdGlvbiBmb3IgWiBhbmQgbGF0ZXIg d291bGQNCiB3YW50IHRvIHNlbmQgRFBOIG9wZXJhdGlvbiB0byB0aGUgc2FtZSBzZXJ2ZXIuIE5v dGUgdGhhdCB0aGUgRFNPIGNsaWVudCBtYXkgcmVwcmVzZW50IGEgc2luZ2xlIGNvbXB1dGVyLCB3 aGlsZSB0aGUgWiBhbmQgRFBOIHJlcXVlc3RzIHJlcHJlc2VudCBhcHBsaWNhdGlvbnMgb24gdGhh dCBjb21wdXRlciB0aGF0IGltcGxpY2l0bHkgZGVwZW5kIG9uIHRob3NlIHR3byBwcm90b2NvbHMu IEkgZ3Vlc3MgYSBuZXcgY29ubmVjdGlvbiBjb3VsZCBiZSBjcmVhdGVkLA0KIGJ1dCBpdCB3b3Vs ZCBiZSBiZXR0ZXIgaWYgbm90IG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGludGVyb3AgaXNzdWUgaXMgcmVsYXRlZCB0byBzZWN0aW9uIDQuMSB0aGF0IHNheXMgdGhhdCBh bnkgc2Vzc2lvbiBiYXNlZCBwcm90b2NvbCBpcyBzdWl0YWJsZSBmb3IgRFNPLiBJZiB5b3UgbWFr ZSBhIHNlcnZlciB0aGF0IG9ubHkgc3VwcG9ydHMgRFNPIG92ZXIgVENQIGFuZCBJIG1ha2UgYSBj bGllbnQgdGhhdCBvbmx5IHN1cHBvcnRzIERTTyBvdmVyIFFVSUMsIHRoZXkgYXJlIGJvdGggY29t cGxpYW50DQogd2l0aCB0aGUgZHJhZnQsIGJ1dCB0aGV5IGNhbm5vdCBjb21tdW5pY2F0ZSB3aXRo IGVhY2ggb3RoZXIuIFRvIGF2b2lkIHRoaXMsIEkgc3VnZ2VzdCB0aGF0IHRoaXMgZHJhZnQgb25s eSBzdXBwb3J0cyBUTFMgKGFuZCBwb3NzaWJseSBUQ1ApLCBhbmQgc3VwcG9ydGluZyBEU08gb24g YW55IG90aGVyIHVuZGVybHlpbmcgcHJvdG9jb2wgd291bGQgcmVxdWlyZSBhIG5ldyBkb2N1bWVu dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmV0dGVyPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkphbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+VGVkIExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5XZWRuZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDE4IGF0IDU6MjIgUE08YnI+DQo8Yj5U bzogPC9iPiZxdW90O0phbiBLb21pc3NhciAoamtvbWlzc2EpJnF1b3Q7ICZsdDtqa29taXNzYUBj aXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5QYXVsIEhvZmZtYW4gJmx0O3BhdWwuaG9mZm1h bkB2cG5jLm9yZyZndDssIGRuc29wICZsdDtkbnNvcEBpZXRmLm9yZyZndDssICZxdW90O2Ruc3Nk QGlldGYub3JnJnF1b3Q7ICZsdDtkbnNzZEBpZXRmLm9yZyZndDssICZxdW90O2RvaEBpZXRmLm9y ZyZxdW90OyAmbHQ7ZG9oQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW2Ru c3NkXSBbRE5TT1BdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIC0gZHJhZnQtaWV0Zi1kbnNvcC1z ZXNzaW9uLXNpZ25hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBGZWIgMTQsIDIwMTgsIGF0IDU6MTIgUE0sIEphbiBLb21pc3NhciAoamtv bWlzc2EpICZsdDs8YSBocmVmPSJtYWlsdG86amtvbWlzc2FAY2lzY28uY29tIj5qa29taXNzYUBj aXNjby5jb208L2E+Jmd0OyB3cm90ZToNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2Fucy1zZXJpZiI+MTogSSB0aGluayB0 aGF0IGl0IHdvdWxkIGJlIGJldHRlciB0byByZXF1aXJlIFRMUyBmb3IgYWxsIERTTyBjb25uZWN0 aW9ucy4gVGhpcyBkb2N1bWVudCAoRFNPKSBzcGVjaWZpZXMgdGhhdCBpdCBzaG91bGQgdXNlIFRD UCBvciBUTFMgZm9yIGNvbm5lY3Rpb25zLCBidXQgdGhlIEROUyBQdXNoDQogTm90aWZpY2F0aW9u IChEUE4pIGRyYWZ0IHJlcXVpcmVzIFRMUy4gVGhpcyB3b3VsZCBjb21wbGljYXRlIG1hdHRlcnMg aWYgYSBzdGFuZGFyZCBUQ1AgY29ubmVjdGlvbiB3YXMgb3BlbmVkIGZvciBvbmUgcHVycG9zZSBh bmQgbGF0ZXIgYSBEUE4gb3BlcmF0aW9uIG92ZXIgdGhlIHNhbWUgY29ubmVjdGlvbiB3YXMgYXR0 ZW1wdGVkLiBBbHNvLCBpdCBpbXByb3ZlcyBzZWN1cml0eSBmb3IgYWxsIERTTyBvcGVyYXRpb25z Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5KYW4sIEknbSBoYXZpbmcgdHJvdWJsZSBmb2xsb3dpbmcgeW91ciByZWFz b25pbmcgaGVyZS4gJm5ic3A7IFRoZSBjbGllbnQgdGhhdCBtYWtlcyB0aGUgY29ubmVjdGlvbiBw cmVzdW1hYmx5IGtub3dzIHdoZXRoZXIgb3Igbm90IGl0J3MgZ29pbmcgdG8gZG8gRFBOLiAmbmJz cDsgV2h5IHdvdWxkIHRoZXJlIGJlIGFueSBjb25mdXNpb24/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkROUy1vdmVyLVRDUCBhbmQgRE5TLW92 ZXItVExTIGFyZSBzdGFuZGFyZHMuICZuYnNwOyBJdCdzIGhhcmQgdG8gc2VlIHdoZXJlIHRoZSBp bnRlcm9wIGlzc3VlIHdvdWxkIGJlLiAmbmJzcDsgQ2FuIHlvdSBleHBhbmQgb24gdGhhdD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywg ZG8geW91IHRoaW5rIHRoYXQgRE5TLW92ZXItVENQIHNob3VsZCBiZSBmb3JtYWxseSBkZXByZWNh dGVkPyAmbmJzcDsgSWYgc28sIHBlcmhhcHMgdGhhdCdzIHRoZSByaWdodCB3YXkgdG8gYWRkcmVz cyB0aGlzLiAmbmJzcDsgSWYgbm90LCBjYW4geW91IHNheSB3aHkgRFNPIGlzIHNwZWNpYWwgYW5k IHJlcXVpcmVzIFRMUywgd2hlbiBETlMtb3Zlci1UQ1AgZG9lcyBub3Q/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5AFBBFBECF5A4F7A9AC9F7E0040BBABDciscocom_-- From nobody Wed Feb 14 15:13:58 2018 Return-Path: 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 46138126CD8 for ; Wed, 14 Feb 2018 15:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 NhkAQhGDLN_K for ; Wed, 14 Feb 2018 15:13:52 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3524212711B for ; Wed, 14 Feb 2018 15:13:52 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id u6so9816737qtg.13 for ; Wed, 14 Feb 2018 15:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LcAG1GklvpMReCOBKC51IEAmNOw3TB+r4CSuOQBhkOc=; b=bIBOALsByzQrUvYRCy1SGL7HL7nq0XIj6lbmHqpkohJypQkqEMP8MyGkE2ZoYpr2Km lT+yexGD8e+c+hh0FjcI4uE13uA5xLBfCdaZlpiyRizp+riLtxCj4evhRLD3huG3SuEA qkU8R6mUwpgzGA7nM+lFuQzFUGOG40KRcPsyRjmXy43ID1NvUqHuYXpr/Fd9VxE+nKFc 6pLynsK1iwPN10/uDBna3hYoPPxfYGY+ruAQhCAnMV6jvh24XZPFAm2Aw61Ut8k5kesF O11ul0MM8WpvcSSZGSiNQH9cp/D2X4ViVDJb+TpmZVDXOW3gW4dhogN3N1r3DxeENlnE goyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LcAG1GklvpMReCOBKC51IEAmNOw3TB+r4CSuOQBhkOc=; b=eVKmsyrUzkwfjZ94ZRyoM+QAnCHI1t1Y9hjCeWPdoWmy+NS/ya2rMwB4FvHI7UxqnQ EAq9oYMES46p/NZsAoeuARDo7tqG7HKvFK60RutU2cRZiy5t8N91Ty8h/fUBmvV3G0iv 0gZEZH/yCElJ/iAhvncMSmnFMbifWa1Kc1oS/6+dr7qysVqli7aUgBrA/TP854Jw6tTQ fNciBKTdQQvl3Tgqx8vcexsK2yIjHZ/qAtpCuSqaXA7sQzTyv2NQXKD8QLP9+Gpc+Q98 0FbOdV+v9r60qKNbbiwP3R5JT+wjlEHNkg1e8i6zCxvEMQMI2a+7/hf34aEDRttVSzgz kE7w== X-Gm-Message-State: APf1xPCAQ5ykfvO2vyueVMHxb6NzmHRre6jyFTARqONSbIO3UOyoeDjP sSa7MRHtKZ3fF1bDKl6pcjUEXQ== X-Google-Smtp-Source: AH8x227gc9/qbzlqt8WzTf9jSTvJYejLPKKEUIBbffa6iZ2nsM7Nf65u9tGeng8gc3f8zVRwmcpb3w== X-Received: by 10.200.53.121 with SMTP id z54mr1266378qtb.278.1518650031207; Wed, 14 Feb 2018 15:13:51 -0800 (PST) Received: from [10.0.1.16] ([8.20.190.66]) by smtp.gmail.com with ESMTPSA id w63sm908778qtd.76.2018.02.14.15.13.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 15:13:50 -0800 (PST) From: Ted Lemon Message-Id: <34561144-6844-4E00-90E9-41095A9E14E6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_06F1DF30-8E0D-43FB-991F-A0C44D12D6F3" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 14 Feb 2018 18:13:47 -0500 In-Reply-To: <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> Cc: Paul Hoffman , dnsop , "dnssd@ietf.org" , "doh@ietf.org" To: "Jan Komissar (jkomissa)" References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Feb 2018 23:13:54 -0000 --Apple-Mail=_06F1DF30-8E0D-43FB-991F-A0C44D12D6F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 14, 2018, at 6:06 PM, Jan Komissar (jkomissa) = wrote: > Currently, there are only plans for DPN, and that would force every = connection to be TLS. However, if a future protocol =E2=80=9CZ-over-DSO=E2= =80=9D does not require TLS, it is possible that a client would create a = TCP connection for Z and later would want to send DPN operation to the = same server. Note that the DSO client may represent a single computer, = while the Z and DPN requests represent applications on that computer = that implicitly depend on those two protocols. I guess a new connection = could be created, but it would be better if not necessary. Hm, is that really true? What is the scenario that you envision here? = Like, when would this actually happen? What's the client that's making = the connection? How is it that it is the same client that's doing DPN? = If it is configured to support TLS, why isn't it defaulting to that? > The interop issue is related to section 4.1 that says that any = session based protocol is suitable for DSO. If you make a server that = only supports DSO over TCP and I make a client that only supports DSO = over QUIC, they are both compliant with the draft, but they cannot = communicate with each other. To avoid this, I suggest that this draft = only supports TLS (and possibly TCP), and supporting DSO on any other = underlying protocol would require a new document. I think I've heard other suggestions that we should enumerate which = protocols are supported explicitly, but I don't think there's a = requirement to support DSO over anything. We're just describing a new = DNS message type that can be used with any connection-oriented protocol. You didn't answer my third question: > Also, do you think that DNS-over-TCP should be formally deprecated? = If so, perhaps that's the right way to address this. If not, can you = say why DSO is special and requires TLS, when DNS-over-TCP does not? Is is that you want to make DSO-over-TLS MTI and DSO-over-TCP optional? --Apple-Mail=_06F1DF30-8E0D-43FB-991F-A0C44D12D6F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 14, 2018, at 6:06 PM, Jan Komissar (jkomissa) <jkomissa@cisco.com> = wrote:
Currently, = there are only plans for DPN, and that would force every connection to = be TLS. However, if a future protocol =E2=80=9CZ-over-DSO=E2=80=9D does = not require TLS, it is possible that a client would create a TCP = connection for Z and later would want to send DPN operation to the same = server. Note that the DSO client may represent a single computer, while = the Z and DPN requests represent applications on that computer that = implicitly depend on those two protocols. I guess a new connection could = be created, but it would be better if not = necessary.

Hm, is that = really true?   What is the scenario that you envision here? =  Like, when would this actually happen?   What's the client = that's making the connection?   How is it that it is the same = client that's doing DPN?   If it is configured to support TLS, why = isn't it defaulting to that?

 The interop issue is related to section 4.1 that says that = any session based protocol is suitable for DSO. If you make a server = that only supports DSO over TCP and I make a client that only supports = DSO over QUIC, they are both compliant with the draft, but they cannot = communicate with each other. To avoid this, I suggest that this draft = only supports TLS (and possibly TCP), and supporting DSO on any other = underlying protocol would require a new = document.

I = think I've heard other suggestions that we should enumerate which = protocols are supported explicitly, but I don't think there's a = requirement to support DSO over anything.   We're just describing a = new DNS message type that can be used with any connection-oriented = protocol.

You = didn't answer my third question:

Also, do you think that = DNS-over-TCP should be formally deprecated?   If so, perhaps that's = the right way to address this.   If not, can you say why DSO is = special and requires TLS, when DNS-over-TCP does not?

Is is = that you want to make DSO-over-TLS MTI and DSO-over-TCP = optional?

= --Apple-Mail=_06F1DF30-8E0D-43FB-991F-A0C44D12D6F3-- From nobody Wed Feb 14 16:24:54 2018 Return-Path: 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 76B71126CF9 for ; Wed, 14 Feb 2018 16:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 7GEFMAps6ISL for ; Wed, 14 Feb 2018 16:24:50 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFAED127010 for ; Wed, 14 Feb 2018 16:24:50 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 335FA1CAE4F for ; Wed, 14 Feb 2018 16:24:19 -0800 (PST) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by c8a.amsl.com (Postfix) with ESMTPSA id 1149F1CAE3D for ; Wed, 14 Feb 2018 16:24:19 -0800 (PST) Received: by mail-it0-f47.google.com with SMTP id j21so14448430ita.1 for ; Wed, 14 Feb 2018 16:24:50 -0800 (PST) X-Gm-Message-State: APf1xPAv4rB9FUOx3dfMdSNjSoy8DXLm3HFu0CBGWoXxAjTw/1tkVD3s rguglHLgPHCog7LTKZxORJmEmHSz6m3O88u99B0= X-Google-Smtp-Source: AH8x226gBuaAXYmYneUeEiUclpyTJrGiwuEmUGkUyiDgEEAV7SNmywcKmwa/03lIsGmfdJD2AjnsrQO4CrCXpdrGRbA= X-Received: by 10.36.132.76 with SMTP id h73mr1139784itd.110.1518654290239; Wed, 14 Feb 2018 16:24:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.1.68 with HTTP; Wed, 14 Feb 2018 16:24:29 -0800 (PST) From: Glen Date: Wed, 14 Feb 2018 16:24:29 -0800 X-Gmail-Original-Message-ID: Message-ID: To: doh@ietf.org Content-Type: multipart/alternative; boundary="001a113b930881a4a605653541a5" Archived-At: Subject: [Doh] Possible missed messages on this list X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 00:24:52 -0000 --001a113b930881a4a605653541a5 Content-Type: text/plain; charset="UTF-8" Possible missed messages on this list Dear list participants - An upgrade to the IETF's custom mail processing software today resulted in some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours. We invite you to check the mail archives for this list, at: https://mailarchive.ietf.org/arch/search/?email_list=doh to ensure that you have received all the relevant messages for this list today. We apologize for the inconvenience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --001a113b930881a4a605653541a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Possible missed messages on this list

Dear list participants -
An upgrade to the IETF's custom mail processing software today resulted i= n some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours.

We invite you to check the mail archiv= es for this list, at:

https://mailarchive.ietf.org/arch/search/?email_li= st=3Ddoh

to ensure that you have received all the relevant messa= ges for this list today.

We apologize for the inconvenience.

= Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)


--001a113b930881a4a605653541a5-- From nobody Thu Feb 15 08:14:33 2018 Return-Path: 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 9BF5812DA4D for ; Thu, 15 Feb 2018 08:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 4gLF3ykGKVCN for ; Thu, 15 Feb 2018 08:14:27 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 A992C126B7E for ; Thu, 15 Feb 2018 08:14:27 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id E5C02280172; Thu, 15 Feb 2018 17:14:25 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id E042A28017D; Thu, 15 Feb 2018 17:14:25 +0100 (CET) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id D9B33280172; Thu, 15 Feb 2018 17:14:25 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id D66A5642C581; Thu, 15 Feb 2018 17:14:25 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id CDB6041249; Thu, 15 Feb 2018 17:14:25 +0100 (CET) Date: Thu, 15 Feb 2018 17:14:25 +0100 From: Stephane Bortzmeyer To: Patrick McManus Cc: doh@ietf.org Message-ID: <20180215161425.b3gjam66qnvxqwpe@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.093210, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.15.160915 Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 16:14:32 -0000 On Fri, Feb 02, 2018 at 02:22:44PM -0500, Patrick McManus wrote a message of 55 lines which said: > of course you should read the draft, comment, and open issues as necessary. No strong opinion on the controversial issues, sorry. Editorial: "Specifications that define media types for use with DOH, such as DNS Wire Format Section 5.1 of this document, MUST indicate if the body parameter uses base64url encoding." Isn't it "dns" now and not "body"? "When using the GET method, the body MUST be encoded with base64url" Same problem. I believe that, in HTTP, you cannot use the word "body" for URI parameters. There is at least one occurrence of "DOH server" instead of "DNS API server". (I myself prefer "DOS server", there is nothing really APIesque in DoH.) From nobody Thu Feb 15 08:53:32 2018 Return-Path: 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 6B4D212D775 for ; Thu, 15 Feb 2018 08:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 OcBFdwRDzP4u for ; Thu, 15 Feb 2018 08:53:29 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 0F316129C56 for ; Thu, 15 Feb 2018 08:53:29 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1FGmK2p024916; Thu, 15 Feb 2018 16:53:28 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OxfO6FDcnwiNfEVREkyxnIzZj/NMcrK5tXVZ2Yj23rg=; b=F8xb45fIary8VFJuSAFG/BQm9sEu7mYOWeFt7i6f+AT5Zy/+vNcSvtZd/7+/uI0IJmMy uRshpyFnkzAfyGf/BjaMiCIwAsXbOZXaQh9GEw+IaVR4f0FJbozjku8a8lYLLykXKIp3 Ez682Pb/hUOOt3qEc9lLgha4e9uibhOTpbJWogQzHd+kPslj+5dlBRW15YLF9ooqGBn9 HOCUYxMotdNUWjqsqdKQRKQVUgTv6Yqn2CnqQat84s0yf6qCaaMMkU1PRPulG4UmwC4j N30LqheoFwTZ4wpVFguWH7ttgW9ZsxD8XGFTm8FRcTieO75Bo4ODXLaH53/t8HmsrMnO sQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2g48w2dvp7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Feb 2018 16:53:27 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1FGpSoa023879; Thu, 15 Feb 2018 11:53:26 -0500 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint3.akamai.com with ESMTP id 2g1vy1eqm6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Feb 2018 11:53:26 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Feb 2018 10:53:25 -0600 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.1263.000; Thu, 15 Feb 2018 10:53:25 -0600 From: "Hewitt, Rory" To: Stephane Bortzmeyer , Patrick McManus CC: "doh@ietf.org" Thread-Topic: [Doh] Changes for draft-ietf-doh-dns-over-https-03 Thread-Index: AQHTnFs5Ya+wWZYL2Ui/KO2Y9reH66OmG/aA//+mDaA= Date: Thu, 15 Feb 2018 16:53:25 +0000 Message-ID: <69df5d30e4644a01894f4689bfebc029@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20180215161425.b3gjam66qnvxqwpe@nic.fr> In-Reply-To: <20180215161425.b3gjam66qnvxqwpe@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.177] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_066E_01D3A63A.6FEAD010" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-15_06:, , 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-1711220000 definitions=main-1802150204 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-15_06:, , 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-1711220000 definitions=main-1802150203 Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 16:53:30 -0000 ------=_NextPart_000_066E_01D3A63A.6FEAD010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Stephane Bortzmeyer wrote: "There is at least one occurrence of "DOH server" instead of "DNS API server". (I myself prefer "DOS server", there is nothing really APIesque in DoH.)" Why not just DNS server? Rory ------=_NextPart_000_066E_01D3A63A.6FEAD010 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDIxNTE2NTMyM1owIwYJKoZIhvcNAQkEMRYEFJZ2pdF1QVK5XC7IBfOfoKKRfIyUMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBADFJLrDVZULuN2z22Q3LKIfanADwWqkNohJp5zkba26KPXyCBhoQDc/lXC7b aXm7Y2takw5cxuHccEtJWW6cYj4tcS6Zf5bhhRFxqboRjqbml39Gz5ut6xmNtUsOAtRiQA+SBCML OwDkpkUAsCE7fiT7FAkaeMUClvIv7Fy7bDx9dqJ8gItWT4asLl0QiXFG7YBWUtzXgTaFiLKKRzeF 0UfpmTGMq/elwga+RXyAY/DPculF6kLEdK8E9UIfRBULKcKbur7kz6i9+zDEll0u6uP/qO++TX0W 7MjDxSTUH6hqToVRxUrDyEuxQgTfMPEdlzOXShV/umB89uBkC4BKoXQAAAAAAAA= ------=_NextPart_000_066E_01D3A63A.6FEAD010-- From nobody Thu Feb 15 08:57:25 2018 Return-Path: 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 8198512D949 for ; Thu, 15 Feb 2018 08:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KUdRGxFGkTxf for ; Thu, 15 Feb 2018 08:57:22 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 E5635129C56 for ; Thu, 15 Feb 2018 08:57:21 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 7472F280172; Thu, 15 Feb 2018 17:57:20 +0100 (CET) Received: by mx4.nic.fr (Postfix, from userid 500) id 6DBEE28017D; Thu, 15 Feb 2018 17:57:20 +0100 (CET) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id 67356280172; Thu, 15 Feb 2018 17:57:20 +0100 (CET) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 6254E663EBE0; Thu, 15 Feb 2018 17:57:20 +0100 (CET) Received: by b12.nic.fr (Postfix, from userid 1000) id 550D641249; Thu, 15 Feb 2018 17:57:20 +0100 (CET) Date: Thu, 15 Feb 2018 17:57:20 +0100 From: Stephane Bortzmeyer To: "Hewitt, Rory" Cc: Stephane Bortzmeyer , Patrick McManus , "doh@ietf.org" Message-ID: <20180215165720.5qjj43safhvohnup@nic.fr> References: <20180215161425.b3gjam66qnvxqwpe@nic.fr> <69df5d30e4644a01894f4689bfebc029@ustx2ex-dag1mb3.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69df5d30e4644a01894f4689bfebc029@ustx2ex-dag1mb3.msg.corp.akamai.com> X-Operating-System: Debian GNU/Linux 9.3 X-Kernel: Linux 4.9.0-5-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.15.164216 Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 16:57:23 -0000 On Thu, Feb 15, 2018 at 04:53:25PM +0000, Hewitt, Rory wrote a message of 139 lines which said: > > (I myself prefer "DOS server", there is nothing really APIesque in > > DoH.) > > Why not just DNS server? The idea is to find a way to tell apart DNS-over-HTTPS servers from "classic" DNS servers. From nobody Thu Feb 15 09:00:47 2018 Return-Path: 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 B599D1289B0 for ; Thu, 15 Feb 2018 09:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=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 yw9rflT32dRf for ; Thu, 15 Feb 2018 09:00:42 -0800 (PST) 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 AACC912DA41 for ; Thu, 15 Feb 2018 09:00:42 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1FGwlt9006890; Thu, 15 Feb 2018 17:00:40 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=LNmLVIYNw8CqCjf5kjkmDpXGnYr/1jHBMM0SdjS6wno=; b=oi1SDiKTUkgVDqYeyyHFIxgvebH63aQuaZVA8wpYuz3C1q39ecK7J/Vs0Ro8Fo7a8x5A Kvxqq6Zem/KyEoW7A18QUPlKZcoepsgfKjJpz1DgxohPLXwoV2UzUtFeaay0YjB3cuPw dgTL6Nmsav1hXP5ae8NM9Euub598x9Fl43Cu+AV/VIPPmIM7HXlOKiaO0n2hT6islYEc 22M/+wHcwluBoULko9S+TQzbfVbUxYns+dydSvT3X+JW3Ev57hQcBK+FtO1OiPIlARmV 50u9Ogg5vBj2JUpI9XiaZa2bNBfPq+IxhZk4mb1yaZKu9oVwNQSpwimnAUIMbKxBbn4G ng== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2g5d1y87ev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Feb 2018 17:00:38 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1FGtxaj002875; Thu, 15 Feb 2018 12:00:38 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2g1vy0ppx6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Feb 2018 12:00:38 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 15 Feb 2018 11:00:36 -0600 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.1263.000; Thu, 15 Feb 2018 11:00:35 -0600 From: "Hewitt, Rory" To: Stephane Bortzmeyer CC: Patrick McManus , "doh@ietf.org" Thread-Topic: [Doh] Changes for draft-ietf-doh-dns-over-https-03 Thread-Index: AQHTnFs5Ya+wWZYL2Ui/KO2Y9reH66OmG/aA//+mDaCAAGXxAP//m7fQ Date: Thu, 15 Feb 2018 17:00:35 +0000 Message-ID: <6c5d6f3d21aa44d8b18a27fc8a896f0a@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20180215161425.b3gjam66qnvxqwpe@nic.fr> <69df5d30e4644a01894f4689bfebc029@ustx2ex-dag1mb3.msg.corp.akamai.com> <20180215165720.5qjj43safhvohnup@nic.fr> In-Reply-To: <20180215165720.5qjj43safhvohnup@nic.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.177] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0673_01D3A63B.70056780" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-15_06:, , 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-1711220000 definitions=main-1802150205 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-15_06:, , 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-1711220000 definitions=main-1802150205 Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 17:00:45 -0000 ------=_NextPart_000_0673_01D3A63B.70056780 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well but from the POV of this doc, we're *only* talking about DOH servers. If we were explicitly contrasting them with 'traditional' DNS servers, I'd want the difference. A DNS server is a DNS server is a DNS server. It's how we access them that makes a difference... Thanks, Rory Rory Hewitt Senior Solutions Architect Global Services & Support Akamai Technologies Tel: (408) 650-0035 -----Original Message----- From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] Sent: Thursday, February 15, 2018 8:57 AM To: Hewitt, Rory Cc: Stephane Bortzmeyer ; Patrick McManus ; doh@ietf.org Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 On Thu, Feb 15, 2018 at 04:53:25PM +0000, Hewitt, Rory wrote a message of 139 lines which said: > > (I myself prefer "DOS server", there is nothing really APIesque in > > DoH.) > > Why not just DNS server? The idea is to find a way to tell apart DNS-over-HTTPS servers from "classic" DNS servers. ------=_NextPart_000_0673_01D3A63B.70056780 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDIxNTE3MDAzM1owIwYJKoZIhvcNAQkEMRYEFGm9Gxlz2Q3C6coIBQk6DESXVwFkMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBALdETwh+O0sNkbIG/DjY7eVuKZrnwGTohNquTjoriXwJota7Q/9QvnlEf2qb p5Q44lLEyOcnqrNkd/bGCY2QjToSvmW6ed1Ntjo7kQ/dT0uWUd/da7nlu9cePi+ZkfPT4/9Wjrqo UukmI7MeiNAZE41oDqWrvtKeKs5o+n17yPguD5WMsQvf1U4xY5swVVpKW2yYGqBPs4mONNq2Nd4V 0kRYHVRrjvspq26YEPs7U3Qzz7lokolPVFmzY1j4j2/UzJZ3+EBjR4GqT08dwXgQ/GMPXEGsK5Re mBdwmVh7l1Gzb0T7t9vRXv38b7C69XBM9vBZFxwVE4oHqS1awSMlL0UAAAAAAAA= ------=_NextPart_000_0673_01D3A63B.70056780-- From nobody Thu Feb 15 09:18:18 2018 Return-Path: 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 C3FF612D775 for ; Thu, 15 Feb 2018 09:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.102 X-Spam-Level: ** X-Spam-Status: No, score=2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 g5LQMAA6kIJ5 for ; Thu, 15 Feb 2018 09:18:13 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF311289B0 for ; Thu, 15 Feb 2018 09:18:13 -0800 (PST) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id A82543A085 for ; Thu, 15 Feb 2018 12:18:12 -0500 (EST) Received: by mail-oi0-f50.google.com with SMTP id 24so334431oij.3 for ; Thu, 15 Feb 2018 09:18:12 -0800 (PST) X-Gm-Message-State: APf1xPDCsB2XRo9U2RIwd4mDl5qkjptyZdr7i0BSXBDO7zaT04mbyuXo bQXEdILmNS1br8hGcyVKQEb3Hz7m4YHEZFEuNCg= X-Google-Smtp-Source: AH8x225gxvqRyjFnknV4XGKwMB5s3Vr6Whg71y+WZniVuEeaFDTTgam20wmRK6fSdWLTtJzaGjdx9jjJZcabfI+xW48= X-Received: by 10.202.74.143 with SMTP id x137mr2389915oia.101.1518715092350; Thu, 15 Feb 2018 09:18:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.66.212 with HTTP; Thu, 15 Feb 2018 09:18:11 -0800 (PST) In-Reply-To: <6c5d6f3d21aa44d8b18a27fc8a896f0a@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20180215161425.b3gjam66qnvxqwpe@nic.fr> <69df5d30e4644a01894f4689bfebc029@ustx2ex-dag1mb3.msg.corp.akamai.com> <20180215165720.5qjj43safhvohnup@nic.fr> <6c5d6f3d21aa44d8b18a27fc8a896f0a@ustx2ex-dag1mb3.msg.corp.akamai.com> From: Patrick McManus Date: Thu, 15 Feb 2018 12:18:11 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Hewitt, Rory" Cc: Stephane Bortzmeyer , Patrick McManus , "doh@ietf.org" Content-Type: multipart/alternative; boundary="001a1134ebb89844d40565436920" Archived-At: Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 17:18:16 -0000 --001a1134ebb89844d40565436920 Content-Type: text/plain; charset="UTF-8" Thank you for these "Specifications that define media types for use with DOH, such as DNS Wire Format Section 5.1 of this document, MUST indicate if the body parameter uses base64url encoding." Isn't it "dns" now and not "body"? "When using the GET method, the body MUST be encoded with base64url" Same problem. I believe that, in HTTP, you cannot use the word "body" for URI parameters. On Thu, Feb 15, 2018 at 12:00 PM, Hewitt, Rory wrote: > Well but from the POV of this doc, we're *only* talking about DOH servers. > If we were explicitly contrasting them with 'traditional' DNS servers, I'd > want the difference. > > A DNS server is a DNS server is a DNS server. It's how we access them that > makes a difference... > > Thanks, > > Rory > > Rory Hewitt > Senior Solutions Architect > Global Services & Support > Akamai Technologies > Tel: (408) 650-0035 > > -----Original Message----- > From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr] > Sent: Thursday, February 15, 2018 8:57 AM > To: Hewitt, Rory > Cc: Stephane Bortzmeyer ; Patrick McManus > ; doh@ietf.org > Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03 > > On Thu, Feb 15, 2018 at 04:53:25PM +0000, Hewitt, Rory < > rhewitt@akamai.com> > wrote a message of 139 lines which said: > > > > (I myself prefer "DOS server", there is nothing really APIesque in > > > DoH.) > > > > Why not just DNS server? > > The idea is to find a way to tell apart DNS-over-HTTPS servers from > "classic" DNS servers. > --001a1134ebb89844d40565436920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for these

"Specifications that define media types for use with DOH, such as DNS<= br> Wire Format Section 5.1 of this document, MUST indicate if the body
parameter uses base64url encoding." Isn't it "dns" now a= nd not "body"?

"When using the GET method, the body MUST be encoded with base64url&qu= ot;
Same problem. I believe that, in HTTP, you cannot use the word "body&q= uot;
for URI parameters.




On Thu, Feb 15, 2018 at 12:= 00 PM, Hewitt, Rory <rhewitt@akamai.com> wrote:
Well but from the POV of this doc, we're *only* = talking about DOH servers.
If we were explicitly contrasting them with 'traditional' DNS serve= rs, I'd
want the difference.

A DNS server is a DNS server is a DNS server. It's how we access them t= hat
makes a difference...

Thanks,

Rory

Rory Hewitt
Senior Solutions Architect
Global Services & Support
Akamai Technologies
Tel: (408) 650-0035

-----Original Message-----
From: Stephane Bortzmeyer [mailto:bort= zmeyer@nic.fr]
Sent: Thursday, February 15, 2018 8:57 AM
To: Hewitt, Rory <rhewitt@akamai.c= om>
Cc: Stephane Bortzmeyer <bortzmeyer= @nic.fr>; Patrick McManus
<pmcmanus@mozilla.com>; <= a href=3D"mailto:doh@ietf.org">doh@ietf.org
Subject: Re: [Doh] Changes for draft-ietf-doh-dns-over-https-03

On Thu, Feb 15, 2018 at 04:53:25PM +0000,=C2=A0 Hewitt, Rory <rhewitt@akamai.com>
wrote=C2=A0 a message of 139 lines which said:

> > (I myself prefer "DOS server", there is nothing really = APIesque in
> > DoH.)
>
> Why not just DNS server?

The idea is to find a way to tell apart DNS-over-HTTPS servers from
"classic" DNS servers.

--001a1134ebb89844d40565436920-- From nobody Thu Feb 15 14:35:05 2018 Return-Path: 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 198F812D947; Thu, 15 Feb 2018 14:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 aFhGgi9S5Uym; Thu, 15 Feb 2018 14:34:50 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DEA12D837; Thu, 15 Feb 2018 14:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15936; q=dns/txt; s=iport; t=1518734090; x=1519943690; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rpNomXkibcde4/zpprxgOXJqv8U1kFY5ctkdsAjoFAA=; b=M51IRbDgAn0R420mYYDk98cWmKA6ZGCTmobqj3stfMD9WYJUDDjOedZI 6Tx0wiWQCa9SJ/h54ei0qvvM8mOGjRfBUaE/QSIpW+jRImHsCDWvk4OCo tvLVTiDRtlUjzroCHzgrLIzJ6I4R/i01hNse/h04MqZj0nhNfYr82WY6t 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAADNCoZa/51dJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaeGZwKAqDW4oljgKCAnwbkGmFXIIYCoU7AhqCKFQYAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQQjVhACAQgOAwMBAigDAgICMBQJCAIEDgWJUWSvP4InJohPg?= =?us-ascii?q?hMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhQOCJ4FXgWgpgk82hQw2FoJhMYI0BaQ?= =?us-ascii?q?yCQKWA5RGl28CERkBgTsBHzmBUXAVZwGCG4R3eIx9AYEYAQEB?= X-IronPort-AV: E=Sophos; i="5.46,518,1511827200"; d="scan'208,217"; a="70920066" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 22:34:49 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w1FMYmOK011153 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 22:34:48 GMT Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 16:34:48 -0600 Received: from xch-aln-019.cisco.com ([173.36.7.29]) by XCH-ALN-019.cisco.com ([173.36.7.29]) with mapi id 15.00.1320.000; Thu, 15 Feb 2018 16:34:48 -0600 From: "Jan Komissar (jkomissa)" To: Ted Lemon CC: Paul Hoffman , dnsop , "dnssd@ietf.org" , "doh@ietf.org" Thread-Topic: [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal Thread-Index: AQHTm5D+P8Hdt54fVUSceurV+Y+5IKOSDxkAgBKMVQCAAFapAP//uH4AgABVzICAATOegA== Date: Thu, 15 Feb 2018 22:34:48 +0000 Message-ID: <3F61D530-DD24-40A3-B6C8-C6EC7936784E@cisco.com> References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> <34561144-6844-4E00-90E9-41095A9E14E6@fugue.com> In-Reply-To: <34561144-6844-4E00-90E9-41095A9E14E6@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.25.0.170815 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.67.103] Content-Type: multipart/alternative; boundary="_000_3F61D530DD2440A3B6C8C6EC7936784Eciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 22:34:53 -0000 --_000_3F61D530DD2440A3B6C8C6EC7936784Eciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KDQpBZnRlciBwb25kZXJpbmcgeW91ciByZXNwb25zZSwgbXkgY29tbWVudHMgYXJl IGlubGluZToNCg0KRnJvbTogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPg0KRGF0ZTogV2Vk bmVzZGF5LCBGZWJydWFyeSAxNCwgMjAxOCBhdCA2OjEzIFBNDQpUbzogIkphbiBLb21pc3NhciAo amtvbWlzc2EpIiA8amtvbWlzc2FAY2lzY28uY29tPg0KQ2M6IFBhdWwgSG9mZm1hbiA8cGF1bC5o b2ZmbWFuQHZwbmMub3JnPiwgZG5zb3AgPGRuc29wQGlldGYub3JnPiwgImRuc3NkQGlldGYub3Jn IiA8ZG5zc2RAaWV0Zi5vcmc+LCAiZG9oQGlldGYub3JnIiA8ZG9oQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtkbnNzZF0gW0ROU09QXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCAtIGRyYWZ0LWll dGYtZG5zb3Atc2Vzc2lvbi1zaWduYWwNCg0KT24gRmViIDE0LCAyMDE4LCBhdCA2OjA2IFBNLCBK YW4gS29taXNzYXIgKGprb21pc3NhKSA8amtvbWlzc2FAY2lzY28uY29tPG1haWx0bzpqa29taXNz YUBjaXNjby5jb20+PiB3cm90ZToNCkN1cnJlbnRseSwgdGhlcmUgYXJlIG9ubHkgcGxhbnMgZm9y IERQTiwgYW5kIHRoYXQgd291bGQgZm9yY2UgZXZlcnkgY29ubmVjdGlvbiB0byBiZSBUTFMuIEhv d2V2ZXIsIGlmIGEgZnV0dXJlIHByb3RvY29sIOKAnFotb3Zlci1EU0/igJ0gZG9lcyBub3QgcmVx dWlyZSBUTFMsIGl0IGlzIHBvc3NpYmxlIHRoYXQgYSBjbGllbnQgd291bGQgY3JlYXRlIGEgVENQ IGNvbm5lY3Rpb24gZm9yIFogYW5kIGxhdGVyIHdvdWxkIHdhbnQgdG8gc2VuZCBEUE4gb3BlcmF0 aW9uIHRvIHRoZSBzYW1lIHNlcnZlci4gTm90ZSB0aGF0IHRoZSBEU08gY2xpZW50IG1heSByZXBy ZXNlbnQgYSBzaW5nbGUgY29tcHV0ZXIsIHdoaWxlIHRoZSBaIGFuZCBEUE4gcmVxdWVzdHMgcmVw cmVzZW50IGFwcGxpY2F0aW9ucyBvbiB0aGF0IGNvbXB1dGVyIHRoYXQgaW1wbGljaXRseSBkZXBl bmQgb24gdGhvc2UgdHdvIHByb3RvY29scy4gSSBndWVzcyBhIG5ldyBjb25uZWN0aW9uIGNvdWxk IGJlIGNyZWF0ZWQsIGJ1dCBpdCB3b3VsZCBiZSBiZXR0ZXIgaWYgbm90IG5lY2Vzc2FyeS4NCg0K SG0sIGlzIHRoYXQgcmVhbGx5IHRydWU/ICAgV2hhdCBpcyB0aGUgc2NlbmFyaW8gdGhhdCB5b3Ug ZW52aXNpb24gaGVyZT8gIExpa2UsIHdoZW4gd291bGQgdGhpcyBhY3R1YWxseSBoYXBwZW4/ICAg V2hhdCdzIHRoZSBjbGllbnQgdGhhdCdzIG1ha2luZyB0aGUgY29ubmVjdGlvbj8gICBIb3cgaXMg aXQgdGhhdCBpdCBpcyB0aGUgc2FtZSBjbGllbnQgdGhhdCdzIGRvaW5nIERQTj8gICBJZiBpdCBp cyBjb25maWd1cmVkIHRvIHN1cHBvcnQgVExTLCB3aHkgaXNuJ3QgaXQgZGVmYXVsdGluZyB0byB0 aGF0Pw0KDQpKYW46DQpJIHdhcyBpbWFnaW5pbmcgYSBzaW5nbGUgb3BlcmF0aW5nIHN5c3RlbSBz ZXJ2aWNlIHBlcmZvcm1pbmcgYWxsIERTTyBiYXNlZCBvcGVyYXRpb25zIG9uIGJlaGFsZiBvZiB2 YXJpb3VzIGFwcGxpY2F0aW9ucywgYnV0IGl0IHdvdWxkIHByb2JhYmx5IG1vcmUgbGlrZWx5IGJl IG9uZSBzZXJ2aWNlIGZvciBhbGwgRFBOIHVzZXJzIGFuZCBhbm90aGVyIGZvciBwcm90b2NvbCBa IHVzZXJzLCBhbmQgdGhlIGV4aXN0aW5nIHN0dWIgcmVzb2x2ZXIgZm9yIHRyYWRpdGlvbmFsIERO UyBxdWVyaWVzLiBBbmQgaW4gdGhhdCBjYXNlLCB0aGVyZSB3b3VsZCBiZSBubyByZWFzb24gdG8g Zm9yY2UgYWxsIERTTyBiYXNlZCBvcGVyYXRpb25zIGludG8gVExTLiBJIGNhbiBsaXZlIHdpdGgg dGhhdC4NCg0KIFRoZSBpbnRlcm9wIGlzc3VlIGlzIHJlbGF0ZWQgdG8gc2VjdGlvbiA0LjEgdGhh dCBzYXlzIHRoYXQgYW55IHNlc3Npb24gYmFzZWQgcHJvdG9jb2wgaXMgc3VpdGFibGUgZm9yIERT Ty4gSWYgeW91IG1ha2UgYSBzZXJ2ZXIgdGhhdCBvbmx5IHN1cHBvcnRzIERTTyBvdmVyIFRDUCBh bmQgSSBtYWtlIGEgY2xpZW50IHRoYXQgb25seSBzdXBwb3J0cyBEU08gb3ZlciBRVUlDLCB0aGV5 IGFyZSBib3RoIGNvbXBsaWFudCB3aXRoIHRoZSBkcmFmdCwgYnV0IHRoZXkgY2Fubm90IGNvbW11 bmljYXRlIHdpdGggZWFjaCBvdGhlci4gVG8gYXZvaWQgdGhpcywgSSBzdWdnZXN0IHRoYXQgdGhp cyBkcmFmdCBvbmx5IHN1cHBvcnRzIFRMUyAoYW5kIHBvc3NpYmx5IFRDUCksIGFuZCBzdXBwb3J0 aW5nIERTTyBvbiBhbnkgb3RoZXIgdW5kZXJseWluZyBwcm90b2NvbCB3b3VsZCByZXF1aXJlIGEg bmV3IGRvY3VtZW50Lg0KDQpJIHRoaW5rIEkndmUgaGVhcmQgb3RoZXIgc3VnZ2VzdGlvbnMgdGhh dCB3ZSBzaG91bGQgZW51bWVyYXRlIHdoaWNoIHByb3RvY29scyBhcmUgc3VwcG9ydGVkIGV4cGxp Y2l0bHksIGJ1dCBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYSByZXF1aXJlbWVudCB0byBzdXBwb3J0 IERTTyBvdmVyIGFueXRoaW5nLiAgIFdlJ3JlIGp1c3QgZGVzY3JpYmluZyBhIG5ldyBETlMgbWVz c2FnZSB0eXBlIHRoYXQgY2FuIGJlIHVzZWQgd2l0aCBhbnkgY29ubmVjdGlvbi1vcmllbnRlZCBw cm90b2NvbC4NCg0KSmFuOg0KVXBvbiBmdXJ0aGVyIHJldmlldywgSSBhZ3JlZS4NCg0KWW91IGRp ZG4ndCBhbnN3ZXIgbXkgdGhpcmQgcXVlc3Rpb246DQoNCkFsc28sIGRvIHlvdSB0aGluayB0aGF0 IEROUy1vdmVyLVRDUCBzaG91bGQgYmUgZm9ybWFsbHkgZGVwcmVjYXRlZD8gICBJZiBzbywgcGVy aGFwcyB0aGF0J3MgdGhlIHJpZ2h0IHdheSB0byBhZGRyZXNzIHRoaXMuICAgSWYgbm90LCBjYW4g eW91IHNheSB3aHkgRFNPIGlzIHNwZWNpYWwgYW5kIHJlcXVpcmVzIFRMUywgd2hlbiBETlMtb3Zl ci1UQ1AgZG9lcyBub3Q/DQoNCklzIGlzIHRoYXQgeW91IHdhbnQgdG8gbWFrZSBEU08tb3Zlci1U TFMgTVRJIGFuZCBEU08tb3Zlci1UQ1Agb3B0aW9uYWw/DQoNCkphbjoNCkl0IHdvdWxkIGJlIG5p Y2UgaWYgd2UgY291bGQgbWFrZSBzdGVwcyB0b3dhcmRzIG1vcmUgc2VjdXJlIEROUyBjb21tdW5p Y2F0aW9ucywgYW5kIHNpbmNlIERTTyByZXF1aXJlcyBuZXcgY2xpZW50IGNvZGUsIGl0IGNvdWxk IGJlIGEgd2F5IG9mIG1vdmluZyBpbiB0aGF0IGRpcmVjdGlvbi4gSeKAmW0gbm90IHJlYWR5IHRv IGRlcHJlY2F0ZSBETlMtb3Zlci1UQ1AsIHRoZXJlIGFyZSBwcm9iYWJseSB0b28gbWFueSBleGlz dGluZyBjbGllbnRzIGFuZCBzZXJ2ZXJzIGRlcGxveWVkIHRvIHN0YXJ0IHRoYXQgcHJvY2Vzcy4g T24gdGhlIG90aGVyIGhhbmQsIGlmIHdlIHdhbnQgdG8gaW1wcm92ZSBjb21tdW5pY2F0aW9ucyBz ZWN1cml0eSwgaXQgbWlnaHQgYmUgZ29vZCB0byBmaW5kIHdheXMgdGhhdCBzdHJvbmdseSBlbmNv dXJhZ2UgaW1wbGVtZW50ZXJzIGluIG91ciBzcGFjZSB0byBhZG9wdCBzZWN1cmUgcHJvdG9jb2xz LCBhbmQgbWFraW5nIG5ldyBmZWF0dXJlcyBzZWN1cmUgaXMgYSB3YXkgdG8gZG8gdGhhdC4gU28s IGl04oCZcyBub3QgdGhhdCBEU08gaXMgc3BlY2lhbCwgYnV0IEl04oCZcyBhbiBvcHBvcnR1bml0 eSB0byBpbXByb3ZlIEROUyBzZWN1cml0eS4gVGhhdOKAmXMgd2h5IEkgd291bGQgcHJlZmVyIHRo ZSBkcmFmdCB0byByZXF1aXJlIFRMUy4gSWYgdGhlIFdHIGRpc2FncmVlcywgc28gYmUgaXQuDQoN ClJlZ2FyZHMsDQoNCkphbi4NCg0K --_000_3F61D530DD2440A3B6C8C6EC7936784Eciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <198FF37CD24EA7449760E51E0131A8AC@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglw YW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ bXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0 ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFRlZCw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXIgcG9uZGVyaW5nIHlvdXIgcmVzcG9uc2UsIG15IGNvbW1l bnRzIGFyZSBpbmxpbmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UZWQg TGVtb24gJmx0O21lbGxvbkBmdWd1ZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2Rh eSwgRmVicnVhcnkgMTQsIDIwMTggYXQgNjoxMyBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7SmFu IEtvbWlzc2FyIChqa29taXNzYSkmcXVvdDsgJmx0O2prb21pc3NhQGNpc2NvLmNvbSZndDs8YnI+ DQo8Yj5DYzogPC9iPlBhdWwgSG9mZm1hbiAmbHQ7cGF1bC5ob2ZmbWFuQHZwbmMub3JnJmd0Oywg ZG5zb3AgJmx0O2Ruc29wQGlldGYub3JnJmd0OywgJnF1b3Q7ZG5zc2RAaWV0Zi5vcmcmcXVvdDsg Jmx0O2Ruc3NkQGlldGYub3JnJmd0OywgJnF1b3Q7ZG9oQGlldGYub3JnJnF1b3Q7ICZsdDtkb2hA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbZG5zc2RdIFtETlNPUF0gV29y a2luZyBHcm91cCBMYXN0IENhbGwgLSBkcmFmdC1pZXRmLWRuc29wLXNlc3Npb24tc2lnbmFsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+T24gRmViIDE0LCAy MDE4LCBhdCA2OjA2IFBNLCBKYW4gS29taXNzYXIgKGprb21pc3NhKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmprb21pc3NhQGNpc2NvLmNvbSI+amtvbWlzc2FAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkN1cnJlbnRseSwgdGhlcmUgYXJlIG9ubHkg cGxhbnMgZm9yIERQTiwgYW5kIHRoYXQgd291bGQgZm9yY2UgZXZlcnkgY29ubmVjdGlvbiB0byBi ZSBUTFMuIEhvd2V2ZXIsIGlmIGEgZnV0dXJlIHByb3RvY29sIOKAnFotb3Zlci1EU0/igJ0gZG9l cyBub3QgcmVxdWlyZSBUTFMsIGl0IGlzIHBvc3NpYmxlIHRoYXQgYSBjbGllbnQgd291bGQgY3Jl YXRlIGEgVENQIGNvbm5lY3Rpb24NCiBmb3IgWiBhbmQgbGF0ZXIgd291bGQgd2FudCB0byBzZW5k IERQTiBvcGVyYXRpb24gdG8gdGhlIHNhbWUgc2VydmVyLiBOb3RlIHRoYXQgdGhlIERTTyBjbGll bnQgbWF5IHJlcHJlc2VudCBhIHNpbmdsZSBjb21wdXRlciwgd2hpbGUgdGhlIFogYW5kIERQTiBy ZXF1ZXN0cyByZXByZXNlbnQgYXBwbGljYXRpb25zIG9uIHRoYXQgY29tcHV0ZXIgdGhhdCBpbXBs aWNpdGx5IGRlcGVuZCBvbiB0aG9zZSB0d28gcHJvdG9jb2xzLiBJIGd1ZXNzIGEgbmV3DQogY29u bmVjdGlvbiBjb3VsZCBiZSBjcmVhdGVkLCBidXQgaXQgd291bGQgYmUgYmV0dGVyIGlmIG5vdCBu ZWNlc3NhcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPkhtLCBpcyB0aGF0IHJlYWxseSB0cnVlPyAmbmJzcDsgV2hhdCBpcyB0 aGUgc2NlbmFyaW8gdGhhdCB5b3UgZW52aXNpb24gaGVyZT8gJm5ic3A7TGlrZSwgd2hlbiB3b3Vs ZCB0aGlzIGFjdHVhbGx5IGhhcHBlbj8gJm5ic3A7IFdoYXQncyB0aGUgY2xpZW50IHRoYXQncyBt YWtpbmcgdGhlIGNvbm5lY3Rpb24/ICZuYnNwOyBIb3cgaXMgaXQgdGhhdCBpdCBpcyB0aGUgc2Ft ZSBjbGllbnQgdGhhdCdzIGRvaW5nDQogRFBOPyAmbmJzcDsgSWYgaXQgaXMgY29uZmlndXJlZCB0 byBzdXBwb3J0IFRMUywgd2h5IGlzbid0IGl0IGRlZmF1bHRpbmcgdG8gdGhhdD88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFuOjxicj4NCkkgd2FzIGltYWdpbmluZyBh IHNpbmdsZSBvcGVyYXRpbmcgc3lzdGVtIHNlcnZpY2UgcGVyZm9ybWluZyBhbGwgRFNPIGJhc2Vk IG9wZXJhdGlvbnMgb24gYmVoYWxmIG9mIHZhcmlvdXMgYXBwbGljYXRpb25zLCBidXQgaXQgd291 bGQgcHJvYmFibHkgbW9yZSBsaWtlbHkgYmUgb25lIHNlcnZpY2UgZm9yIGFsbCBEUE4gdXNlcnMg YW5kIGFub3RoZXIgZm9yIHByb3RvY29sIFogdXNlcnMsIGFuZCB0aGUgZXhpc3Rpbmcgc3R1YiBy ZXNvbHZlciBmb3INCiB0cmFkaXRpb25hbCBETlMgcXVlcmllcy4gQW5kIGluIHRoYXQgY2FzZSwg dGhlcmUgd291bGQgYmUgbm8gcmVhc29uIHRvIGZvcmNlIGFsbCBEU08gYmFzZWQgb3BlcmF0aW9u cyBpbnRvIFRMUy4gSSBjYW4gbGl2ZSB3aXRoIHRoYXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDtUaGUgaW50ZXJvcCBpc3N1 ZSBpcyByZWxhdGVkIHRvIHNlY3Rpb24gNC4xIHRoYXQgc2F5cyB0aGF0IGFueSBzZXNzaW9uIGJh c2VkIHByb3RvY29sIGlzIHN1aXRhYmxlIGZvciBEU08uIElmIHlvdSBtYWtlIGEgc2VydmVyIHRo YXQgb25seSBzdXBwb3J0cyBEU08gb3ZlciBUQ1AgYW5kIEkgbWFrZSBhIGNsaWVudCB0aGF0IG9u bHkgc3VwcG9ydHMgRFNPIG92ZXIgUVVJQywNCiB0aGV5IGFyZSBib3RoIGNvbXBsaWFudCB3aXRo IHRoZSBkcmFmdCwgYnV0IHRoZXkgY2Fubm90IGNvbW11bmljYXRlIHdpdGggZWFjaCBvdGhlci4g VG8gYXZvaWQgdGhpcywgSSBzdWdnZXN0IHRoYXQgdGhpcyBkcmFmdCBvbmx5IHN1cHBvcnRzIFRM UyAoYW5kIHBvc3NpYmx5IFRDUCksIGFuZCBzdXBwb3J0aW5nIERTTyBvbiBhbnkgb3RoZXIgdW5k ZXJseWluZyBwcm90b2NvbCB3b3VsZCByZXF1aXJlIGEgbmV3IGRvY3VtZW50LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SSB0aGluayBJJ3Zl IGhlYXJkIG90aGVyIHN1Z2dlc3Rpb25zIHRoYXQgd2Ugc2hvdWxkIGVudW1lcmF0ZSB3aGljaCBw cm90b2NvbHMgYXJlIHN1cHBvcnRlZCBleHBsaWNpdGx5LCBidXQgSSBkb24ndCB0aGluayB0aGVy ZSdzIGEgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBEU08gb3ZlciBhbnl0aGluZy4gJm5ic3A7IFdl J3JlIGp1c3QgZGVzY3JpYmluZyBhIG5ldyBETlMgbWVzc2FnZQ0KIHR5cGUgdGhhdCBjYW4gYmUg dXNlZCB3aXRoIGFueSBjb25uZWN0aW9uLW9yaWVudGVkIHByb3RvY29sLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KYW46PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5VcG9uIGZ1cnRoZXIgcmV2aWV3LCBJIGFncmVlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+WW91IGRpZG4n dCBhbnN3ZXIgbXkgdGhpcmQgcXVlc3Rpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkFsc28sIGRvIHlvdSB0aGluayB0aGF0 IEROUy1vdmVyLVRDUCBzaG91bGQgYmUgZm9ybWFsbHkgZGVwcmVjYXRlZD8gJm5ic3A7IElmIHNv LCBwZXJoYXBzIHRoYXQncyB0aGUgcmlnaHQgd2F5IHRvIGFkZHJlc3MgdGhpcy4gJm5ic3A7IElm IG5vdCwgY2FuIHlvdSBzYXkgd2h5IERTTyBpcyBzcGVjaWFsIGFuZCByZXF1aXJlcyBUTFMsIHdo ZW4gRE5TLW92ZXItVENQIGRvZXMgbm90PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JcyBpcyB0aGF0IHlvdSB3YW50IHRvIG1ha2UgRFNPLW92ZXIt VExTIE1USSBhbmQgRFNPLW92ZXItVENQIG9wdGlvbmFsPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5KYW46PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCB3b3VsZCBiZSBuaWNlIGlmIHdlIGNvdWxkIG1ha2Ugc3RlcHMgdG93YXJkcyBtb3JlIHNl Y3VyZSBETlMgY29tbXVuaWNhdGlvbnMsIGFuZCBzaW5jZSBEU08gcmVxdWlyZXMgbmV3IGNsaWVu dCBjb2RlLCBpdCBjb3VsZCBiZSBhIHdheSBvZiBtb3ZpbmcgaW4gdGhhdCBkaXJlY3Rpb24uIEni gJltIG5vdCByZWFkeSB0byBkZXByZWNhdGUgRE5TLW92ZXItVENQLCB0aGVyZSBhcmUgcHJvYmFi bHkgdG9vIG1hbnkNCiBleGlzdGluZyBjbGllbnRzIGFuZCBzZXJ2ZXJzIGRlcGxveWVkIHRvIHN0 YXJ0IHRoYXQgcHJvY2Vzcy4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHdlIHdhbnQgdG8gaW1wcm92 ZSBjb21tdW5pY2F0aW9ucyBzZWN1cml0eSwgaXQgbWlnaHQgYmUgZ29vZCB0byBmaW5kIHdheXMg dGhhdCBzdHJvbmdseSBlbmNvdXJhZ2UgaW1wbGVtZW50ZXJzIGluIG91ciBzcGFjZSB0byBhZG9w dCBzZWN1cmUgcHJvdG9jb2xzLCBhbmQgbWFraW5nIG5ldyBmZWF0dXJlcw0KIHNlY3VyZSBpcyBh IHdheSB0byBkbyB0aGF0LiBTbywgaXTigJlzIG5vdCB0aGF0IERTTyBpcyBzcGVjaWFsLCBidXQg SXTigJlzIGFuIG9wcG9ydHVuaXR5IHRvIGltcHJvdmUgRE5TIHNlY3VyaXR5LiBUaGF04oCZcyB3 aHkgSSB3b3VsZCBwcmVmZXIgdGhlIGRyYWZ0IHRvIHJlcXVpcmUgVExTLiBJZiB0aGUgV0cgZGlz YWdyZWVzLCBzbyBiZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SmFuLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_3F61D530DD2440A3B6C8C6EC7936784Eciscocom_-- From nobody Thu Feb 15 15:36:54 2018 Return-Path: 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 904D01243F3 for ; Thu, 15 Feb 2018 15:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=fugue-com.20150623.gappssmtp.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 55rBXQPlmXaB for ; Thu, 15 Feb 2018 15:36:37 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCBA127419 for ; Thu, 15 Feb 2018 15:36:35 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id n198so1800710qke.7 for ; Thu, 15 Feb 2018 15:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0yaGdAfOHbPLrs65bAX2XuzMgQaBTAFEMFd7jQ0E74M=; b=1KxMT45LKsxKpJ0pwPbPLrvbeA9rJcvJ87kH/YEsaiq81hUNUhDxlHrZerLKYNYYeO EWE9WylBy/ASXB1DJRke3AjSb/CjNrWPBDoFGsBnAW0WsorOmsOWsJLj0FpbtK7S3gTk iSWVG7foIqSlBSmt5CsTJOuCG+hyM/7A1H40IfGT5qn+Zu7qbX2LL5FL3Zovm/EvjbMh Lod7ZDYyfp9dpN4jzSnCtljE59/0fli/HYaGIaOgD4qQ74uPc+zDlLsC8s6Yw29Ne6uc GZOIpHJhYokD/ZwUlc3eX+Jm6LmO3KweJGiVxtEE8op8CYl3cRJTbeOVPv7CjVnnJ9u6 iagA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0yaGdAfOHbPLrs65bAX2XuzMgQaBTAFEMFd7jQ0E74M=; b=t3E6Sfp0hA9Hvgl0nENT70MInSUH0nZOeekXz6CApDueR40xCCgfVvsliJ7TQ459HB 7P+d7h+6F/15tw3d/75fAL/JAK1RbO6p+Kp9a7fzuJ92S6mMGuxXJ/lBz9qjO17xIrE7 LDGzAp27/Z+e4SemIN2J+fHnGyJr6tmxVzz/WPNLMLi5JxaoHssfknVsYr2Yh0vmrRZK /zSnoJEsDD5MaCGWemUyEBOGO6RxaBqCBD6I9yFx4ogrVKdqNCZZ7jDyjiUN3uBF06aa cWXFtFl4o8NNbn8Iy75zC4AtY7dTDoThfO0lnyilulpLYapjBSwLHTVvEcYmRM4haPy2 UFQA== X-Gm-Message-State: APf1xPD7NdLTMG3V1jOo4Mbq6q3qEG25kdovh1nw0kcaYxz/UeMeqMPQ TDrb53dRC2ZFgByo1GBsuG+Zbw== X-Google-Smtp-Source: AH8x227z98pmMrQgs8EIv0uRAat7dnUUkpoKgll4hrATmNXMKeMdCosf+VEwILp4m7UfY2u/aFIadQ== X-Received: by 10.55.31.20 with SMTP id f20mr7079721qkf.290.1518737794189; Thu, 15 Feb 2018 15:36:34 -0800 (PST) Received: from cavall.lan (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id l80sm1469620qki.92.2018.02.15.15.36.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 15:36:33 -0800 (PST) From: Ted Lemon Message-Id: <5476EC6A-E6C1-4EFB-9E82-E829C1939E75@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_561A9D11-9ED4-4695-8315-4EE7D0B0284A" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 15 Feb 2018 18:36:31 -0500 In-Reply-To: <3F61D530-DD24-40A3-B6C8-C6EC7936784E@cisco.com> Cc: Paul Hoffman , dnsop , "dnssd@ietf.org" , "doh@ietf.org" To: "Jan Komissar (jkomissa)" References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> <34561144-6844-4E00-90E9-41095A9E14E6@fugue.com> <3F61D530-DD24-40A3-B6C8-C6EC7936784E@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2018 23:36:38 -0000 --Apple-Mail=_561A9D11-9ED4-4695-8315-4EE7D0B0284A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Feb 15, 2018, at 5:34 PM, Jan Komissar (jkomissa) = wrote: > After pondering your response, my comments are inline: Thanks! >> Also, do you think that DNS-over-TCP should be formally deprecated? = If so, perhaps that's the right way to address this. If not, can you = say why DSO is special and requires TLS, when DNS-over-TCP does not? >=20 > =20 > Is is that you want to make DSO-over-TLS MTI and DSO-over-TCP = optional? > =20 > Jan: > It would be nice if we could make steps towards more secure DNS = communications, and since DSO requires new client code, it could be a = way of moving in that direction. I=E2=80=99m not ready to deprecate = DNS-over-TCP, there are probably too many existing clients and servers = deployed to start that process. On the other hand, if we want to improve = communications security, it might be good to find ways that strongly = encourage implementers in our space to adopt secure protocols, and = making new features secure is a way to do that. So, it=E2=80=99s not = that DSO is special, but It=E2=80=99s an opportunity to improve DNS = security. That=E2=80=99s why I would prefer the draft to require TLS. If = the WG disagrees, so be it. Understood. One way in which this certainly makes sense is that = although DNSSEC can be used to authenticate DNS data, DSO data can't = really be validated that way. And we don't have TSIG either. So it's = certainly worth considering. --Apple-Mail=_561A9D11-9ED4-4695-8315-4EE7D0B0284A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Feb 15, 2018, at 5:34 PM, Jan Komissar (jkomissa) <jkomissa@cisco.com> = wrote:
After pondering your = response, my comments are inline:

Thanks!

Also, do you think that DNS-over-TCP should be formally = deprecated?   If so, perhaps that's the right way to address this. =   If not, can you say why DSO is special and requires TLS, when = DNS-over-TCP does not?
 
Is is that you want to make = DSO-over-TLS MTI and DSO-over-TCP optional?
 
Jan:
It would be nice if we could make steps towards more secure = DNS communications, and since DSO requires new client code, it could be = a way of moving in that direction. I=E2=80=99m not ready to deprecate = DNS-over-TCP, there are probably too many existing clients and servers = deployed to start that process. On the other hand, if we want to improve = communications security, it might be good to find ways that strongly = encourage implementers in our space to adopt secure protocols, and = making new features secure is a way to do that. So, it=E2=80=99s not = that DSO is special, but It=E2=80=99s an opportunity to improve DNS = security. That=E2=80=99s why I would prefer the draft to require TLS. If = the WG disagrees, so be it.

Understood.   One way in which this certainly = makes sense is that although DNSSEC can be used to authenticate DNS = data, DSO data can't really be validated that way.   And we don't = have TSIG either.   So it's certainly worth = considering.

= --Apple-Mail=_561A9D11-9ED4-4695-8315-4EE7D0B0284A-- From nobody Fri Feb 16 09:54:16 2018 Return-Path: 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 5B35A129BBF for ; Fri, 16 Feb 2018 09:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zEiGPpC_nwFx for ; Fri, 16 Feb 2018 09:54:12 -0800 (PST) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 6716E127698 for ; Fri, 16 Feb 2018 09:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1518803651; x=2382717251; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=GXbFDTlwFtwTS7T/YjOHhcIldgq6Z2eERppytGs6w9M=; b=ah9wB9iK9jp9f+rQ3If10hhpDl+i/t/vxMC+jPq76Guv6t+wf4uAaZStJIkttKpc kx9EYCukVJPHcBMs4ugNFoKYxMtAx0e19h+1APcgGH21S5e1XgGXab0OCSK5sBxF 2C7+VyoCuMwnIGaeAaQlQSlDq/w4K55waMeHj0+QyFZ8kGi18EEugEDM/QcPrRh4 vdd+OpUkfRbGl6IYA/LvzsjpfCeEksvNCFA3lMwwfVhsEhHJcf3PZGq7/TkAJo8Y vJ4DylAf0OHAsRB8AQ0eRB8EOeeB5nqFgDYZ5tcKW5lZ9Rhsjhl9Zb8KOBCstmUR a7jcjk5oLMWsydLy/sea4A==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id B8.46.11907.3CA178A5; Fri, 16 Feb 2018 09:54:11 -0800 (PST) X-AuditID: 11ab0216-325f09e000002e83-1a-5a871ac3f053 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay6.apple.com (Apple SCV relay) with SMTP id 38.DE.23861.2CA178A5; Fri, 16 Feb 2018 09:54:10 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3nRXvu09hVhRghBStcELxw)" Received: from [17.234.68.209] (unknown [17.234.68.209]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4900MJF8EA4020@nwk-mmpp-sz10.apple.com>; Fri, 16 Feb 2018 09:54:10 -0800 (PST) Sender: dschinazi@apple.com From: David Schinazi Message-id: <9AC49151-EB79-4AB8-B04E-D5213007784F@apple.com> Date: Fri, 16 Feb 2018 09:54:09 -0800 In-reply-to: Cc: dnsop , dnssd@ietf.org, doh@ietf.org To: tjw ietf References: X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUi2FAYpXtYqj3KYMpjSYu7by6zWLxfOovR 4trdi2wW09o2MzuweOycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGYtX/GEtWCJXcfThVvYG xuNSXYycHBICJhKPn5xl7mLk4hASWMMkcf/9NFaYxNVvLxkhEocYJTr+b2QBSfAKCEr8mHwP zGYWCJO49ekOO0TRRCaJgxcPM4EkhAWkJbou3AWaxMHBJqAlcWCNEUSvjcT7oytYIEr8JDqb 2sBsFgFViRWNH9lBbE6BYIn+/8cZIeZbSLQsmg8WFxFQlLj/9i9YvZBAgERzx1qoQ5Ukpn+/ zQZyg4TACjaJb/0L2CcwCs1CcussJLdC2FoS3x+1AsU5gGx5iYPnZSHCmhLP7n2CKtGWePLu AusCRrZVjMK5iZk5upl5RkZ6iQUFOal6yfm5mxhBEbKaSWwH473XhocYBTgYlXh4Ox62RQmx JpYVV+YeYpTmYFES5732vDFKSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2P41Zntj17uvnyt es2rhvrbTJ9mrpLxLH+kaKq11+boJ71Q3r5urn87m43KxHKelN1Ye/PtpndLNx4QtPtcpKnQ +Gr/BFufF0kX5LScZA1eiHVK67QuPc9dfDG6+uGdM2GLGQ5L/uOba7wsP/vbvnDdT5xrFF7t ixUpt9pVy6dRIPXeQOCP13IlluKMREMt5qLiRACbCo0DcQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FBcpXtIqj3KoKfXyuLum8ssFu+XzmK0 uHb3IpvFtLbNzA4sHjtn3WX3WLLkJ1MAUxSXTUpqTmZZapG+XQJXxuIVf1gLlshVHH24lb2B 8bhUFyMnh4SAicTVby8Zuxi5OIQEDjFKdPzfyAKS4BUQlPgx+R6YzSwQJnHr0x12iKKJTBIH Lx5mAkkIC0hLdF24y9rFyMHBJqAlcWCNEUSvjcT7oytYIEr8JDqb2sBsFgFViRWNH9lBbE6B YIn+/8cZIeZbSLQsmg8WFxFQlLj/9i9YvZBAgERzx1pWiEOVJKZ/v802gZF/FpLzZiE5D8LW kvj+qBUozgFky0scPC8LEdaUeHbvE1SJtsSTdxdYFzCyrWIUKErNSaw000ssKMhJ1UvOz93E CA7nwqgdjA3LrQ4xCnAwKvHwPnjcFiXEmlhWXJkLDCMOZiUR3ucgId6UxMqq1KL8+KLSnNTi Q4zSHCxK4rxPg1uihATSE0tSs1NTC1KLYLJMHJxSDYzJu8OTwrXfmX8q2Jx9raXdMuHLq8IJ ptsmHnf5Y2n99fGU9LTFN1i43r5dueup76qbv562P5jcP2M19wavG2c1JkcVPD7+75SW13wn 44vLZZ/UeNR6VDA0hvfGRbGt27lRh3kbr//CcC8peVHTxsDpwae9RT4vP7uQbUdk1DbN6YZh wW/NZ4UpsRRnJBpqMRcVJwIAhsVDX2MCAAA= Archived-At: Subject: Re: [Doh] [dnssd] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2018 17:54:14 -0000 --Boundary_(ID_3nRXvu09hVhRghBStcELxw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi, (chair hat off) I've reviewed draft-ietf-dnsop-session-signal-04 and -05 and think -05 is ready to move forward. Draft -05 addresses the points I raised on -04 and in my opinion makes the document clearer. Thanks, David Schinazi > On Feb 1, 2018, at 11:14, tjw ietf wrote: > > > This starts a Working Group Last Call for draft-ietf-dnsop-session-signal > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ > > Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons. > > We are doing a three week Working Group Last Call process, and we're cross posting to a few groups where we hope to receive some strong reviews. > > This WGLC ends at midnight, 22 February 2018. > > thanks > Tim/suzanne > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Boundary_(ID_3nRXvu09hVhRghBStcELxw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Hi,

(chair = hat off)

I've = reviewed draft-ietf-dnsop-session-signal-04 and -05 and think -05 = is ready to move forward.
Draft -05 addresses the = points I raised on -04 and in my opinion makes the document = clearer.

Thanks,
David Schinazi


On Feb 1, 2018, at 11:14, tjw ietf <tjw.ietf@gmail.com> = wrote:


This starts a Working Group Last Call = for draft-ietf-dnsop-session-signal

Current versions of the draft is = available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signa= l/

Please = review the draft and offer relevant comments. Also, if someone feels the = document is *not* ready for publication, please speak out with your = reasons.

We = are doing a three week Working Group Last Call process, and we're cross = posting to a few groups where we hope to receive some strong = reviews. 

This WGLC ends at midnight, 22 February 2018.

thanks
Tim/suzanne
_______________________________________________
dnssd = mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Boundary_(ID_3nRXvu09hVhRghBStcELxw)-- From nobody Wed Feb 21 10:39:28 2018 Return-Path: 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 156AF124BAC for ; Wed, 21 Feb 2018 10:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 l4Hosomx53mm for ; Wed, 21 Feb 2018 10:39:21 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 D1F0E126CC7 for ; Wed, 21 Feb 2018 10:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1519238360; x=2383151960; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wr+Q+pTHR18PhpmaO1gR4lH0LomQ8hAu1UtrhIObbSE=; b=cTvbvukh5sBWnhVYTegNwmVH83f9BAl1ZDUAOki1vVId6/uoQ9nQhlRmZrWM9P6w lUfKjY2kxzBkBNCNnPbHBxMi3Fc5os1ls8U/vlg48owzmxSibUl9YJfA/doIW9A4 T/1kCH0MtcPJXwO5MpufjHTH/caAOT1PpG66CXn6IYLWejVQ3fK/MHodgHKDhe63 adhcTetyblkU9oCw1HeU9+d7z0rOFcqDse3b61ENrqeF6hj8rKZaGuJENqZ6F8MX SXVvKfgM04Sq0ZNrBp7QqfG6cfJIb68X54hUVVdEmpGO5txVmmK4nU3cK+ZUND6R rnIV8iFudECEAXk+PunosA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id A7.61.13704.8DCBD8A5; Wed, 21 Feb 2018 10:39:20 -0800 (PST) X-AuditID: 11973e13-efdff70000003588-c9-5a8dbcd83be7 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay6.apple.com (Apple SCV relay) with SMTP id 16.AA.23861.8DCBD8A5; Wed, 21 Feb 2018 10:39:20 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.234.51.43] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4I000O9JTHRD60@nwk-mmpp-sz09.apple.com>; Wed, 21 Feb 2018 10:39:20 -0800 (PST) Sender: cheshire@apple.com From: Stuart Cheshire Content-transfer-encoding: quoted-printable Date: Wed, 21 Feb 2018 10:39:15 -0800 References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> To: "Jan Komissar (jkomissa)" , Ted Lemon , "dnssd@ietf.org" , dnsop , "doh@ietf.org" , Paul Hoffman In-reply-to: <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> Message-id: <8225F726-323C-4078-9CB5-C6672025494B@apple.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUi2FAYpXtjT2+Uwb2VohZ331xmsXi/dBaj xbW7F9ksGpctZbJ4s+YIk8Wt9V9YHdg8pvzeyOrRdGEZu8eSJT+ZPD7PvsocwBLFZZOSmpNZ llqkb5fAldE+oYet4ApbxfH17A2MS1m7GDk5JARMJI70/WHsYuTiEBJYzSSxt/EJcxcjB1ji 16lyiPhBRokfD1YygjTwCghK/Jh8jwWkhllAXWLKlFyQsJDAF0aJW3dkQGxhASmJVys/M4PY bAJaEi8+X2EDsZkFtCWevLvAClETIXHuyEl2kDEsAqoSd6+xQKyayyTR+PE5O4gjInCNUeLr +g/sIA2cArYSTVMusEPcYCNx8/81NogHlCSmf78NZS9hkzi1qXgCo9AsJKfOQjh1FpIzFjAy r2IUyk3MzNHNzDPVSywoyEnVS87P3cQICvzpdsI7GE+vsjrEKMDBqMTDu6GsN0qINbGsuDL3 EKM0B4uSOK/fzp4oIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxbjqhm9+U6BXe+40u47KjG +G7bn6dneC7Nal1z6me/Sq+vW8mhqHeTnp1uFMssnutzZem9CaFmLVLX61ZsWfdi3jU+o2VN L36d5nv0WnCl0sm7F3oF/92p+djGsXmT/6uprg6Ta2Y+yll68aXz/E3hdfF/RNbM/q5glPlU 6OSMhnfzGwxl9aU7lFiKMxINtZiLihMBlSXiGV0CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAcoHtjT2+UwbzJQhZ331xmsXi/dBaj xbW7F9ksGpctZbJ4s+YIk8Wt9V9YHdg8pvzeyOrRdGEZu8eSJT+ZPD7PvsocwBLFZZOSmpNZ llqkb5fAldE+oYet4ApbxfH17A2MS1m7GDk4JARMJH6dKu9i5OIQEjjIKPHjwUrGLkZODl4B QYkfk++xgNQwC6hLTJmSCxIWEvjCKHHrjgyILSwgJfFq5WdmEJtNQEvixecrbCA2s4C2xJN3 F1ghaiIkzh05yQ4yhkVAVeLuNRaIVXOZJBo/PmcHcUQErjFKfF3/gR2kgVPAVqJpygV2iBts JG7+vwY2VEJASWL699tsExj5ZyE5bxbCebOQrF7AyLyKUaAoNSex0kwvsaAgJ1UvOT93EyM4 VAujdjA2LLc6xCjAwajEw7uhrDdKiDWxrLgy9xCjBAezkgjviQSgEG9KYmVValF+fFFpTmrx IUZpDhYlcd5GD6CUQHpiSWp2ampBahFMlomDU6qB0XMt284Xkw8s0dH83Kl3lmuHflPJ+jkO X9z4lvRffPlpjmbis+eaM9rrvh9yYKp/FFD6csrp6x/LJlvMqv3tsfOk7NOL5/T+95cpbeRr 2+uwkbFBWHyS+05fvnO1XgdlLh4+5L/c2D96X3eVirBXtgdH47nAyN25xs8TduuGquRMDTvx 1YN7nRJLcUaioRZzUXEiAPXc+I1RAgAA Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:39:22 -0000 I think Jan makes a good point. Suppose there=E2=80=99s a server that supports DNS over TCP, and DSO = signaling, and Push Notifications, and DNS Update, and maybe other = things. Now suppose a client connects to that server. The server doesn=E2=80=99t = know what that client is going to do. The client may do queries over = TCP, or DNS updates. It may do queries over TCP and use the DSO = signaling to request a longer inactivity timeout. It may request Push = Notifications (which are currently specified to require TLS). It may do = all of those. When the server receives an incoming TCP connection request from a = client, what are the first bytes received over that TCP connection? Are = they a DNS header and message body? Are they a TLS handshake message? = Can it be either? How does the server know? Stuart Cheshire From nobody Wed Feb 21 10:50:36 2018 Return-Path: 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 D97E9129C59 for ; Wed, 21 Feb 2018 10:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 mPQRMLx_T6D9 for ; Wed, 21 Feb 2018 10:50:14 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEED12D961 for ; Wed, 21 Feb 2018 10:50:06 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v90so3200657qte.12 for ; Wed, 21 Feb 2018 10:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J868/+Sec3ctRcZ4ExhQns6ABafSqjVuH8036kuxLTU=; b=QnUqGq/lWKiGrchXhCVCAZRKl7It0Hl397GWK8SpRM78+Nk2rCiZumiuwydiIU+L6M LxuP27OrpESi9JYk1sikIloruBr0c+SOeBcjI7I185bEs0qxsHSjPdrwttHbL7JnileB grht6FAjFCpDp9gDDcSZWQhU2eUi51kqH9gkmpLWrN88T9ImbLndsxv3Ky+uvTQt+gio +pn+Ox7097Ku3Y5lOBFnvIdcqyuPykPC+mnXIiyp3PN3alHFpWbwNN1c8oFInztWUEiI 9NT8/UXyHLG0vwdQXHEz4mUs7Jkp3UyPN8PLW6nqufaMUxUiO1g8C6u7I5lJ029Qdi+d RfdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=J868/+Sec3ctRcZ4ExhQns6ABafSqjVuH8036kuxLTU=; b=QjHfTeIsUxFYO5QMiQ3Xm9ZcaTCGC15Y8AUSdUeG1O7Rjk1qmxS6fwE/irGN1iheCp YlJvdvGsu8OFQxXi8iXLSKWb4GgPqNKYkr79uph/qQQ1xsR6EbupN2gtKcbDMtZKW79j B4s8v6jZTqTGxfU2KVj+vFdsUFENqUalKoaJN6l3AhZVLvnF2pvu8GGXkSIUlCdo0OQ7 iqsohbo8I1WzCAMQjTX6m0Kx0bDpV8pm19BLvaL4wp+Xu5rxhGPpYubt4Fr/dWQKycJu 44F4GEtX1dm2nfet2WNgjRGSVwwytanfp3Vr9vMiXdRLwdWijz/wXGWXBweXha1VTCFT L7aQ== X-Gm-Message-State: APf1xPAh54AuDB8o3FG3deV2dWjmJYlWdvsLP5ljHgOMxlwJy3vG8Kud uDsrrJhU5Tt+lZQPViLDOOXJVvijauY= X-Google-Smtp-Source: AH8x224Sf0eIXwcU5qrykdhAmZtEhFliNwdvETCiXJr2s3usx+6BwjLpU09KEmVWNkNQodeRAud39w== X-Received: by 10.237.47.165 with SMTP id m34mr7089387qtd.51.1519239005408; Wed, 21 Feb 2018 10:50:05 -0800 (PST) Received: from [192.168.1.147] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id q34sm5666619qkh.73.2018.02.21.10.50.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Feb 2018 10:50:04 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPad Mail (15A372) In-Reply-To: <8225F726-323C-4078-9CB5-C6672025494B@apple.com> Date: Wed, 21 Feb 2018 13:50:03 -0500 Cc: "Jan Komissar (jkomissa)" , "dnssd@ietf.org" , dnsop , "doh@ietf.org" , Paul Hoffman Content-Transfer-Encoding: quoted-printable Message-Id: References: <91E3DCED-7A40-4454-9809-EBF68E942DB0@vpnc.org> <02FF7C21-3421-40C5-A530-BE1D814237B2@cisco.com> <976312C8-4424-4642-A150-21F25FB137EE@fugue.com> <5AFBBFBE-CF5A-4F7A-9AC9-F7E0040BBABD@cisco.com> <8225F726-323C-4078-9CB5-C6672025494B@apple.com> To: Stuart Cheshire Archived-At: Subject: Re: [Doh] [dnssd] [DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Feb 2018 18:50:23 -0000 On Feb 21, 2018, at 1:39 PM, Stuart Cheshire wrote: > I think Jan makes a good point. >=20 > Suppose there=E2=80=99s a server that supports DNS over TCP, and DSO signa= ling, and Push Notifications, and DNS Update, and maybe other things. >=20 > Now suppose a client connects to that server. The server doesn=E2=80=99t k= now what that client is going to do. The client may do queries over TCP, or D= NS updates. It may do queries over TCP and use the DSO signaling to request a= longer inactivity timeout. It may request Push Notifications (which are cur= rently specified to require TLS). It may do all of those. >=20 > When the server receives an incoming TCP connection request from a client,= what are the first bytes received over that TCP connection? Are they a DNS h= eader and message body? Are they a TLS handshake message? Can it be either? H= ow does the server know? Doesn=E2=80=99t dns over tls use a different port?= From nobody Tue Feb 27 15:14:39 2018 Return-Path: X-Original-To: doh@ietf.org Delivered-To: doh@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D5D12E91F; Tue, 27 Feb 2018 15:11:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: doh@ietf.org, adam@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977307334.5200.10410664230080416387.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:13 -0800 Archived-At: Subject: [Doh] doh - Requested session has been scheduled for IETF 101 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2018 23:11:13 -0000 Dear Benjamin Schwartz, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. doh Session 1 (1:30:00) Thursday, Afternoon Session I 1330-1530 Room Name: Blenheim size: 200 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: DNS Over HTTPS Area Name: Applications and Real-Time Area Session Requester: Benjamin Schwartz Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: httpbis dprive dnssd dnsop Second Priority: homenet hrpc v6ops quic capport People who must be present: Paul E. Hoffman Adam Roach Patrick McManus Benjamin M. Schwartz David C Lawrence Paul E. Hoffman Adam Roach Patrick McManus Benjamin M. Schwartz David C Lawrence Resources Requested: Special Requests: I think 45 minutes is probably enough. ---------------------------------------------------------