From nobody Mon Jul 9 19:49:37 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 C89F71310EA; Mon, 9 Jul 2018 19:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KfgTZYcMkAzA; Mon, 9 Jul 2018 19:49:26 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id C47081310ED; Mon, 9 Jul 2018 19:49:26 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 12C9D3A050; Mon, 9 Jul 2018 22:49:26 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id s198-v6so39781256oih.11; Mon, 09 Jul 2018 19:49:26 -0700 (PDT) X-Gm-Message-State: APt69E2PXvlg6nvwDBpXKzTjDwTSUXUG7RfATuebEoj3vkoeWPjTvBSj Oq0QBsXOLls+aPF0ebOh18/SGd1pPPeQv5zPViw= X-Google-Smtp-Source: AAOMgpffJRnEVtif8+cFsl4FKNUPJTA+LEwMl/QGr0LUV51oilorMcOyIo28iD/WwBekvMa9HXZF6rHRmAZdoRXM9qY= X-Received: by 2002:aca:e80c:: with SMTP id f12-v6mr27287137oih.38.1531190965716; Mon, 09 Jul 2018 19:49:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 19:49:25 -0700 (PDT) From: Patrick McManus Date: Mon, 9 Jul 2018 22:49:25 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , driu@ietf.org, HTTP Working Group , dnsop Content-Type: multipart/alternative; boundary="000000000000984e2405709c2d48" Archived-At: Subject: [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:49:29 -0000 --000000000000984e2405709c2d48 Content-Type: text/plain; charset="UTF-8" Hi All, I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in Montreal. We have often talked about the benefits and concerns of DNS information obtained from sources that are, shall we say, less globally trusted than a recursive a resolver. The central use case is DoH when pushed from an endpoint that isn't a recursive resolver but there have been other proposals. For example www.example.com pushes you a AAAA record for img1.example.com. Should you use it? What if it is for img1.img-example.com ? Do the relationship between these domains matter? What kind of relationship (i.e. it could be a domain relationship, or in the context of a browser it might be a first-party tab like relationship, etc..)? What are the implications of poison? Trackers? Privacy of requests never made? Speed? Competitive shenanigans or DoS attacks? This was out of scope for DoH. *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to 17:30 on Monday July 16th.* This is a meeting of interested folks looking to see if we can agree on next steps - we're not going to work out the details (nor should a side meeting try and do so). so we'll have a tight agenda that I suggest organizaing as follows: 1] What forms of transport could be in scope? HTTP/2 push is one such vector, but I've heard others. Spray paint for example. 2] What needs to be considered when using such data? (signatures? scope? etc?) 3] Who are the stakeholders for 1 + 2? 4] Is there enough interest to explore further? Next steps as output I hope you can come! -Patrick --000000000000984e2405709c2d48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I am organizing an ad-hoc Side = Meeting regarding 'Resolverless DNS' in Montreal.

We have often talked about the benefits and concerns of DNS informa= tion obtained from sources that are, shall we say, less globally trusted th= an a recursive a resolver. The central use case is DoH when pushed from an = endpoint that isn't a recursive resolver but there have been other prop= osals.

For example www.example.com pushes you a AAAA record for img1.example.com. Sho= uld you use it? What if it is for img1.img-example.com ? Do the relationship between the= se domains matter? What kind of relationship (i.e. it could be a domain rel= ationship, or in the context of a browser it might be a first-party tab lik= e relationship, etc..)? What are the implications of poison? Trackers? Priv= acy of requests never made? Speed? Competitive shenanigans or DoS attacks?<= /div>

This was out of scope for DoH.

We'll do the meeting over 1 hour in the Dorchester room from 1= 6:30 to 17:30 on Monday July 16th.

This is a m= eeting of interested folks looking to see if we can agree on next steps - w= e're not going to work out the details (nor should a side meeting try a= nd do so). so we'll have a tight agenda that I suggest organizaing as f= ollows:

1] What forms of transport could be in sco= pe? HTTP/2 push is one such vector, but I've heard others. Spray paint = for example.

2] What needs to be considered wh= en using such data? (signatures? scope? etc?)

3] W= ho are the stakeholders for 1 + 2?

4] Is there eno= ugh interest to explore further? Next steps as output

I hope you can come!

-Patrick
--000000000000984e2405709c2d48-- From nobody Mon Jul 9 19: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 2845E130EBC for ; Mon, 9 Jul 2018 19:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-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=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 H6Zq9eT7Sd2O for ; Mon, 9 Jul 2018 19:55:27 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 4B000126F72 for ; Mon, 9 Jul 2018 19:55:27 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id r24-v6so18964699ioh.9 for ; Mon, 09 Jul 2018 19:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hbievmt9Qg7XZ30HuxATmXkHzWVEzkLqH9rZb5dQaWY=; b=dmDee0ECsiSDTlMlZXMB3DVvrtMwOg5fTOJuRP3Tsru/mUDK2ySoKCeVRwywzIhi7g qHMqc0ccmIJSdpOTdGZgUPI5m5njuX1vkm4/MbKXrWgLjLHjoAod8DLYqLJ/uH+rL1Em epOk0jEyurphBXZFpQQcb9ZPYhcdHIe3uQS/Lq4tYLXM+Re5q7iEh06ZxAmybLjP0E6E HqyutDF6Wd6TaneB0GkUOrjpCzDUxnnfmfER7xAHe8lHO7JH+cIzcz54hBmtak4fl/W/ jcktKZFcyr7bKn0GOyNt24iJV9daa9REm/p+D6dREqhz0ZvvgMeHZ+jUSc70/bpThTWK sioQ== 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=hbievmt9Qg7XZ30HuxATmXkHzWVEzkLqH9rZb5dQaWY=; b=mX+6yiQfOAFwnuqgMgKR65fnaBi24InLLq2A9uFt7I3l9W86w29iSpltdQ1KEGaw6X SOeQFQ6K4krjduCYnBd505u0JSDeZogz0y45UDPIQ3TSexHmy3NgWjy9nHdH3HJ3ezks +UzKMa+ZDL4x/qE9N2sC6gc7p42Ywij0t1p0j+OFBjtxaw3AGxwkzvPzSwA3rWq0xc5T tRrCtjfcm3riM+Ju0sxyhZqJtt/pLETC80+t5pJoWbrpX2FhX9odH8qHQp+5MCSUCutJ S3zyF09dD9YR3ZIR6ju49JvVevWUY+nweOEKOzAmu95TPCx4QqdRGpj+uDIP56ckTs2A 5asw== X-Gm-Message-State: AOUpUlGMDILaJ/yzEL/uyXvrNMpQDP0lRtsPHu9V9j4mbWJdpxq08bJa UDqYbxPUd2Z8YnXvYtzePUuBfNsbArpilOyCT93F/w== X-Google-Smtp-Source: AAOMgpfm/h7ZdeoqmxrYYxAWCOXsIvKIGk4JFbHfLfmOHCkBjLjTVygxCjcid55AXYB8biALia3Ea8UdDK1IGs9q1qk= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr20108924ioe.85.1531191326640; Mon, 09 Jul 2018 19:55:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Mon, 9 Jul 2018 22:55:16 -0400 Message-ID: To: Patrick McManus Cc: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="0000000000001ba40005709c43ea" Archived-At: Subject: Re: [Doh] [Driu] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:55:31 -0000 --0000000000001ba40005709c43ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This sounds an awful lot like an unapproved bof. The reason we don=E2=80=99= t do those is that they tend to make it hard for people to participate. Why isn=E2=80=99t this in scope for dnsop? On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus wrote: > Hi All, > > I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in > Montreal. > > We have often talked about the benefits and concerns of DNS information > obtained from sources that are, shall we say, less globally trusted than = a > recursive a resolver. The central use case is DoH when pushed from an > endpoint that isn't a recursive resolver but there have been other > proposals. > > For example www.example.com pushes you a AAAA record for img1.example.com= . > Should you use it? What if it is for img1.img-example.com ? Do the > relationship between these domains matter? What kind of relationship (i.e= . > it could be a domain relationship, or in the context of a browser it migh= t > be a first-party tab like relationship, etc..)? What are the implications > of poison? Trackers? Privacy of requests never made? Speed? Competitive > shenanigans or DoS attacks? > > This was out of scope for DoH. > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > > This is a meeting of interested folks looking to see if we can agree on > next steps - we're not going to work out the details (nor should a side > meeting try and do so). so we'll have a tight agenda that I suggest > organizaing as follows: > > 1] What forms of transport could be in scope? HTTP/2 push is one such > vector, but I've heard others. Spray paint for example. > > 2] What needs to be considered when using such data? (signatures? scope? > etc?) > > 3] Who are the stakeholders for 1 + 2? > > 4] Is there enough interest to explore further? Next steps as output > > I hope you can come! > > -Patrick > > _______________________________________________ > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu > --0000000000001ba40005709c43ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This sounds an awful lot like an unapproved bof. The= reason we don=E2=80=99t do those is that they tend to make it hard for peo= ple to participate. Why isn=E2=80=99t this in scope for dnsop?
<= div>
On Mon, Jul 9, 2018 at = 10:49 PM Patrick McManus <pmcman= us@mozilla.com> wrote:
Hi All,

I am organizing an ad-hoc Side Meeti= ng regarding 'Resolverless DNS' in Montreal.

We have often talked about the benefits and concerns of DNS information = obtained from sources that are, shall we say, less globally trusted than a = recursive a resolver. The central use case is DoH when pushed from an endpo= int that isn't a recursive resolver but there have been other proposals= .

For example www.example.com pushes you a AAAA record for img1.example.com. Should= you use it? What if it is for img1.img-example.com ? Do the relationship between these = domains matter? What kind of relationship (i.e. it could be a domain relati= onship, or in the context of a browser it might be a first-party tab like r= elationship, etc..)? What are the implications of poison? Trackers? Privacy= of requests never made? Speed? Competitive shenanigans or DoS attacks?

This was out of scope for DoH.

We'll do the meeting over 1 hour in the Dorchester room from 16:3= 0 to 17:30 on Monday July 16th.

This is a meet= ing of interested folks looking to see if we can agree on next steps - we&#= 39;re not going to work out the details (nor should a side meeting try and = do so). so we'll have a tight agenda that I suggest organizaing as foll= ows:

1] What forms of transport could be in scope?= HTTP/2 push is one such vector, but I've heard others. Spray paint for= example.

2] What needs to be considered when = using such data? (signatures? scope? etc?)

3] Who = are the stakeholders for 1 + 2?

4] Is there enough= interest to explore further? Next steps as output

=
I hope you can come!

-Patrick

<= /div>
_______________________________________________
DRIU mailing list
DRIU@ietf.org
https://www.ietf.org/mailman/listinfo/driu
--0000000000001ba40005709c43ea-- From nobody Mon Jul 9 20:06:42 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 9D4561310ED; Mon, 9 Jul 2018 20:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 UVkKhTlb8Yda; Mon, 9 Jul 2018 20:06:29 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 58EC0130E43; Mon, 9 Jul 2018 20:06:29 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id C712D3A054; Mon, 9 Jul 2018 23:06:27 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id 13-v6so39883001ois.1; Mon, 09 Jul 2018 20:06:27 -0700 (PDT) X-Gm-Message-State: APt69E2Es9uwiBG8S9Q+I887+w1CIJMQIp9YumyDb+0R1LyWLbHaHYA0 XFYvJvGWvSrdM+OLFvq7PaOVfFFOZjLDS/5Gh0I= X-Google-Smtp-Source: AAOMgpf9TbJJx9QCkXtfqJ2zqOOPvxS7P/NWR5Teg1n7rNi7h5h7Ejnfu5sm5V61DUD0Qi/zdsBIpROuWjGuwEoKQ5M= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr24109264oib.155.1531191987416; Mon, 09 Jul 2018 20:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 20:06:26 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Mon, 9 Jul 2018 23:06:26 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ted Lemon Cc: Patrick McManus , Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="0000000000007e3a0705709c6a62" Archived-At: Subject: Re: [Doh] [Driu] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 03:06:32 -0000 --0000000000007e3a0705709c6a62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable this is essentially a bar bof - though lacking in a bar and I'm fond of more professional terms so I call it a side meeting. It has no standing. If you're interested then please come, if you're not or are conflicted then you're missing anything process wise. Someday it might graduate to becoming a bof - but I would never put a bof forward that didn't have a proposal I was comfortable with. This is indeed a side meeting for anyone interested to see if there is a shared vision for what such a proposal might look like. Its not in scope for any wg as there isn't a proposal. Its quite possible that it might have multiple outcomes which are in scope for multiple application groups; I've tried to cc the likely suspects here. But that is presupposing outcomes. -P On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon wrote: > This sounds an awful lot like an unapproved bof. The reason we don=E2=80= =99t do > those is that they tend to make it hard for people to participate. Why > isn=E2=80=99t this in scope for dnsop? > > On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus > wrote: > >> Hi All, >> >> I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in >> Montreal. >> >> We have often talked about the benefits and concerns of DNS information >> obtained from sources that are, shall we say, less globally trusted than= a >> recursive a resolver. The central use case is DoH when pushed from an >> endpoint that isn't a recursive resolver but there have been other >> proposals. >> >> For example www.example.com pushes you a AAAA record for img1.example.co= m. >> Should you use it? What if it is for img1.img-example.com ? Do the >> relationship between these domains matter? What kind of relationship (i.= e. >> it could be a domain relationship, or in the context of a browser it mig= ht >> be a first-party tab like relationship, etc..)? What are the implication= s >> of poison? Trackers? Privacy of requests never made? Speed? Competitive >> shenanigans or DoS attacks? >> >> This was out of scope for DoH. >> >> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to >> 17:30 on Monday July 16th.* >> >> This is a meeting of interested folks looking to see if we can agree on >> next steps - we're not going to work out the details (nor should a side >> meeting try and do so). so we'll have a tight agenda that I suggest >> organizaing as follows: >> >> 1] What forms of transport could be in scope? HTTP/2 push is one such >> vector, but I've heard others. Spray paint for example. >> >> 2] What needs to be considered when using such data? (signatures? scope? >> etc?) >> >> 3] Who are the stakeholders for 1 + 2? >> >> 4] Is there enough interest to explore further? Next steps as output >> >> I hope you can come! >> >> -Patrick >> >> _______________________________________________ >> DRIU mailing list >> DRIU@ietf.org >> https://www.ietf.org/mailman/listinfo/driu >> > --0000000000007e3a0705709c6a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this is essentially a bar bof - though lacking in a b= ar and I'm fond of more professional terms so I call it a side meeting.= It has no standing. If you're interested then please come, if you'= re not or are conflicted then you're missing anything process wise.
=

Someday it might graduate to becoming a bof - but= I would never put a bof forward that didn't have a proposal I was comf= ortable with. This is indeed a side meeting for anyone interested to see if= there is a shared vision for what such a proposal might look like.

Its not in scope for any wg as there isn't a prop= osal. Its quite possible that it might have multiple outcomes which are in = scope for multiple application groups; I've tried to cc the likely susp= ects here.=C2=A0 But that is presupposing outcomes.

-P


On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon <me= llon@fugue.com> wrote:
This sounds an awful lot like an unapproved bof. The rea= son we don=E2=80=99t do those is that they tend to make it hard for people = to participate. Why isn=E2=80=99t this in scope for dnsop?
=
On M= on, Jul 9, 2018 at 10:49 PM Patrick McManus <pmcmanus@mozilla.com> wrote:
Hi All,

I am organizing an ad-hoc Side Meeting = regarding 'Resolverless DNS' in Montreal.

= We have often talked about the benefits and concerns of DNS information obt= ained from sources that are, shall we say, less globally trusted than a rec= ursive a resolver. The central use case is DoH when pushed from an endpoint= that isn't a recursive resolver but there have been other proposals.

For example www.example.com pushes you a AAAA record for img1.example.com. Should you = use it? What if it is for img1.img-example.com ? Do the relationship between these domai= ns matter? What kind of relationship (i.e. it could be a domain relationshi= p, or in the context of a browser it might be a first-party tab like relati= onship, etc..)? What are the implications of poison? Trackers? Privacy of r= equests never made? Speed? Competitive shenanigans or DoS attacks?

This was out of scope for DoH.

We'll do the meeting over 1 hour in the Dorchester room from 16:30 to = 17:30 on Monday July 16th.

This is a meeting o= f interested folks looking to see if we can agree on next steps - we're= not going to work out the details (nor should a side meeting try and do so= ). so we'll have a tight agenda that I suggest organizaing as follows:<= /div>

1] What forms of transport could be in scope? HTTP= /2 push is one such vector, but I've heard others. Spray paint for exam= ple.

2] What needs to be considered when using= such data? (signatures? scope? etc?)

3] Who are t= he stakeholders for 1 + 2?

4] Is there enough inte= rest to explore further? Next steps as output

= I hope you can come!

-Patrick

_______________________________________________
DRIU mailing list
DRIU@ietf.org
https://www.ietf.org/mailman/listinfo/driu

--0000000000007e3a0705709c6a62-- From nobody Tue Jul 10 01:42:14 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 EB069130F28; Tue, 10 Jul 2018 01:42:11 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 64AC5L8Mql6n; Tue, 10 Jul 2018 01:42:10 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A84130F1C; Tue, 10 Jul 2018 01:42:10 -0700 (PDT) Received: from [192.168.43.179] (unknown [5.33.14.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BACD7892B9; Tue, 10 Jul 2018 08:42:03 +0000 (UTC) Message-ID: <5B447154.5010307@redbarn.org> Date: Tue, 10 Jul 2018 10:41:56 +0200 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Patrick McManus CC: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , driu@ietf.org, HTTP Working Group , dnsop References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 08:42:12 -0000 Patrick McManus wrote: > ... > > For example www.example.com pushes you a AAAA > record for img1.example.com . Should you use > it? no. sibling names might be delegation points. kashpureff taught us this in 1996 or so, and kaminsky reinforced that lesson in 2008. > What if it is for img1.img-example.com ? certainly not. -- P Vixie From nobody Tue Jul 10 02:09: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 72413130E1D; Tue, 10 Jul 2018 02:09:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N3Xv3bvsMMYr; Tue, 10 Jul 2018 02:09:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 EAE27130E14; Tue, 10 Jul 2018 02:09:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fcoe5-0000GuC; Tue, 10 Jul 2018 11:09:17 +0200 Message-Id: To: dnsop@ietf.org Cc: Patrick McManus Cc: DoH WG , driu@ietf.org, HTTP Working Group From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com In-reply-to: Your message of "Mon, 9 Jul 2018 22:49:25 -0400 ." Date: Tue, 10 Jul 2018 11:09:16 +0200 Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 09:09:23 -0000 >For example www.example.com pushes you a AAAA record for img1.example.com. >Should you use it? What if it is for img1.img-example.com ? Do the >relationship between these domains matter? What kind of relationship (i.e. >it could be a domain relationship, or in the context of a browser it might >be a first-party tab like relationship, etc..)? What are the implications >of poison? Trackers? Privacy of requests never made? Speed? Competitive >shenanigans or DoS attacks? > >This was out of scope for DoH. Assuming that in the context of DoH reply size is not an issue, is seems to me that this use case is already solved by DNSSEC. Just push all required signatures, key material and DS records that allow the receiving side to validate the additional information. Are you trying to re-invent DNSSEC for people who don't want to deploy DNSSEC? From nobody Tue Jul 10 06:28:52 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 CA995130E78; Tue, 10 Jul 2018 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1xmSoNHA8IMm; Tue, 10 Jul 2018 06:28:45 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id D00B9130E9D; Tue, 10 Jul 2018 06:28:44 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3CE153A026; Tue, 10 Jul 2018 09:28:44 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id 13-v6so42582469ois.1; Tue, 10 Jul 2018 06:28:44 -0700 (PDT) X-Gm-Message-State: APt69E0Nlcy1MzoSORNP8Klhwp7uC6qp5oWnCV4sweEEegwLbD871MfH MSqagI/3L4hPCSVaaUAH3tiOqLfMTjcQLF0tRKY= X-Google-Smtp-Source: AAOMgpddJX+GMF9Ubh/Zt1sdM63rBsPA9+JKqAhpZLIYNEQVNnQuiubsN33mHDdXkyhF+FDwBIwvRq7pjNf5tQlUYqo= X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr25581825oih.132.1531229323894; Tue, 10 Jul 2018 06:28:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 06:28:43 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 10 Jul 2018 09:28:43 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Philip Homburg Cc: dnsop , Patrick McManus , DoH WG , driu@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000ebce400570a51bea" Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 13:28:47 -0000 --000000000000ebce400570a51bea Content-Type: text/plain; charset="UTF-8" > Assuming that in the context of DoH reply size is not an issue, is seems to > me that this use case is already solved by DNSSEC. Just push all required > signatures, key material and DS records that allow the receiving side to > validate the additional information. > > that validates its a valid dns record. And maybe that's the whole answer - at which point we still need to write that down along with the scope of where its valid. otoh - maybe its not the same valid dns record another resolver might want you to use. perhaps you have a stronger trust relationship with that other resolver. hmm. otoh - maybe an unsigned record is ok in an https context where DNS isn't the https security model. this is the kind of stuff that I expect is in scope for discussion. > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC no. --000000000000ebce400570a51bea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Assuming that in the context of DoH reply size is not an issue, is s= eems to
me that this use case is already solved by DNSSEC. Just push all required signatures, key material and DS records that allow the receiving side to validate the additional information.


that validates its a valid dns record.= And maybe that's the whole answer - at which point we still need to wr= ite that down along with the scope of where its valid.

otoh - maybe its not the same valid dns record another resolver mi= ght want you to use. perhaps you have a stronger trust relationship with th= at other resolver. hmm.

otoh - maybe an unsigned r= ecord is ok in an https context where DNS isn't the https security mode= l.

this is the kind of stuff that I expect is in s= cope for discussion.
=C2=A0
Are you trying to re-invent DNSSEC for people who don't want to deploy<= br> DNSSEC

no.
--000000000000ebce400570a51bea-- From nobody Tue Jul 10 06:42:55 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 56864130FC4; Tue, 10 Jul 2018 06:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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] 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 n-k16YZ2Cvd7; Tue, 10 Jul 2018 06:42:26 -0700 (PDT) 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 1DE6D131158; Tue, 10 Jul 2018 06:42:26 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id y10-v6so5560663ioa.10; Tue, 10 Jul 2018 06:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0eOH/RC2GtAj1uACi5ZejTEKKv6YyfXsyGZ0W6kn+N4=; b=PAxuq8gThq8pFkFjn3QORolYQcYu4EFly2b7+8kM5XZC0US5lr1zM23oYZektoxiqb O5UmABa3p0fM/Pait5/8ftyTnMS33BNW1u1Ry/6o/zJiv8L+efAGemFXU4azUk75sghC PdGg0s/Rpoc5+2kTHdozY6aF2PPFBWY81GWjqkjHa4F5dNZL3VnXyzkM19jbsFpeX6Ym pFt9dFDNs+L9g0MpVJaNJT7YflFKuCMj36r7/LrlfaryvUfIshtFZzivWNtHCiNTngiK /xdQUGDheOfS9wuTgfSdVNiqEqsxXDtcbrF6HI/63HNMkRSyzTiFFuWXgOrzRyHlBqM9 xAmQ== 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=0eOH/RC2GtAj1uACi5ZejTEKKv6YyfXsyGZ0W6kn+N4=; b=qdZQzkDpiB88czNIGfYy08LbqaA3yEBq77BE8pNZPL9A6K5PQ4hSoukdotwQhOOiQn ocbrSaclpTLHjq5wvILcyvS2UZcb86Ehdw+vpmXPujC5/w8SAkpYlNZj8WP9U2vVCREt LiW1i6yB1so/PXqGw4Cw/eIcYHtIY4YbA7GKYeI9GL3eKMTLaPr8be341qdup/dbzYOQ 57wlwDhU/+L7uVxxfahh9MknlBtu2E/Zs/uopLZ1PmwsZsAaQCle2RH8EcUt0b9nE5DF OPy+FU1PfXIgDcBwjCp0CuyhQvE/NlLgssj1GNuVM9mpiMvrHtQG1qmndyd8tV6Za8yI RwNQ== X-Gm-Message-State: AOUpUlGGSn/FDxur5JPBATsm2+B1QPejENMZ/Pu+wfphfqCHAkyqJRFU ufny5LRQju6Fe3F+gr7N9Xe7U4uKGV/tyEJ20b4= X-Google-Smtp-Source: AAOMgpf0Foh/bqyHs38sz+/9xvflUrnd7dp0LS2osR6Er1WjAvNjy9W2NyXVM7ro73mn+m3cnnENoKgs4u8AtJujkIE= X-Received: by 2002:a6b:c90a:: with SMTP id z10-v6mr19948415iof.135.1531230145413; Tue, 10 Jul 2018 06:42:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: manu tman Date: Tue, 10 Jul 2018 06:42:14 -0700 Message-ID: To: Patrick McManus Cc: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000e305a30570a54c7d" Archived-At: Subject: Re: [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 13:42:34 -0000 --000000000000e305a30570a54c7d Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus wrote: > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > Will it be recorded and will there be everything set for remote participants? Manu --000000000000e305a30570a54c7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Jul 9, 2018 at 7:49 PM Patrick McManus <pmcmanus@mozilla.com> wrote:

We'll do the meeting over 1 hour= in the Dorchester room from 16:30 to 17:30 on Monday July 16th.
<= /div>

Will it be = recorded and will there be everything set for remote participants?

Manu
--000000000000e305a30570a54c7d-- From nobody Tue Jul 10 06:47:07 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 5599A130E9D; Tue, 10 Jul 2018 06:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 msQvTJNPOF3A; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id C8AA41277CC; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5A9E03A055; Tue, 10 Jul 2018 09:46:57 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id w126-v6so42666313oie.7; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) X-Gm-Message-State: APt69E3vq4QYc1ndaKNEzvprDSM7Y3Aifv4WBx20l5bS64vtZ2MX2Vqu xGiKV7lUnR7PAH8/GOGl2IrIuu/lxoPGirS7aek= X-Google-Smtp-Source: AAOMgpep4y/uhziPfTS7snWkI8Ic4YLMQ/M2ytR5I71voqRVfo0Tk3ZNpruzQR2pc4VAgiHq4Gp2pEJDor+qs/2eB0k= X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr25653367oih.132.1531230417018; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 06:46:56 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 10 Jul 2018 09:46:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: manu tman Cc: Patrick McManus , Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="00000000000013681f0570a55d5c" Archived-At: Subject: Re: [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 13:47:00 -0000 --00000000000013681f0570a55d5c Content-Type: text/plain; charset="UTF-8" probably not (whatever is available will be adhoc) - its a side meeting (aka bar bof) meant to take advantage of whomever is there. It has no process value. I'll make an effort to take minutes and report out though. On Tue, Jul 10, 2018 at 9:42 AM, manu tman wrote: > > > On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus > wrote: > >> >> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to >> 17:30 on Monday July 16th.* >> > > Will it be recorded and will there be everything set for remote > participants? > > Manu > --00000000000013681f0570a55d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
probably not (whatever is available will be adhoc) - = its a side meeting (aka bar bof) meant to take advantage of whomever is the= re. It has no process value.

I'll make an effo= rt to take minutes and report out though.


On Tue, Jul 10, 2018 at = 9:42 AM, manu tman <chantr4@gmail.com> wrote:


On Mon, Jul 9, 2018 at 7:49 PM Patrick McManu= s <pmcmanus@mo= zilla.com> wrote:

We'll do the meeting over 1 hour in the Dorchester= room from 16:30 to 17:30 on Monday July 16th.
=

Will it be recorded an= d will there be everything set for remote participants?

Manu

--00000000000013681f0570a55d5c-- From nobody Tue Jul 10 07:03:14 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 4BC30130E9F; Tue, 10 Jul 2018 07:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 1qDFlKBAAVtP; Tue, 10 Jul 2018 07:03:10 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 F1B29130E8C; Tue, 10 Jul 2018 07:03:09 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id a3-v6so5521821wrt.2; Tue, 10 Jul 2018 07:03:09 -0700 (PDT) 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=UBghc4tka6ONj6OZRTSQMjTHhWawF0VRGtuU0L0GCUE=; b=DRkqxf33Xk8Czrc5gZbOocBf2goTWCnXkpOdhfVEwhIA97Qm2oIrQzRRwy5SSckfCU jESICt289qorRQs8ZTTUTZ8jMrWSuAlfqNqWjdcnq5UxG+oFuWSl2cYtqsTO2R5/3kaK tTcBFBq0trpW0Pf0vZZ/JahPudyGL3raPtEtdIS6dtOlodAzfcP5BiSixvd9RW7zcxcm BBmtPMqzt5iS5zuxwLbnHmPVNssnqUwETDZQwykbffPTjOIfdTjCbvw4DUEM/8wiqHEn luGZ/IVeKMJQiKsBEMG7f1YS+YXhH6K1WOgAAsmAaw8cEEIiGBBxs02d0gwj4m7hdYUi KZxg== 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=UBghc4tka6ONj6OZRTSQMjTHhWawF0VRGtuU0L0GCUE=; b=X9oBImGQRPIyQIm+96j8OgWUVSCZnykhuAm7XPTAhuIVTX+Xhgoe2BZX3tt48jFiWf R5EryXwTzZkDSTmWXD8FEgLNDpHTxbhXrTo/DdZ770ajMryV9d+oiEq47EZcnLJu5ryh YSkqTYqsDQp+PFcUWeF/X6kQwJ23+af8thhiExHZY1s6vCjDCKH3cvjV12wpANji7lbX AnnqZE1BlLUcuHhSdjzdJnWlEsY0oZkx/YC1ALEu5/D6JdIYBVPHDG2F8K4ko81gxFsc kYN42pXbbqiFauq57+yh/i/QfQfi33HbDQqU3CBdP/twjli/9HH7xqzzU0/2oNCxrY1E fUqg== X-Gm-Message-State: AOUpUlGlyFrArOVmFQpSKVniZv3dbRqycZJvx31aNhcaqhUOXINADYHw BzxU068uxkB2sn9DVcti4N0b20l7YwC3Gha972s= X-Google-Smtp-Source: AAOMgpc4ZHdjYs/R+jOVTlPcTioXZlycl/ALApiVPyT8XiYe0HwD+mVVwQ5b84vxyROo9GQNf+iLFSVk8qrf5HKBCrQ= X-Received: by 2002:adf:e34d:: with SMTP id n13-v6mr10166512wrj.158.1531231388542; Tue, 10 Jul 2018 07:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 07:03:08 -0700 (PDT) In-Reply-To: References: From: Tim Wicinski Date: Tue, 10 Jul 2018 10:03:08 -0400 Message-ID: To: Philip Homburg Cc: dnsop , HTTP Working Group , DoH WG , Patrick McManus , driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000fbaa1e0570a59615" Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:03:13 -0000 --000000000000fbaa1e0570a59615 Content-Type: text/plain; charset="UTF-8" > > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" My magic 8-ball says "signs point to Yes" On Tue, Jul 10, 2018 at 5:09 AM, Philip Homburg wrote: > >For example www.example.com pushes you a AAAA record for img1.example.com > . > >Should you use it? What if it is for img1.img-example.com ? Do the > >relationship between these domains matter? What kind of relationship (i.e. > >it could be a domain relationship, or in the context of a browser it might > >be a first-party tab like relationship, etc..)? What are the implications > >of poison? Trackers? Privacy of requests never made? Speed? Competitive > >shenanigans or DoS attacks? > > > >This was out of scope for DoH. > > Assuming that in the context of DoH reply size is not an issue, is seems to > me that this use case is already solved by DNSSEC. Just push all required > signatures, key material and DS records that allow the receiving side to > validate the additional information. > > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC? > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000fbaa1e0570a59615 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Are you trying to re-invent DNSSEC = for people who don't want to deploy
DNSSEC?"
<= br>
My magic 8-ball says "signs point to Yes"=C2=A0

On Tue, J= ul 10, 2018 at 5:09 AM, Philip Homburg <pch-dnsop-3@u-1.phicoh.co= m> wrote:
= >For example www.example.com pushes you a AAAA record for img1.example.co= m.
>Should you use it? What if it is for img1.img-example.com ? Do th= e
>relationship between these domains matter? What kind of relationship (i= .e.
>it could be a domain relationship, or in the context of a browser it mi= ght
>be a first-party tab like relationship, etc..)? What are the implicatio= ns
>of poison? Trackers? Privacy of requests never made? Speed? Competitive=
>shenanigans or DoS attacks?
>
>This was out of scope for DoH.

Assuming that in the context of DoH reply size is not an issue, is s= eems to
me that this use case is already solved by DNSSEC. Just push all required signatures, key material and DS records that allow the receiving side to validate the additional information.

Are you trying to re-invent DNSSEC for people who don't want to deploy<= br> DNSSEC?


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

--000000000000fbaa1e0570a59615-- From nobody Tue Jul 10 07:59: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 30763130FCF; Tue, 10 Jul 2018 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 1bROqm8coot4; Tue, 10 Jul 2018 07:59:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 2AC81130FCD; Tue, 10 Jul 2018 07:59:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Q5233w6dzDm5; Tue, 10 Jul 2018 16:59:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531234747; bh=3/+32zpeEZ4nIxPZISHOvOY63QE9kAj2xJORSW0LWDk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DYHl77ahR6hvcHhlPlNCFNcvV0IoFhjGUo6rfBtfM6Uyc3W7f6C8gCkr2LIKHl8zA 31YR5O8N/DHHBYzPtDg50MnEviRXyP0ElpytTnwV8uOpEUWu2du1M5vmQ8N+cRHv8P jrsKZsTiUt8jTpgvtcjWn3uNDuFhugdhH8U9cl4w= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id vL-UWlkEHvhP; Tue, 10 Jul 2018 16:59:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jul 2018 16:59:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8717D39A6A8; Tue, 10 Jul 2018 10:59:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8717D39A6A8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8080541682B5; Tue, 10 Jul 2018 10:59:05 -0400 (EDT) Date: Tue, 10 Jul 2018 10:59:05 -0400 (EDT) From: Paul Wouters To: Philip Homburg cc: dnsop@ietf.org, HTTP Working Group , DoH WG , Patrick McManus , driu@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:59:14 -0000 On Tue, 10 Jul 2018, Philip Homburg wrote: >> For example www.example.com pushes you a AAAA record for img1.example.com. >> Should you use it? What if it is for img1.img-example.com ? Do the >> relationship between these domains matter? What kind of relationship (i.e. >> it could be a domain relationship, or in the context of a browser it might >> be a first-party tab like relationship, etc..)? What are the implications >> of poison? Trackers? Privacy of requests never made? Speed? Competitive >> shenanigans or DoS attacks? >> >> This was out of scope for DoH. I'm also confused about what the scope is. If you connect over TLS to a site and it has links to other hostnames, I guess you trust it ? The TLS/trust mechanism has really no other way of certifying the content server over TLS, unless you want to object/webpage signing. Which is impossible in today's dynamic web state. > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC? It seems more like an extension of the Public Suffix. Which domains can make claims about other domains. I'm not sure I see the connection with private DNS queries. Paul From nobody Tue Jul 10 08:10: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 314C81311AB; Tue, 10 Jul 2018 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 6TQTeCGggPXs; Tue, 10 Jul 2018 08:09:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7A4E1131184; Tue, 10 Jul 2018 08:09:47 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AF9fWg085359 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 10:09:44 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Paul Wouters , Philip Homburg Cc: driu@ietf.org, dnsop@ietf.org, DoH WG , HTTP Working Group , Patrick McManus References: From: Adam Roach Message-ID: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> Date: Tue, 10 Jul 2018 10:09:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:09:57 -0000 [as an individual] On 7/10/18 9:59 AM, Paul Wouters wrote: > It seems more like an extension of the Public Suffix. Which domains can > make claims about other domains. Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay? There *might* be some useful discussion that includes applying the PSL to determine who can vouch for what, but I would expect this to be of significantly lower priority; and, given DBOUND's recent failure, I doubt there's useful IETF work to be done in that space, at least for the time being. /a From nobody Tue Jul 10 08:19:41 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 23DD8130FDB; Tue, 10 Jul 2018 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 0wMBNtbPAd-Q; Tue, 10 Jul 2018 08:19:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 E00E4130FE5; Tue, 10 Jul 2018 08:19:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Q5Td07l5zDm5; Tue, 10 Jul 2018 17:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531235973; bh=gH0uXzuqvfQnwfwAXQpXHYCcNJM8y9nIzygp41ElniQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=n8/KpKmsUW8YI4np3XFjkn6DRBNkHqgPwZ2VXlTGe+0X8dZNsNe1AolZObcXxrx7o YtTdImHDRmBc+VLl8J6PCs6EWZ8KROSb3D1oIzFGwxi4PcprYZn9apnEE4auioH1mO /Ih0WCV8KtsxWip9QNQV4nm7otULAah47jp7hI/g= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id tZDyKNojmzR8; Tue, 10 Jul 2018 17:19:31 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jul 2018 17:19:30 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E256739A6A8; Tue, 10 Jul 2018 11:19:29 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E256739A6A8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8CC441682B5; Tue, 10 Jul 2018 11:19:29 -0400 (EDT) Date: Tue, 10 Jul 2018 11:19:29 -0400 (EDT) From: Paul Wouters To: Adam Roach cc: Philip Homburg , Patrick McManus , dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group In-Reply-To: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:19:40 -0000 On Tue, 10 Jul 2018, Adam Roach wrote: > On 7/10/18 9:59 AM, Paul Wouters wrote: >> It seems more like an extension of the Public Suffix. Which domains can >> make claims about other domains. > > Based on the conversation that took place in DoH in Singapore, I think it's > mostly *not* about this. The questions that have come up so far include: (a) > If the record that is pushed to me is DNSSEC signed, is that sufficient to > trust it? (b) If the record that is pushed to me is not DNS signed, but I'm > using it in a context that requires TLS (e.g., HTTPS), and the thing that I > connect to when I use the record can present a cert that proves its identity, > is that okay? I see. I guess I agree more now with the previous poster that this is more like yet another kind of "transparancy" workaround for not wanting to deploy dnssec :) I understand that having a WebPKI and a DANE PKI leads to an unwanted mixture of trust models. It might be useful to talk about that, especially in light of tls-dnssec-chain where it seems that some proposals result in a preventative block of a DANE PKI for no apparent other gain. Paul From nobody Tue Jul 10 08:30: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 9221613105F for ; Tue, 10 Jul 2018 08:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 hlaV9Wr_fiMM for ; Tue, 10 Jul 2018 08:30:22 -0700 (PDT) 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 5F283131024 for ; Tue, 10 Jul 2018 08:30:22 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id n17-v6so24832613wmh.2 for ; Tue, 10 Jul 2018 08:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s5CFesfgJ2jLxkVR4YFgJKgPtCEkMh/3dbdo3NUhL7M=; b=dj2qc5Q6MTrnCEann9BXMzgT25sJ9W50NIWcDX3BDmUctr6ran8rQ8gzmEGAimKr86 on8PBdICex5dniywQhT0UsUdM7RtzH3ttCM0QVcnkQBKJX9vKTphGu1HpvIHMuiVqZ1N /dUeWsginS+mJFnhAMFYJ40PBeUk/U3G2Xjus= 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=s5CFesfgJ2jLxkVR4YFgJKgPtCEkMh/3dbdo3NUhL7M=; b=WZEZagYYY/YpWvmUPKflzEdNLO3OA/wnSZh+2rfBcDD0Uybz1NWgJWOBxNO+xt2xAq 9Yq8icOlKsQo0Fyn5ZOKoNXI201kTzcIxuO0BJt1xltGaLJD8iZh5f2aYcoSgjVNjxRk 1H7NuWYBRqEzRJC/0s+OycJBELy6pFmab1a0IBEWVh5BwM3si/7kjKT64IEI8Bjw9AGb /mjvemrte8mJVczNr3MjtXjOFqc2mFt9f9egbJ9IX3DM7ZNMebYRy9z3GsGb5Po3vhEx 5CJ3wY+i/ejq7QpP2nBgemzqQb5gTI/K4/dtIClCjC4MdPPc2HyQ7dUFhaPUos/fOACi N36A== X-Gm-Message-State: APt69E1pFFShnTiOOb6gS9/BUhfDYydjzNWhitlX7VnnaGsP6mBPuYjk H1O2M5gbkmKgPIci3WPpUlzupQ09tmI= X-Google-Smtp-Source: AAOMgpdW45wVyAGV2TmCg6NS6o/7zU55P9wT7TtA3bVwyzl9bmgzwGXGAJfqKYN+8lU1zpdE+iGcfA== X-Received: by 2002:a1c:30d2:: with SMTP id w201-v6mr14180928wmw.47.1531236620778; Tue, 10 Jul 2018 08:30:20 -0700 (PDT) Received: from [10.0.1.165] (host165-120-47-210.range165-120.btcentralplus.com. [165.120.47.210]) by smtp.gmail.com with ESMTPSA id c10-v6sm17366203wrs.6.2018.07.10.08.30.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 08:30:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15F79) In-Reply-To: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> Date: Tue, 10 Jul 2018 16:30:18 +0100 Cc: Paul Wouters , Philip Homburg , Patrick McManus , dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> To: Adam Roach Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:30:25 -0000 On Jul 10, 2018, at 16:09, Adam Roach wrote: > [as an individual] >=20 >> On 7/10/18 9:59 AM, Paul Wouters wrote: >> It seems more like an extension of the Public Suffix. Which domains can >> make claims about other domains.=20 >=20 > Based on the conversation that took place in DoH in Singapore, I think it'= s mostly *not* about this. The questions that have come up so far include: (= a) If the record that is pushed to me is DNSSEC signed, is that sufficient t= o trust it? (b) If the record that is pushed to me is not DNS signed, but I'= m using it in a context that requires TLS (e.g., HTTPS), and the thing that I= connect to when I use the record can present a cert that proves its identit= y, is that okay? I think perhaps the people who have been having these conversations are not b= eing ambitious enough. The pressures in the enterprise DNS market are overwhelmingly driven by the n= eed to make web apps more reliable, load faster, and offer user-specific con= tent. There are other reasons to want DNS tricks, but the customers that pay= the big money are all concerned with HTTPS UX. Some of the decision points a= re in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX= session initiation, but after that the HTTP layer has (can have) a far rich= er set of data about the user and is able to separate user-blocking decision= -making from the flow of the UX which also affords extra time to make decisi= ons without the user becoming frustrated. [To illustrate the architectural lunacy of the status quo, consider the data= sets that are gathered through real-user-monitoring in browsers, served at t= he HTTP layer, that are subsequently used to steer DNS traffic used to retri= eve resources back at the HTTP layer. There's a whole layer of derived datas= ets relating to the DNS there that are being generated by the web and used b= y the web, but with a tangy sandwich filler of DNS that is just overhead.] It seems like it would be nice then, after the UX-blocking elements are load= ed and the user is already engaged, for subsequent lookups to be driven in H= TTP and client-side scripting and to be presented to the stack as bare addre= sses rather than DNS names. That avoids the dependency on the DNS after init= ial page load altogether and leaves all the performance engineering decision= s in the same place as the content decisions. There are problems with this approach today (certificate matching, for examp= le) but I don't think the problems necessarily relate to the DNS. Perhaps th= ey relate to a local-context naming system that doesn't exist outside a java= script sandbox. I see the attraction of shifting name resolution to DOH sinc= e it makes it look like everything is a web app, but collapsing the address s= election back to the extent that you can avoid name resolution at all seems l= ike a better end goal. So rather than resolverless operation, think about resolutionless or nameles= s, eliminating the DNS as unnecessary overhead. Perhaps I have misunderstood the whole problem space, of course :-) Joe From nobody Tue Jul 10 09:23:40 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 58581130E4A; Tue, 10 Jul 2018 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 95QFJvmELtlu; Tue, 10 Jul 2018 09:23:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7A743126CC7; Tue, 10 Jul 2018 09:23:29 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AGMtwP097444 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 11:22:57 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Joe Abley Cc: Paul Wouters , driu@ietf.org, dnsop@ietf.org, DoH WG , Patrick McManus , Philip Homburg , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: Date: Tue, 10 Jul 2018 11:22:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:23:32 -0000 On 7/10/18 10:30 AM, Joe Abley wrote: > On Jul 10, 2018, at 16:09, Adam Roach wrote: > >> [as an individual] >> >>> On 7/10/18 9:59 AM, Paul Wouters wrote: >>> It seems more like an extension of the Public Suffix. Which domains can >>> make claims about other domains. >> Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay? > I think perhaps the people who have been having these conversations are not being ambitious enough. > > The pressures in the enterprise DNS market are overwhelmingly driven by the need to make web apps more reliable, load faster, and offer user-specific content. There are other reasons to want DNS tricks, but the customers that pay the big money are all concerned with HTTPS UX. Some of the decision points are in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX session initiation, but after that the HTTP layer has (can have) a far richer set of data about the user and is able to separate user-blocking decision-making from the flow of the UX which also affords extra time to make decisions without the user becoming frustrated. > > [To illustrate the architectural lunacy of the status quo, consider the data sets that are gathered through real-user-monitoring in browsers, served at the HTTP layer, that are subsequently used to steer DNS traffic used to retrieve resources back at the HTTP layer. There's a whole layer of derived datasets relating to the DNS there that are being generated by the web and used by the web, but with a tangy sandwich filler of DNS that is just overhead.] > > It seems like it would be nice then, after the UX-blocking elements are loaded and the user is already engaged, for subsequent lookups to be driven in HTTP and client-side scripting and to be presented to the stack as bare addresses rather than DNS names. That avoids the dependency on the DNS after initial page load altogether and leaves all the performance engineering decisions in the same place as the content decisions. Basically, you're describing a solution space that could be realized as something like: But this is really equivalent in just about every important way to sending the normal along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have. Note: I'm not saying anything about the trust issues that arise in either case, and I'm not trying to gloss over the need to perform a really careful analysis; I'm just saying that what you're suggesting is definitely equivalent to one of the implied eventual outcomes of what is being proposed. /a From nobody Tue Jul 10 09:34: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 8DF64126CC7 for ; Tue, 10 Jul 2018 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 v9lNYA4v2YZ5 for ; Tue, 10 Jul 2018 09:34:43 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 08F41131012 for ; Tue, 10 Jul 2018 09:34:41 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id q127-v6so16614760ljq.11 for ; Tue, 10 Jul 2018 09:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=RhOwDeizS2p1sDwMvQJpECvp62XALlw/l7BD48f8O0Q=; b=IyH9v9MEpD3onkQOraCj1qlObMwPrP4rA3G0nIFK5gpGgsOfkOUvMGU8njqdifHky/ 8NT14mdS//rC2adaxFv+A4yWyWfhfWrgAUKtSpeZTpuTsIPIhpeEpJVcK2/j7W+8o2RH Whp9rf5a9MlCekbQJGxQV7Y3GcJBqOuQVVA5E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=RhOwDeizS2p1sDwMvQJpECvp62XALlw/l7BD48f8O0Q=; b=NfC/e1lpvly2yAEgk9z4ikveBvw3hDN0Evi1KPb7kTHYAkOZUQIv2XjoflH+g97odC 0RYHQvjEQLfmGLs0Q7GeohGVgRV/b92RfAjVOxJOIpLfSrl4wiDEHodT1xz2vv24js/L 8P4L6xF782RVhR+H25JQwheTsS+2R5iq4oA2uUepRtED10Wmhk4E1JVuflBoRxmAjg41 moTzpUDto2byqXTNRH++mI+G/yO8qh+R+CStA+7H6l36gTavvK8cEu+HdvRb5jW4JAEe suEMe9D8R7+xzlfRAV5Ps2YQJnH5wTN5QYjsAYSshK1Sqt4HHxM7ToA7BPPdmqJFyMKE UBkg== X-Gm-Message-State: APt69E0T50Tlwmi1ysK1caqnAUhYSMoLi5EuLk7ypOaxjdpwZ3jjmfRx LCWL5uycQCjp0zr1eudDSVcAg4dYbnxMt54TA2ffMQ== X-Google-Smtp-Source: AAOMgper5iC5ciWT5QSOvbIfNf6C6wptrj2+IxkwIumOQxfjmkMTjaAHuYnX5/TaPLQ3dJmbX3RViLPifzrbV9roP5Q= X-Received: by 2002:a2e:7815:: with SMTP id t21-v6mr9092751ljc.61.1531240479262; Tue, 10 Jul 2018 09:34:39 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 09:34:38 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-Reply-To: Date: Tue, 10 Jul 2018 09:34:38 -0700 Message-ID: To: Adam Roach Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:34:45 -0000 On Jul 10, 2018, at 17:22, Adam Roach wrote: > Basically, you're describing a solution space that could be realized as s= omething like: > > Ok, interesting. I would suggest considering a richer scheme that accommodates address families and multiple addresses with priorities, but I see how that kind of thing would allow a client to do so certificate matching and resource retrieval without using the DNS. > But this is really equivalent in just about every important way to sendin= g the normal along with a pushe= d DNS record that indicates that "example.com" resolves to "192.0.2.1" -- a= nd this latter thing is (to my understanding, at least) in scope of the con= versation that Patrick is proposing to have. My question is why you would involve the DNS at all if all the performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit. > Note: I'm not saying anything about the trust issues that arise in either= case, and I'm not trying to gloss over the need to perform a really carefu= l analysis; Likewise. However, I think DNS protocol advice is probably more useful as input to the analysis if it's clear that the DNS is necessarily involved. Joe From nobody Tue Jul 10 09:42: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 9F8DD12F1A5 for ; Tue, 10 Jul 2018 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, 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 tFZACf4WngkY for ; Tue, 10 Jul 2018 09:42:27 -0700 (PDT) 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 0EC0A131010 for ; Tue, 10 Jul 2018 09:42:27 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 188-v6so32202530ita.5 for ; Tue, 10 Jul 2018 09:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68SDTK5YT/MU8mHuyvullKIGlLi4GxVmx9CuRJwFs9w=; b=FKty7O+cCbpyj1DKFWSyHK1r4ThoGd5ivfSPOkt6uwmZkjIviLF7EOCMe5UKH6aTke 6LLahAaev8zV+dlu8HNcxuHnGXVqNptOPuBeSBMtvOwF1W9tQc7ffDR7ZPYqX1Rk0c8r JYCnUn/+B3wjB6WtkBg1yLeindRi0ilp57mXWsnDk2fwi1/1H4rrXJNPAFktMVcpI6Nw fpuXZUNx7cCAhWrcX9+weRTEhQra6F42j65x1lsPtp4Pquf1EAvpcnACVNqMyZ8JaoLh BoJ7mloXe/CywbUZk9nF1rub/C921URHKUNoNBAqEGjCXnFkuppLlJY/sLhyKdUpckHc S+pA== 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=68SDTK5YT/MU8mHuyvullKIGlLi4GxVmx9CuRJwFs9w=; b=Bfv154zZLm92pFoJjLCMKAqqnue2OwGXC0HYNLsy/WbEO1xSdcAd6bj2NgO1QJteey 1BymBXdwadU+RLx752edVPUBndmdXp9ovF2xkr/RSwGGzVUE9j/qeyZ1BQPqyvyX3aca KuOns54+ogc3EsVQspuRbyE/kDg07MmWgJ6naqVUYxE0DM4Qfd666RfI7Us7IBbS/2Uq /2dS6wKbZKJZYZy/XlJ2wjBiTw6yPc5vSURg/EB+IDUTagpJQOfGKPkTfZMurT/uamEK RN7x/g6KKjWfK8G0581vxYloC74IsM/OyJIlsALAu2TKfAyX9E3FHUjPMA2hl/MwrKVk aw9Q== X-Gm-Message-State: APt69E3uKXx9PXmzP7PtBJhHXbvRmnkahwCNEI0sAYU/xTb+d19N1Efq 8BU4/B+Bl8YXgvwq4iB0HXy1t9p9IbFS7h+sfaJ1qw== X-Google-Smtp-Source: AAOMgpf6z3DMBuvAVT7AYW1h39XcgfMKTCLyVLRWu/yNjkIqd4kv/r72Hw65iKKmpzN/HFMrBVLWRZvx42eTrv997qY= X-Received: by 2002:a02:b70b:: with SMTP id g11-v6mr21785562jam.34.1531240946430; Tue, 10 Jul 2018 09:42:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 09:41:46 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Ted Lemon Date: Tue, 10 Jul 2018 12:41:46 -0400 Message-ID: To: Joe Abley Cc: Adam Roach , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000ad820b0570a7d050" Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:42:30 -0000 --000000000000ad820b0570a7d050 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > > But this is really equivalent in just about every important way to > sending the normal along with a > pushed DNS record that indicates that "example.com" resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at least) in > scope of the conversation that Patrick is proposing to have. > > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source. I'm sure there's an attack surface in there somewhere. --000000000000ad820b0570a7d050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopc= ount.ca> wrote:
> But this i= s really equivalent in just about every important way to sending the normal= <img src=3D"https://example.com/img/f.jpg"> a= long with a pushed DNS record that indicates that "example.com" reso= lves to "192.0.2.1" -- and this latter thing is (to my understand= ing, at least) in scope of the conversation that Patrick is proposing to ha= ve.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit

=
The ip=3D modifier would be a great way to arrange for something to lo= ok like it came from a different source than its actual source. =C2=A0 I= 9;m sure there's an attack surface in there somewhere.
--000000000000ad820b0570a7d050-- From nobody Tue Jul 10 09:47: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 27D5E131113 for ; Tue, 10 Jul 2018 09:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 CXt8AYlMyx1X for ; Tue, 10 Jul 2018 09:47:38 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 C5595131016 for ; Tue, 10 Jul 2018 09:47:37 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id u14-v6so18888304lfu.0 for ; Tue, 10 Jul 2018 09:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=6J6A+vP8PvPMWUyi3RHqDp0tRbsGRA+uorGsYvr/7TQ=; b=Frs75OXH1NAlA6UwE4eOCBrXm2WCxt7LVaPzbyscQVJUZH6aZGlXxODzbsB3wfUvJv GOsoKL1Kr5O62HtTa7BUaoWj2nQzB6RJqSLE0lfwbz0a6go9RJK40WinWOnDltnvzn+g LrORxDlHM4IxDBguur9691e3d+MKRIemskU9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=6J6A+vP8PvPMWUyi3RHqDp0tRbsGRA+uorGsYvr/7TQ=; b=e5fwouG+SRUvxc8XYc7LMgBB/HA6hLvqq7bXmxY5+uAPaopApSLMZC69pzYSXrawDG jTvLWXGN32mNtqzNT+dUEUne5/ev+wBAlVQsRUcU/RGWc7kHt/cZtZKAHZup85diA+WY 1DjG3Lco3FUVb8GJIY+s2vnIaSU1Qcb6iHlrR/lCcjO2zPdOyyLHNon52JgIrgo7xdP1 HVHDu7/kCFSX8JoAV/9VcVrMt0cXLFHiTCuKIidrICh22RSThSxlUfNu85dwebwF2Bog SaEqFx8U055/0KuQeJAhUVAjfEw+MQjBWfat3utes5Wewp1uaf57oPhK5idcpqRMtBuH wOBw== X-Gm-Message-State: APt69E3zlT/I6tHZqF0oLh65b9wNwMF+4Pd7haIRuvNv5WpEdyQhqQaN bKXhTDzNFWEVkdsf74duv3wHXiR195g5VrvR2GxS8w== X-Google-Smtp-Source: AAOMgpeX/jNQLA9S56MDTer5E/vlgm/Fubh4P0D2suiKOXjLvP/i4zyXAQwL5gEqzwq0qERS17kAVb4BcZe/kI1Xpe4= X-Received: by 2002:a19:1f4b:: with SMTP id f72-v6mr3314407lff.42.1531241256022; Tue, 10 Jul 2018 09:47:36 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 09:47:35 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-Reply-To: Date: Tue, 10 Jul 2018 09:47:35 -0700 Message-ID: To: Ted Lemon Cc: Adam Roach , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000021bd490570a7e349" Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:47:47 -0000 --00000000000021bd490570a7e349 Content-Type: text/plain; charset="UTF-8" On Jul 10, 2018, at 17:41, Ted Lemon wrote: On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > > But this is really equivalent in just about every important way to > sending the normal along with a > pushed DNS record that indicates that "example.com" resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at least) in > scope of the conversation that Patrick is proposing to have. > > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source. I'm sure there's an attack surface in there somewhere. I'm haven't thought hard enough to say what vulnerability that would enable that wasn't already there using unsigned zones (because enterprise DNS tricks or some other reason) but you're probably right. Joe --00000000000021bd490570a7e349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jul 10, 2018, at 17:= 41, Ted Lemon <mellon@fugue.com&= gt; wrote:

On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopcount.ca&g= t; wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> But this is really equi= valent in just about every important way to sending the normal <img src= =3D"https://example.com/img/f.jpg"> along with a = pushed DNS record that indicates that "example.com" resolves to &quo= t;192.0.2.1" -- and this latter thing is (to my understanding, at leas= t) in scope of the conversation that Patrick is proposing to have.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit

=
The ip=3D modifier would be a great way to arrange for something to lo= ok like it came from a different source than its actual source. =C2=A0 I= 9;m sure there's an attack surface in there somewhere.

I'm haven't thought hard enough to say = what vulnerability that would enable that wasn't already there using un= signed zones (because enterprise DNS tricks or some other reason) but you&#= 39;re probably right.


Joe
--00000000000021bd490570a7e349-- From nobody Tue Jul 10 10:03: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 B39B813114C; Tue, 10 Jul 2018 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 JtihJTA2fqCQ; Tue, 10 Jul 2018 10:03:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 17FD8131142; Tue, 10 Jul 2018 10:03:23 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AH2tmL004330 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:02:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Joe Abley Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: Date: Tue, 10 Jul 2018 12:02:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:03:26 -0000 On 7/10/18 11:34 AM, Joe Abley wrote: > On Jul 10, 2018, at 17:22, Adam Roach wrote: > >> Basically, you're describing a solution space that could be realized as something like: >> >> > Ok, interesting. I would suggest considering a richer scheme that > accommodates address families and multiple addresses with priorities, > but I see how that kind of thing would allow a client to do so > certificate matching and resource retrieval without using the DNS. > >> But this is really equivalent in just about every important way to sending the normal along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have. > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit. In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". /a From nobody Tue Jul 10 10:06: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 4C3E0131142; Tue, 10 Jul 2018 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 BbMY-Hgud_Ve; Tue, 10 Jul 2018 10:06:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 89A6C13113E; Tue, 10 Jul 2018 10:06:13 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AH5jek004872 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:05:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ted Lemon , Joe Abley Cc: DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> Date: Tue, 10 Jul 2018 12:05:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BCF78CA0739BD930ABF88DE6" Content-Language: en-US Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:06:16 -0000 This is a multi-part message in MIME format. --------------BCF78CA0739BD930ABF88DE6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/10/18 11:41 AM, Ted Lemon wrote: > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley > wrote: > > > But this is really equivalent in just about every important way to sending the normal src="https://example.com/img/f.jpg > "> along with a pushed DNS record > that indicates that "example.com " resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at > least) in scope of the conversation that Patrick is proposing to have. > > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit > > > The ip= modifier would be a great way to arrange for something to look > like it came from a different source than its actual source.   I'm > sure there's an attack surface in there somewhere. Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, this is very much one of the questions that is being asked: is there? /a --------------BCF78CA0739BD930ABF88DE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/10/18 11:41 AM, Ted Lemon wrote:
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopcount.ca> wrote:
> But this is really equivalent in just about every important way to sending the normal <img src="https://example.com/img/f.jpg"> along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're
just adding cost and complexity without benefit

The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source.   I'm sure there's an attack surface in there somewhere.


Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, this is very much one of the questions that is being asked: is there?

/a

--------------BCF78CA0739BD930ABF88DE6-- From nobody Tue Jul 10 10:10:34 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 B6AF613117E for ; Tue, 10 Jul 2018 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-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=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 3lTkaRXagycl for ; Tue, 10 Jul 2018 10:10:29 -0700 (PDT) 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 6B589131179 for ; Tue, 10 Jul 2018 10:10:29 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id p185-v6so32359786itp.4 for ; Tue, 10 Jul 2018 10:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RtdV3HVCVufDVCnq++2dHOceaWsMe1UFGNtOa00Lwjo=; b=jR5z/QXcPGTwzEoYnfKa8G6/yrPQ+SSA3mef+XV+mpfpnx8PSd1j0fxQjDtQc/jybT 9RskP7jjfTegFE4dPnmLiABjEqQndSfw0+NORmuU+OkeR3/49MdR9KGw2Rhfg7ZMjtpU TU7QDL1AVyxLJDiN2GTChqHM8M/TGfAu7K+ye18A983a7uZ93xg3UWATCxrZI6ikbSbi VCLczQjCT7/AeqUQYt8Tb7Hd8CTkmTINACM1r2l8zoLEHLHS3DcuErTJN1t73vjfw5pv F/72XkpISorNw9o/150/dsw5ef0wZHxz1yJ3rly8NxRf/7wir0bOiGURzfuB+eqyEurX +1qg== 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=RtdV3HVCVufDVCnq++2dHOceaWsMe1UFGNtOa00Lwjo=; b=o4fsaG67ei6j8IrLiVagHMv8JPKf6fecOry0RzoQNmDlpWtkKSgJZ08VO7+D6lbo/g WMYNYxjduef+Tm7RXWyaTP4KGFvM4vHdlhNzyM0ntGuQq3e04olKiswcUmikdXe4WrbA eol4xlK7cnu83wV5E0SWok0owoAFeQvXC+XzSjnQCEcpz2ztMSwEcFzkK/DmcJOGq1Cr ZkHJKDMLdFatSAwHaD7V0Y4l/ivp139HUiT0U0a58s8e2kXekoRcwiAYoi+bw4HzYaYC aj3rG7luInDil6x3o269wAcUsqXAgRTGUlfYDA00C4wJfFkuls1sRxxkMRNTp8mlF6Y6 xlqA== X-Gm-Message-State: APt69E36WTMoCIC59joVEJ5XtPxT5d4LwSuoEJmQTeAwH6yneY5NW69a H6oMk/YN/oTNMsK1y7ajzDl10s9FI+j5/inev63OCA== X-Google-Smtp-Source: AAOMgpdDByd6uGTOUoX5d/reHjvZIEsm+EVeQMfGHbScTDQ/wEgRolu9bVFgmCFJMCLSfsIhbM+6unYR0t3u30ScJxs= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr20659576jad.38.1531242628657; Tue, 10 Jul 2018 10:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:09:47 -0700 (PDT) In-Reply-To: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: Ted Lemon Date: Tue, 10 Jul 2018 13:09:47 -0400 Message-ID: To: Adam Roach Cc: Joe Abley , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000f248aa0570a83488" Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:10:32 -0000 --000000000000f248aa0570a83488 Content-Type: text/plain; charset="UTF-8" I'm not suggesting that the attack surfaces couldn't be closed, and that does seem like it would be sufficient to close them. However, we've been burned by implementations not getting details like this right in the past, so that's why I brought it up. On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach wrote: > On 7/10/18 11:41 AM, Ted Lemon wrote: > > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > >> > But this is really equivalent in just about every important way to >> sending the normal along with >> a pushed DNS record that indicates that "example.com" resolves to >> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >> scope of the conversation that Patrick is proposing to have. >> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit > > > The ip= modifier would be a great way to arrange for something to look > like it came from a different source than its actual source. I'm sure > there's an attack surface in there somewhere. > > > Keeping in mind that the certificate provided by whatever machine you > reached would necessarily have to match the URL's origin, this is very much > one of the questions that is being asked: is there? > > /a > --000000000000f248aa0570a83488 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not suggesting that the attack surfaces couldn'= ;t be closed, and that does seem like it would be sufficient to close them.= =C2=A0 However, we've been burned by implementations not getting detai= ls like this right in the past, so that's why I brought it up.

On Tue, Jul 10, 2018= at 1:05 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 7/10/18 11:41 AM= , Ted Lemon wrote:
=20
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jable= y@hopcount.ca> wrote:
> But this is really eq= uivalent in just about every important way to sending the normal <img src=3D"https://example.com/img/f.jpg&qu= ot;> along with a pushed DNS record that indicates that "example.c= om" resolves to "192.0.2.1" -- and this latter thing = is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're
just adding cost and complexity without benefit

The ip=3D modifier would be a great way to arrange for something to look like it came from a different source than its actual source. =C2=A0 I'm sure there's an at= tack surface in there somewhere.


Keeping in mind that the certificate provided by whateve= r machine you reached would necessarily have to match the URL's origin, thi= s is very much one of the questions that is being asked: is there?

<= span class=3D"HOEnZb">

/a


--000000000000f248aa0570a83488-- From nobody Tue Jul 10 10:11:01 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 410251311B5; Tue, 10 Jul 2018 10:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 pd5Yo_xuezKc; Tue, 10 Jul 2018 10:10:38 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id B2C141311A6; Tue, 10 Jul 2018 10:10:38 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 4E69C3A054; Tue, 10 Jul 2018 13:10:37 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id d189-v6so44008009oib.6; Tue, 10 Jul 2018 10:10:37 -0700 (PDT) X-Gm-Message-State: APt69E29hbkmQI8u8jt2VFu4z4O+anGFmOOEhMjFQOjSgFbrQInGRwWw NPFIheEuiGiS1o2+9we0/Rno5hvYHmV+9yBHCsw= X-Google-Smtp-Source: AAOMgpetPYvarAgMzytWSOGAzaYS4w4G0+9dAmWlEbTDFFifAbCRgeBtQrxk5XkXV6rFIFYv5O4h6SD/TywJVVVDKhQ= X-Received: by 2002:aca:5f0a:: with SMTP id t10-v6mr12880476oib.337.1531242637005; Tue, 10 Jul 2018 10:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:10:36 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Patrick McManus Date: Tue, 10 Jul 2018 11:10:36 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Joe Abley , DoH WG , driu@ietf.org, Philip Homburg , dnsop , Patrick McManus , Paul Wouters , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000007199da0570a835c8" Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:10:52 -0000 --0000000000007199da0570a835c8 Content-Type: text/plain; charset="UTF-8" yes; and.. dns has always provided a point of indirection that is useful. dynamically rewriting markup might be infeasible.. and many fetch() like things are driven from script where the markup changes are not obvious or perhaps ill fitting.. and of course there are questions of cached content that might like to late bind. so lots to think about; but the markup example is very illustrative of a very conservative way of scoping things. perhaps too conservative. worth exploring. On Tue, Jul 10, 2018 at 11:02 AM, Adam Roach wrote: > On 7/10/18 11:34 AM, Joe Abley wrote: > >> On Jul 10, 2018, at 17:22, Adam Roach wrote: >> >> Basically, you're describing a solution space that could be realized as >>> something like: >>> >>> >>> >> Ok, interesting. I would suggest considering a richer scheme that >> accommodates address families and multiple addresses with priorities, >> but I see how that kind of thing would allow a client to do so >> certificate matching and resource retrieval without using the DNS. >> >> But this is really equivalent in just about every important way to >>> sending the normal along with >>> a pushed DNS record that indicates that "example.com" resolves to >>> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >>> scope of the conversation that Patrick is proposing to have. >>> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit. >> > > In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > /a > --0000000000007199da0570a835c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes; and.. dns has always provided a point of indirec= tion that is useful. dynamically rewriting markup might be infeasible.. and= many fetch() like things are driven from script where the markup changes a= re not obvious or perhaps ill fitting.. and of course there are questions o= f cached content that might like to late bind. so lots to think about; but = the markup example is very illustrative of a very conservative way of scopi= ng things. perhaps too conservative. worth exploring.

On Tue, Jul 10, 2018 at= 11:02 AM, Adam Roach <adam@nostrum.com> wrote:
On 7/10/18 11:34 AM, Joe Abley wrote:=
On Jul 10, 2018, at 17:22, Adam Roach <adam@nostrum.com> wrote:

Basically, you're describing a solution space that could be realized as= something like:

<img src=3D"https://example.com/img/f.jpg" ip=3D&= quot;192.0.2.1">
Ok, interesting. I would suggest considering a richer scheme that
accommodates address families and multiple addresses with priorities,
but I see how that kind of thing would allow a client to do so
certificate matching and resource retrieval without using the DNS.

But this is really equivalent in just about every important way to sending = the normal <img src=3D"https://example.com/img/f.jpg&q= uot;> along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to m= y understanding, at least) in scope of the conversation that Patrick is pro= posing to have.
My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit.

 In large part because DNS provides "a richer scheme that accommodates = address families and multiple addresses with priorities".


/a

--0000000000007199da0570a835c8-- From nobody Tue Jul 10 10:32: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 CB97D131194; Tue, 10 Jul 2018 10:32:22 -0700 (PDT) X-Quarantine-ID: <9TF0ePKQLBHg> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" 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 9TF0ePKQLBHg; Tue, 10 Jul 2018 10:32:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 4DE37131188; Tue, 10 Jul 2018 10:32:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fcwUq-0000GvC; Tue, 10 Jul 2018 19:32:16 +0200 Message-Id: To: dnsop@ietf.org Cc: Ted Lemon Cc: DoH WG , driu@ietf.org, HTTP Working Group From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-reply-to: Your message of "Tue, 10 Jul 2018 12:41:46 -0400 ." Date: Tue, 10 Jul 2018 19:32:15 +0200 Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:32:23 -0000 >The ip= modifier would be a great way to arrange for something to look like >it came from a different source than its actual source. I'm sure there's >an attack surface in there somewhere. That's a rather fundamental issue. In the context of TLS, and a DNSSEC insecure zone, there are two realistic attack scenarios: - an attack on DNS that returns different addresses for a DNS lookup - a routing attack, that reroutes traffic. Both types of attacks are realistic and happen quite frequently. If we decide that TLS is strong enough to defend against these attacks, then there is no need to secure the DNS lookup, other than to reduce the risk of denial of service and for privacy reasons. Then such an ip= modifier would be fine, because the worst thing that can happen is denial of service. On the other hand, if we don't trust TLS, then we have a bit of a problem. Too many people using public resolvers. Route hijacks are quite easy, etc. From nobody Tue Jul 10 10:43:44 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 7CDE4130E2A; Tue, 10 Jul 2018 10:43:41 -0700 (PDT) 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, SPF_PASS=-0.001, 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 ijkJQZp9F8T7; Tue, 10 Jul 2018 10:43:40 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E600E130E25; Tue, 10 Jul 2018 10:43:39 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 475DB47A1C; Tue, 10 Jul 2018 13:43:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23364.61514.267429.409048@gro.dd.org> Date: Tue, 10 Jul 2018 13:43:38 -0400 From: Dave Lawrence To: Paul Vixie Cc: Patrick McManus , DoH WG , driu@ietf.org, Ben Schwartz , dnsop , HTTP Working Group , Daniel Kahn Gillmor In-Reply-To: <5B447154.5010307@redbarn.org> References: <5B447154.5010307@redbarn.org> Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:43:42 -0000 Paul Vixie writes: > > For example www.example.com pushes you a AAAA > > record for img1.example.com . Should you use > > it? > > no. sibling names might be delegation points. kashpureff taught us this > in 1996 or so, and kaminsky reinforced that lesson in 2008. > > > What if it is for img1.img-example.com ? > > certainly not. In the large I agree with you, but I think there's more to it than that. If it pushed me DNSSEC records that I could verify myself from my own configured trust anchor, why can't I trust them then? From nobody Tue Jul 10 10:49:14 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 754F5130F04; Tue, 10 Jul 2018 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 xOGYiv7ez31c; Tue, 10 Jul 2018 10:49:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E836B130E25; Tue, 10 Jul 2018 10:49:11 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AHn3N8012043 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:49:05 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Philip Homburg , dnsop@ietf.org Cc: DoH WG , Ted Lemon , driu@ietf.org, HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: <711c1727-eb43-c90a-60ab-fa3580786c1d@nostrum.com> Date: Tue, 10 Jul 2018 12:49:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:49:14 -0000 On 7/10/18 12:32 PM, Philip Homburg wrote: > If we decide that TLS is strong enough to defend against these attacks, > then there is no need to secure the DNS lookup, other than to reduce > the risk of denial of service and for privacy reasons. Then such an ip= > modifier would be fine, because the worst thing that can happen is denial > of service. To be crystal clear, my mentioning of that hypothetical parameter was part of a thought experiment, not a proposal. /a From nobody Tue Jul 10 10:54:51 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 DDB90131127; Tue, 10 Jul 2018 10:54:47 -0700 (PDT) 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, SPF_PASS=-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 ClqI2j4IIiin; Tue, 10 Jul 2018 10:54:46 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D86130F04; Tue, 10 Jul 2018 10:54:46 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id A77A547A2B; Tue, 10 Jul 2018 13:54:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23364.62181.661312.974644@gro.dd.org> Date: Tue, 10 Jul 2018 13:54:45 -0400 From: Dave Lawrence To: Tim Wicinski Cc: Philip Homburg , driu@ietf.org, dnsop , DoH WG , HTTP Working Group , Patrick McManus In-Reply-To: References: Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:54:49 -0000 Tim Wicinski writes: > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" > > My magic 8-ball says "signs point to Yes" I don't grok how y'all got "trying to re-invent DNSSEC" out of this, so this is sure to be an entertaining discussion. From nobody Tue Jul 10 10:55: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 A60211311AC for ; Tue, 10 Jul 2018 10:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, UNPARSEABLE_RELAY=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=hopcount.ca 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 viH4XnlkxC2P for ; Tue, 10 Jul 2018 10:55:15 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 4EFB613119D for ; Tue, 10 Jul 2018 10:55:15 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g6-v6so8357744lfb.11 for ; Tue, 10 Jul 2018 10:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=sF4IEOEnumrGo/yi2tqGj8F3dwK+tpMgwcqiDCKJKl4=; b=EljV0CzUdU62DwwA/LkkGrNLyDMgjvmg4JksfnuJDyYZ6d7gIsqpdC5N5KpqRVKAX2 wN2trsSDJYeA7GkMXC2mkw0bS37Ek+D+HCrsKYn25N27d0kQ7CSG2jb//ozbFYvK9Aen o4gMXQYb4OPo520J9mlRC2KgBqcZRfdETNBW4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=sF4IEOEnumrGo/yi2tqGj8F3dwK+tpMgwcqiDCKJKl4=; b=h7j+sYE3TO1k9VB3PlpB7bDrZVU2CuT3pjtOhe2ShvvTsukefhehWH4C/Z/iWT8pUS J97hXHZ5Mj7pWCmCmdTX7oBJ/VTiTv7BZbMazZnZLBVv3bRAHdzfh1jAzherE5Ukl41A wbJ09+jwddyo3sXVAzzu56CRhHAQhfLc4484GJ4coKEy0DsdJ7jBcjFLfV+1MS+dRcM6 1BxFeNXnryGDYyZQC1mAwKfSZw8NopXt2yJFJGekUz3p5JWMTix+EcHCDV+R+onNwVyj 1gEGWnvBtgXUmiCL+tGMsfyGMYQldtSicXBt0XN37U9Xi0AF0iyStbJiGLqYR6zRd7l4 Xdqg== X-Gm-Message-State: APt69E34cqKYofG0Jy5T2XiQRzg+A2ZfHsie38v/5RLfatIh2rCYt7K1 MpmUsXrA8J6vL4zASSUZKqi5Vuiv/4cXsw2sCR3gug== X-Google-Smtp-Source: AAOMgpf/9DI2sFOajwIAFlN0P4GAjsxAICfwuN8MqrD5JceBfw+f0+VnTTE8sVDIZrhSDgEcFyGi83OGdBtyG5OqTOo= X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr3433424lfg.83.1531245313554; Tue, 10 Jul 2018 10:55:13 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 10:55:12 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-Reply-To: Date: Tue, 10 Jul 2018 10:55:12 -0700 Message-ID: To: Adam Roach Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:55:29 -0000 On Jul 10, 2018, at 18:02, Adam Roach wrote: > In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". *cups hand to ear* Was that the sound of a distant desire to specify use of SRV for HTTP? Joe From nobody Tue Jul 10 10:57: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 C2C13131017; Tue, 10 Jul 2018 10:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 Pf7cJMXCejwn; Tue, 10 Jul 2018 10:51:57 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E305B130F04; Tue, 10 Jul 2018 10:51:56 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 785576001608; Tue, 10 Jul 2018 10:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=RhhEoZ408ThwhoEVDri3uLd8KdA=; b= NcZ6oVC9iC0n/haNfPuiO056XcNWFnwSA1nBGp9uMDaxH3HDe3uK9SXCjXQPw2X+ QnfZ+PeRhmFI/nfLTKGNkw/rDFPz4jYXYnZKIyq4tpXNxYXomhQZ/8LCC9nN5toZ MdBDhm20eyjTavkTusJXb8v4JFPNslHTjiGuVwdaE3I= Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 533D16001602; Tue, 10 Jul 2018 10:51:55 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id w16-v6so10403592ita.0; Tue, 10 Jul 2018 10:51:55 -0700 (PDT) X-Gm-Message-State: AOUpUlF0uDdKGztHj7e0ENyZG4abAUluV1xMFcLjpCeLvicrUV9tZx5P FzC/EZ05ulab+CvgvWbdelOMlgRIVtMA4zyohKk= X-Google-Smtp-Source: AAOMgpfuksUe3Ga9juzC5CUfobAyFAYv3gmOA6kuj2PLZqAxznoaKVgCcwYiLYtmDX0wdZMyFG3H8QfVpjwvaq4KoGE= X-Received: by 2002:a24:62d0:: with SMTP id d199-v6mr7502623itc.91.1531245114637; Tue, 10 Jul 2018 10:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:244:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:51:54 -0700 (PDT) In-Reply-To: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: Ryan Sleevi Date: Tue, 10 Jul 2018 13:51:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Ted Lemon , Joe Abley , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000001f45cb0570a8c9ed" Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 10:57:17 -0700 Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:52:01 -0000 --0000000000001f45cb0570a8c9ed Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach wrote: > On 7/10/18 11:41 AM, Ted Lemon wrote: > > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > >> > But this is really equivalent in just about every important way to >> sending the normal along with >> a pushed DNS record that indicates that "example.com" resolves to >> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >> scope of the conversation that Patrick is proposing to have. >> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit > > > The ip= modifier would be a great way to arrange for something to look > like it came from a different source than its actual source. I'm sure > there's an attack surface in there somewhere. > > > Keeping in mind that the certificate provided by whatever machine you > reached would necessarily have to match the URL's origin, this is very much > one of the questions that is being asked: is there? > > /a > Yes. Consider Site A (foo.example) and Site B (bar.example). Both point themselves to CDN 1, which then obtains a certificate for both their names in subjectAltNames. Site B then decides that CDN 1 is an unreliable partner, and goes CDN 2, updating DNS appropriately. This is the same problem in considering the HTTP/2 coalescing without doing DNS resolution (either because of poor security posture or by combining ORIGIN + Secondary Certificates). RFC 8336 briefly touches on this ( https://tools.ietf.org/html/rfc8336#section-4 ) but doesn't really explore the policy implications of the proposed or recommended mitigations. If you start with no mitigations, the net effect of both an ip= or a DNS-ignoring ORIGIN frame is to effectively treat the certificate as a 825-day DNS TTL. By framing the problem as "What's the worst that could happen if DNS entries had their TTLs ignored and were cached for 825 days", that might help explore things further. The suggestion of OCSP reduces that TTL to 7 days (effectively; due to Microsoft's contractual requirements on publicly trusted CAs), but that's still substantially longer. That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, considering that the CA only has to validate a DNS once per 825-day period, and can issue unlimited 825-day certificates during that period, then the effective extension of relying solely on certificates 1650 days minus a second. --0000000000001f45cb0570a8c9ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 7/10/18 1= 1:41 AM, Ted Lemon wrote:
=20
On Tue, Jul 10, 2018 at 12:34= PM, Joe Abley <jabley@hopcount.ca> wrote:
> But this is really equivalent in just about every important way to sending the normal <img src=3D"https://example.com/img/f.jpg&qu= ot;> along with a pushed DNS record that indicates that "example.c= om" resolves to "192.0.2.1" -- and this latter thing = is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

My question is why you w= ould involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're
just adding cost and complexity without benefit

The ip=3D modifier would be a great way to arrange for something to look like it came from a different source than its actual source. =C2=A0 I'm sure there's an at= tack surface in there somewhere.


Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, thi= s is very much one of the questions that is being asked: is there?

<= span class=3D"gmail-HOEnZb">

/a

Yes. Consider Site A (foo.example) and Site B (bar.examp= le). Both point themselves to CDN 1, which then obtains a certificate for b= oth their names in subjectAltNames. Site B then decides that CDN 1 is an un= reliable partner, and goes CDN 2, updating DNS appropriately.

This is the same pr= oblem in considering the HTTP/2 coalescing without doing DNS resolution (ei= ther because of poor security posture or by combining ORIGIN + Secondary Ce= rtificates). RFC 8336 briefly touches on this (=C2=A0https://tools.ietf.org/html/rfc8336#sec= tion-4 ) but doesn't really explore the policy implications of the = proposed or recommended mitigations.

If you start with no mitigations, the net ef= fect of both an ip=3D or a DNS-ignoring ORIGIN frame is to effectively trea= t the certificate as a 825-day DNS TTL. By framing the problem as "Wha= t's the worst that could happen if DNS entries had their TTLs ignored a= nd were cached for 825 days", that might help explore things further. = The suggestion of OCSP reduces that TTL to 7 days (effectively; due to Micr= osoft's contractual requirements on publicly trusted CAs), but that'= ;s still substantially longer.

That's why involving DNS is at least relevant = to that discussion, especially given that publicly trusted certificates are= themselves predicated on DNS. Further, considering that the CA only has to= validate a DNS once per 825-day period, and can issue unlimited 825-day ce= rtificates during that period, then the effective extension of relying sole= ly on certificates 1650 days minus a second.=C2=A0
--0000000000001f45cb0570a8c9ed-- From nobody Tue Jul 10 11:04: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 E7A21130DCE; Tue, 10 Jul 2018 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 EUDVnpcX1F59; Tue, 10 Jul 2018 11:04:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7C4E8130EAA; Tue, 10 Jul 2018 11:04:29 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AI3sKm014543 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 13:03:55 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Joe Abley Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: <3c8fd080-7f67-0e3c-7754-6bba99593873@nostrum.com> Date: Tue, 10 Jul 2018 13:03:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:04:33 -0000 On 7/10/18 12:55 PM, Joe Abley wrote: > On Jul 10, 2018, at 18:02, Adam Roach wrote: > >> In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". > *cups hand to ear* > > Was that the sound of a distant desire to specify use of SRV for HTTP? > Speaking personally (that is: this position may be at odds with any number of organizations I'm affiliated with), I've been sad for a very long time that SRV didn't take off as the entry point for doing all name/service resolution. Maintaining a service-to-port map in 2018 seems as quaint as if we were still having to manually set and de-conflict IRQ values on PC peripherals. This is way off-topic, though -- if you want to continue, find another venue and let me know (or we can find a time to commiserate over beers in Montreal if you prefer). /a From nobody Tue Jul 10 11:06:55 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 3A1E51311AC; Tue, 10 Jul 2018 11:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 UqvW2mI-7258; Tue, 10 Jul 2018 11:06:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 383F3131197; Tue, 10 Jul 2018 11:06:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Q9BB1sRdzDxn; Tue, 10 Jul 2018 20:06:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531245986; bh=ipe99PE1mtID2UiBeg7F2q4Oe/TvNf1WQj5tJNMExN8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b8Ag6jaxNY7S5SKl/3F1mGlD49olR02jzRGr90iIUfU/0PC8slGwA23DKFsD2X+5O 3zL3ztjvVc6RT4enU2a0avgFUJ+EEul938BqyOwjYdLe+NSJ4b/rrLlkR+/xP5ovEi 4Jn9iMw1FsJocI2fjECnj2tDeIwguzAN6OrmCGnk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Z1WHnhGjpDV8; Tue, 10 Jul 2018 20:06:25 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jul 2018 20:06:24 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F3A6941853B; Tue, 10 Jul 2018 14:06:22 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca F3A6941853B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EECCA40008AB; Tue, 10 Jul 2018 14:06:22 -0400 (EDT) Date: Tue, 10 Jul 2018 14:06:22 -0400 (EDT) From: Paul Wouters To: Ryan Sleevi cc: DoH WG , driu@ietf.org, dnsop WG , HTTP Working Group In-Reply-To: Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:06:46 -0000 On Tue, 10 Jul 2018, Ryan Sleevi wrote: > That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, > considering that the CA only has to validate a DNS once per 825-day period, and can issue unlimited 825-day certificates during that period, then the effective > extension of relying solely on certificates 1650 days minus a second.  This of course, is only an argument in favour of DANE depricating WebPKI, especially in light of the EV failures reducing webpki to only DNS already :) Paul > From nobody Tue Jul 10 11:08: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 D947F131192; Tue, 10 Jul 2018 11:08:22 -0700 (PDT) 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, SPF_PASS=-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 T_55XYLCj-aX; Tue, 10 Jul 2018 11:08:21 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B2C131184; Tue, 10 Jul 2018 11:08:21 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 7E7F447A42; Tue, 10 Jul 2018 14:08:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23364.62996.452097.286863@gro.dd.org> Date: Tue, 10 Jul 2018 14:08:20 -0400 From: Dave Lawrence To: Joe Abley Cc: Adam Roach , Paul Wouters , driu@ietf.org, dnsop@ietf.org, DoH WG , Patrick McManus , Philip Homburg , HTTP Working Group In-Reply-To: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:08:31 -0000 Joe Abley writes: >but collapsing the address selection back to the extent that you can > avoid name resolution at all seems like a better end goal. > > So rather than resolverless operation, think about resolutionless or > nameless, eliminating the DNS as unnecessary overhead. > > Perhaps I have misunderstood the whole problem space, of course :-) I believe you are spot-on. From nobody Tue Jul 10 11:11:21 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 1D7CD130EAA; Tue, 10 Jul 2018 11:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aclu.org 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 jS65edoFRZLQ; Tue, 10 Jul 2018 11:11:02 -0700 (PDT) Received: from dkim-ny.aclu.org (dkim-ny.aclu.org [38.109.115.175]) (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 D4345130DCE; Tue, 10 Jul 2018 11:11:01 -0700 (PDT) dkim-signature: v=1; a=rsa-sha256; d=aclu.org; s=hmailserver; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=tLoYkAnIQGa8WxIRuDX37fx/3xBPYoWvVfFxtOfDW/I=; b=YyQzIdps+9s26TWujvtPnybpmjsk66qbj3D8GELCB6D43oTt43f2SvtIYOcBHk+KeZ+qQRfVV+3+UdRq4aH1ZaLTKS6IEkkK7xN2Yogbx9PrL0n1f9J+c0bRBHKEvuSoP1zHkTTOfUsfAt9fZTEfQvlNLxrSeI8uSNv16ltTPlHRHJxVEt3HAOj0RtCYbpIB1Qg/sdajN8QRY71Rijw4ggE0NJnufiyVvdxbdS3glRc1skjSzpK5TQ3h4H jSk/vYkn4+cfCIGwxiXlrv2G6KPN4r5Qc87UUwduCpTQAI/D9DcPcCVkxZsNUydNvHd4N6/eTm1SDyiFYCY8bnIekFgw== Received: from vtvsmtpout.vtv.aclu.org (nyvtv1s.vop.aclu.org [10.70.0.186]) by dkim-ny.aclu.org with ESMTPS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256) ; Tue, 10 Jul 2018 14:10:50 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (localhost [127.0.0.1]) by nyvtv1.vop.aclu.org (Postfix) with ESMTPS id 958FE2E2B70; Tue, 10 Jul 2018 18:10:50 +0000 (UTC) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=dkgillmor@aclu.org; Received: from [127.0.0.1] (38.109.115.139) by BYAPR01MB3653.prod.exchangelabs.com (2603:10b6:a02:84::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Tue, 10 Jul 2018 18:10:46 +0000 To: "Dave Lawrence" , "Paul Vixie" Cc: "Patrick McManus" , "DoH WG" , driu@ietf.org, "Ben Schwartz" , dnsop , HTTP Working Group References: <5B447154.5010307@redbarn.org> <23364.61514.267429.409048@gro.dd.org> From: "Daniel Kahn Gillmor" Openpgp: preference=signencrypt Autocrypt: addr=dkg@aclu.org; prefer-encrypt=mutual; keydata= mQINBEZhxjoBEACtXku9A/xHl58dAVmeiuPzFvB2K+8iqwDjEZRUH+1l8ZWG3Gb81uMsRPf5 PDJCJKRH0ATJYId3ynfdjxjOZC981OdbvRslX+pvIZOXMoK7nSzrvC7CYAyVRUDGikAK7YNj KDdRrQDzSwcuzQOm+BpabYcU7t0k7p/mD1t1P1yIio1WTA5HOlo5+I+rkWtwuIAJCVeIkZOY Lso2K8qY1Xy7VEdFXY+fltaeblEvLjJfOKkUnzEyeNfPAX0QwcGZuMrcBQiLj3KWNrKZNFf7 tzXC2wOVU7Vf0Xt7nuLppAKhHXMr5RbkBWOJFiaKtUqLBfMgfcIyRj3eIppMNgTcWQMcSLD+ L8eUW8MflPsZPnXG85z3an7NzvrEPQ0R/Fiu9Vk17YoHFvVi61YwSl9VA3fLMN6oDghCu5qb PgnyvDtc9tV9qmA4RnKmc9hiR1U3vtD1W7r36K2Zx11krpccZcmZUo1NN1Bjops91AdKqhJo DxW82MssRJ8fIbI6xi9wYgtAH2pLrKP8pW60vDqBxufyHYvethKnRrMh1QiOTG1yHkpN2n9e 9smjOgPBR94F0N2eDar+GSmy3JagZgH+VWXFpZO5u508RU5UGia58LPs7wjstSAOB+NSUs/Y lxxJZHKWYQ8tzPfUxKHEAczpaIC90k1FvoJPa2NPAndMkJrpNwARAQABuQINBEZhzy8BEAC3 Lukb8Fj331u9R7u4Pt0PqFWS1ARju2ooSq/13cYnpVAleaG0zJ1VI1uVtOR5b5Wmv9RgTCaJ W+Pfn3eP/O8+ULrorc5gbPw//7zMDpQN3AeHB5LYKrNv13m8P1dx/v17BaS78jmgfF/gh02b EqQDxb+D0O9G13GX0xR5MlPCG+hj6b7Exf9nqn3jTmKcdJxalpAFt4XZFyNg1PTV2yVWAq4h 7YsUQP1dg7PNi2T4jrsO9nFCl8OTtqveiT5gLDecXjpPWRx8clMB4plISITo8ICNYb6tiCH3 zwn25sTI9TfAL+4YUtqjY7U2/yB/QHmDMryc0A8PIeeVE+mmYDfVAk8kwuuXEVSTOBosP/BX wqeT6s2fdsuPXj/q/b9lruIMnoX6rPVCbax/Dw5bVMhsCRBZahWJIGkI/b87w2bUGfr7en8E mz2jSoKjpwFyQ8HbT84/+wLDh5bFOzAMxmHpN/S3LcibzFK5jqazASnZYx3sMJuZcQ+FTcja NcqlM1RF+CrQuYymVDG7Wn6Z/6N8lpqVFWWFvB2/UPNmf1fW0fIQjqZ6TcmNdVpxyTA/3RGZ gfuK5tcfrPiCCeOdZB2aA4As/Bd9d6Py7USPQFTvRwPVoC1vG1MF9Vgv0nqg99c3SI1mQhi5 +bff6gm31DPp6PVjQjwQqFa65Sg37tfmbQARAQABiQIlBBgBAgAPAhsMBQJPS7pfBQkOjYWr AAoJEMzS7ZTSFznpWWsP+wZ90xzlIPKzHKKJPVcz4mFbsTKwgvSfX/e2t0FM0z/gyOI9U1WD Cowa5X1zMuJX6OVaZkQSJ2p3+JyWRNwQfdisuF6lgB4UnGuxh2WlrDU7s15X7ljK0ylxo7lH G8FHegcztb69d5uTXq+KUcLxxzSYequjRhdsBNZvxATG9i23Y4WyLeneuRIugwHRSWL8T9p/ JWsQKqfMXhdZpbDl6pDrRGGhBY+6B78MxiHPDjgyuHKC3PMAyv7pkWKFuOXqZLwpJG2GTI+4 YKCTf559fk04b3OC/rj6rEek46wOhyL8VQxwLpmLO4mAwqxE46vKEJSPuZyIF76AU4vcM7lE 2Ag2/kZFKlzMqevevcT/mjUsU6U8jz8KP6ThKcx10V+z5LEWu+pXC05dhSfWXkq81uWw6WNZ APGStosAsx/uhxs7O8poqlzECauKjR3VK35spja/mloJiNRIxkvDJSd7TNQejO3p9SZSCzIt qYBvU13ILyBJtQMltj61Ii8pvr7k5ASgsQVa5Eq2ihxJHjA7ddQSF1P42JsBBPzs8nDIkCbl YYo4JGhMvdfbaZyxcAO7m2KHDa53AdZimswz/mwMvu6wKVja+77CGdQQaLSmpyI0HbjA+JrI HDRENVwkVJLxQzc4ODgE+OxpSGky5jjeyFggni+n2j8ZnMlN58tBQb5SuQINBFE/lkQBEADp A5aaDkUui1K7Y6xspi3RTqxpsS02J517ciYBsaCv+wx7HLYv/O3EJ1JLeBnEEM+llSN61a7h EPCujCKE0hG02PuEZP5wHnq6rgUL6olXyayulhyMUXBukymTZtqS60WnF09NYUxNK9XoMv4W PaHSGPlte87FJZ5lsf31a/2XQldHZvk+JG4Imv1079rgUcK/HWwDPBBhjrk/Om9nqH2IWPCd FA/t4gDqO+B9gBjHuw/T8hHsbRbHj74GuXzdsR1LmYmC7xUDrJynEhOKl1U8eEsVKSvev0EB bIYi2So/giRybMX0BMR+eY4JA+XprvLesVFfbdVXHnDPCq1rU2Tw14MuGy7h64sM9HbvUG/h F+Ojeo/Dz6jMx/tiU18pupXclRVP4JBzAlJ/0ySXy0mHOgcI/nAXW3te249+YUwwHZpjafaZ H9Dz+wIWOO1mbonNcV4AryJhh0UogXitIoaNHZpsQ0UEafKmO8uHxBE1DEy8fs173UiWLoYm knp/IbPlWx8wxZk4B1QrJsj43ldLYM3brpTpXBdEmm2k7fBo37tjNIPAIeZA4P6JTkakJ/ai cAyHvzLzCkIC4fBrpRpjh2LCxi2pZYXsVxSi+7Mn1nh/OnuatT5KguhurdoDxoFtHsEuw/iV idYoC35c7uewVPHCHq2sneXpWPGrR+zpewARAQABiQSkBBgBCgAPAhsCBQJUwBGuBQkFYa7q AonBvSAEGQEKAGYFAlE/lkRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBn cC5maWZ0aGhvcnNlbWFuLm5ldEVCOTY5MTI4N0E3QURERTM3NTdEOTExRUE1MjQwMUIxMUJG REZBNUMACgkQpSQBsRv9+lx3lA//QWlgqZLtIr9JHLQXu678qkzRcul7SQgejeOUYR9MkVuF gWiZ6iZs28lUYWveI60xvTdFBgEyeq/qNnwHPtXRN5gLdycQT34zq0YSGLM6S6NOpkMy8gxr SB36mesC0Ok1RHT9GJ8HVTAQeiO7TxKkWIJhxM4rmcgLQ3NGu/8vysUZMO2FMERINh6FRjCM Q4Uu7lPMs9rfWQSUjEj8lZtzHe0Hty6B6IXT6gjDkYJ98K50DfQ/J3odCItbnRvPNzGGx59z aLTpeSAtC3JD9hejL0i1jJoIn6Nl4tv6O5RnkQircHclssIxZx5JiSWVNh6wx9Xgc499uhKg SOA6pQVpRU8+MrxknjM5bH0APTTLGzJGmlACPaY3smuxNwcR5Lp07geoCSBuEZ/9nKggep6b EHx65HI+iHB4FmWfeFlSa9KBQKIYhnGB+dNuslad+39LZhbiKM7mBHIxT9rlapJMlUulp/4V G+RtFwWJC4aGAG3lX7pFxsPunTZ9kzqkFNQpxQNFl1pF9LQ7JJCuhDQ2rzOd+GHRXNlNge3l UVyei6svtkX6rYy4C6uGkD9Mwqkp+OagxlglqGVMdnhYDgmvwKP8AsC7s43BIEVhba1YZh4T 2SaJUH6xVb901MG5Ag0/oQx+cszaaBJX6nULElHYradMjSgPcexZfCOB7WWGfOgJEMzS7ZTS Fznpq2cP/1+kRBtlh5yhnFPejvkmiFEKI02rd4aPKmlTxfBbRPm5looLAyqiiD7CQf0s6fbH FytZulKd2OneM206i/sH1YqQ2hJ6EsZBMKW7+2NNI3ExBwtH21s1h7kZ4+qyoDB0mAnrg6Wj qGGU9HcxNKe2iHzgqdOzsE6TL87Or3ig7JAg2r2wFRBJtCmrBMDDdfJU61sgjyPYrehqnIMv xt938jNHfCRb+l/qY987YXxgMObWPqf+TKIRQlErXY1qFKJFXw8w1tQA+SgcbfJH8wntVCLm q/jA/JX19Gr03soweXxlQbF5Nbm0EdeIjLYTBaOXelIkJlb1zaEU/4N+djX15/z8dh1veLwD AI9JlDdwKzeMAPhi+xuJE+NmERvrJllpbS0oOa4A6dfW3kEQmVYPFJCoS6sFhO8pqFNwty4C dKTg8FBbV6II75RPu239ZIAk630DuToksj4TYn1ZMAbFmm0DHakWIO6ja7Rugr/CI20ih7JY dAqshIAXPjL47p0Byjp08rQTQQh4Pun543lScKdGBWY9ARRpkl3MMBhAeiq/2t3ugTQGXKxd tq5V7vYg2yAGzHZhSpCOCUpA/eztNzS4LCe/LWAb77U39cvhn3pmBjVQlKbTcrhv8nOGEByg MoMqPScH4w8ykfkrZ3QCiRFkeBcvxKE3DVb8zQ0WvzDBuQINBFTAEbUBEAC0hrSG46djsoFv Me/9AIQBXvLXedhEpPYIEgj89kgVogrkZH2J1uaF/QtfLq7/FfQBYJkpOJnMaVrre7sF2GMO oPOMKsoxpVQzaXBOIY9jBclhky8iDffyqkXiwkHEzYnbmcz+uSLHwjubaAjFV/yXDFa2ric2 dmpbfggVv3zj6H7sa2Rlj5ifsyLla1p9qckTEv65JhJhP4VnHIknC89EfX3UppSzdiF5T6Xi qUYRTRT+vvKOkVN0/eAy5rv24nxIKy9vKOwdSnGTVwDzhq8db0VtIWRyGXbXd0vw+2xcVEoc uXSkmRMNkP69PIB1GvZ5YKON3K9npxk55IXWCFWYyP71Qu/AzOKONyAFUHtQp5j5VKKWt5Vl XtV4aDYAxC+JhJoad6zKC0XdiKYZCRWIqFjyKFe6tkYjK67oqBrlPhDJybAciluEsbhxmY/5 3yRAxyGnQIiKTFiM6gMLNQFD9UH5BqaxNnL1W0DHOK3wTMH0nAHd+6+omOH8TWp69UP9MR+O d8pTmryUCir1xfhdHsRlLR2hg66qn48XP2USDyddL6eNODUZi3x7/1N5xpjat37yZCja1sn5 bKINdJr3BResowKMOSsXktjqxsZop3u+eYCcH8H7JiJax+1UrafYPGJjfya3TiYKHU+HWQkB WratKshUTDkPIBnMB1QB7QARAQABiQIlBBgBCgAPBQJUwBG1AhsMBQkB4TOAAAoJEMzS7ZTS FznpsrUP/2b8h00MxwBVi9rF5e78Zpp8G5+/jOBUYF1Uu4cezyAVqQ1WgHVLOR4eFRIEdU5r 5wiK4s1tWnGM8mo4/K/124H7PXxZO9B62cEcZGrTs9AU1+iYI9ZW6a15LHTLdbOzxYahbA+I XRawHbwOLiVSF/pAme8lMXmt4dgpBF0YbdjGMmNcdgGWWAEUbGVLkuowudyG6AtSa9WeFGxv fz3ugCAnusIAVoICYPj7nl/5Ig166Bqzr4DouC7ewjI7hve2VxQ+S86qXKH/utmsyN9oF9fN RUHqkqQ3076IQDNl340DdUdO6u7GZ+9YggpovCR6qCUgy4A8PFy8gO7SIaPtvjIeS9Cseh6U W1gkTf+J/jzU3x5H+iaWuS/aQdNWCdkAfW+KX7iLFKzR8UxDdSWEjYTRvPeuKmbMVuzy2v0s 7TvgM1W/jdMp4J9jSfoVaU+CKD9UTBi8HLfOw/Br2r229b4gne8kPt06jJ1mBH+FxWJNbA36 WoHvbkcXMrQgJVmh6DA8G0QMrnpdY3uhIBMLYX+sk3W4fW1SU4GVDC7G0wHZ20R6tnALxt78 LWmL5t9ddheQppcvey3MZNH4rD6JtYojQYLrDRWY2I8D0sA7T891jIqlk9QUDaz2wQnHrPMR sXFwT5onzIfS+RaxPnpX6KGKpyOHZ/8LyfDYeuQXsvzguQINBFaLZa4BEADGpuoE0MZ35zVy 3I5R4DyRkyd+NX+Qitp9oZiU8HC6ZbyUbwUNe7f2IuR8RCczdWC9ObGdU1hkR4ZcRwhaX43V aEba48K6qmLr7HoqgQ/CyH29zcwFbV50j4h5/X7jkVx+hSRZqq9B9lZRgtECRYQpkZtMuj/T 87UmdgHQ/PU1oCg6ZfQrNW5/21R+OI2JXvUiujZf9ql4Uf9L9TYRWU1IroBl9oTVOOffpoqz 3liJhpFEs4fsltfryFkeD7rRFB70ag/dVBFJnynWX5MUPvBESIv7rCZSAGf0rJjfPT2SwGPW LQBTVFtvIXj+wEUNwGu2o27nL7iNUCIoq04o9mPuNRgs0DInyiPJWRJ0X1iMFxRC+HTb0lP2 cFsglOMBJ8bcJLleDiywbUvcAO12L7tXixMRJpsI9K3KU+0ej20mRFcryZamZ0zxNeSzrCBK QTF4v1v0eDWakZREfNvh1HZA64N49q4pXmEujF3QlOM3Lx9xuI5VxjG0+0/WPdwNWQwknVtF YysXWOFSerT4e+gQxq8MDDOcgfM6eZmQxKpxRXCiYD/Sn4CuMNUsB9pH75/yyZutPq608t0Y g4aWcmQi/8wc+9Nqm6L1xaSGu1ChZk9xGRWthsRxFejQdqXi0Ckqg7ehlgBsGQ5+dkAaCBGj xMjGSd9chm60/Q4tRXYOAQARAQABiQSkBBgBCgAPBQJWi2WuAhsCBQkB4TOAAokJEMzS7ZTS Fznpwb0gBBkBCgBmBQJWi2WuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5w Z3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUyNEVDRkY1QUZG NjgzNzBBAAoJECTs/1r/aDcKcScP/13A6XNGNwJyqqR5popjPYHX3QRLFFiKnqHlz24ocZuG CCY9xDHmdE0+2VMvqaJzER9uPokITcdImoTYjPX6pWmhle+DB8pgOX129t5ihJAg2sduEtjb /9OtBQBaw0IDU+X5qNGDWXTwjs/rw1FAi0QLqZRgGsdiZfEKrYjdrvG0c9Y8sbyiCup01vZk /9LvgpImxX6mLU5CBAoSV/KwqNawETowfavCoqxi34un8dEYuBVqjLsAmLS+fQSpFyHNhejO PF0Qw8B8/SWxQ/53rXMWDX5zQ6COtfCB1aexa/D6dDd8tP1l695+dNIStu6gjAtnl/w5Xy5p uyt10FOWDWS8OhjLbZp+QwnzRVJdvG/hTqoXRO8EQx6CW2QSfK93R0pdd/7Mfc1XrhPZCLLY m+ZpZcEw9t2drf3+lHnASMZo0SklCSUVU0DowD+yLIxrrZzSkR3DD9iOBWtdqFejgzhzrGiN mpCpJhiksBWkZluWkhVeg0gmwQW+1J20JY5HYriOss0tUoc2xyA+tP1l8cphVANsbJaWzex1 eXuzQDUqJ2h7J+HpkgUcKx5Yt8oeZsc8tIH81zOItQpZiYx1AOO9SdM6LDrXRMI4WlbcZFDC BR/fv84gIgGXYATNMY6nqcO21K/uowGxi0oZFbkoCcY4zGAkESAlAzicSBiAr8UZgZQQAJCW ghYWnHlaOh5ql0A9oayTdQbjZKbk3rlOICFDXqqFn0aEd8KI+E09d2AQk3bbZuZvgDmzQ0t8 x0u4oE2Az4QpazO/30NqeiAs1keHORV8621gD1MR+dkagaFAQ6gy+jq2gwEofHRJyCLNjlRp u/VtojxDBPC7JcahWCBsPF6dNI4iM8W8C3T8eu7KnoqxD5wPG463Rgp+eYssUB8f8f2oLKc4 Ee+7d7TX+bHLcTPXBLwNwoK3VJTssZ5j6izMweQqiiZO1i9MW1Sa8lFtbgY33oTh5b0GmRiU hYjIIqYrNiGG6xKAvi7QzTUF6fdcN3+nNVscebg2318zRayfy5C5+JWTDaTgkoSiyu6XxRTQ IMYtqSQQ0HcJ5Zbd4xObtrSklb8C9f9oh3ioxqhjprV9oxVdV55OH+kvSRlE5N3Xb4CObh1t fiHJWdxarxtcy8J8c59RrHCdzkMydqqfPNO+/hRevD/HimE18xAeHvznDF86uO+HKthaVSt5 8i7+TCrCnXiNxnIzxYfGhVzGOJUs1mIPQxilcSzC62weczqeVWfRUaTobZd2tVRxr+g9DF1n jVtRw0uDJ0naTcbv2sAIlgHF6xbIMgQRMsAX+JLw5TUJmsZHyxmIp0KSbeNCkG9ui10WB9rF fYeNLB01LaVso4CTqUGP87kh7WlbzxoRuQINBFaLZeABEACrUd7CU5mmv1YCyGjgUTqV8BMG PFWASAzn0j7SlUTKgUn2RiyREpCkHZdF2Ad+5zPgQwWcOUmgT8ozuwSXj3ZV1Krq3Kkrs4M2 qU7hg9+hi9KmqTW+xJ6cEK3OPph9WYzYzFFcQl2UMe5+2JOls44uWlGSDWfES6TQVlSG468B /HBtrNjw4ux8U4aavGvAJYwg19lDXe1WOJjYq7fNnIHbfomkrXu0sqVhyPTtnOESKQqFJLWN b8dLrA5FW/LxvZ1XtpMczvnKQU4QjczbQjpz/2J4YnzQ5YwELSjpbaqO3IpVnQTgsabBhKRH OEWHZwOwBLZUmcodD3C5tQiEs/1oZLJ8CcTm7BtZOK3z6aFhnEDke8LFxxZ44bWnQoMmzlp2 mAASIz2eoMcvzfP8O6AnK+UjuHwVPbR/UQxSaIMtyRwCJkXA4e0X1JD3g9Z6YvaOGYFI12CQ 8FCNnKLMtTfzM9yh3egeTqFNi5S+sRaLCE2B1DLSrF9SBkIL5fn43oHoaFMCDq77AxZQx/sg REiwnQLo3pHnDuz+usYc2MmzSyQQ5rNpBW+I29+SR13Vjuj3byBfVPJAXf4lkoghAacTnurv 7rM/J5+3K6qgpwIBW13E1ZGH07XVkTfBbQLpkPLPSBQR3yKxF8H+N7freK70mZK/+6CbzNtc 5P6NyxEDzQARAQABiQIlBBgBCgAPBQJWi2XgAhsMBQkB4TOAAAoJEMzS7ZTSFznpfSsQAJE5 RefK40TQ9ctXu2oB4b5xew/Vlblikegyo6mlJOHyaHNbvglmpIy9H/t3k7BT8aTH1r9X4BfC zvUoaysGBq4YIyCqy+ncLu7ZNeJO/GZWDPttRGCtyYUe648jgOEemG5icJ+eDvMH9CFJh6QK pYURZBUZWpauQrmBu+QcV75GaN8qHAxyfC4L1y28Rdx7MrCA65r0qZh+xtuFlGjRnX5yCvs5 HK7Y3ffx+t8RGwxxtU2FerhqQ/MveZfvmF/O9f5Z0B8rKAIeUYUyryu03c2dWQ1Rr7EOJEk5 4kFD+338T/nYHDVUYasjsUN+1D3Ac5MvTC+f1X9lVt2WIbiBilj2vkgPEin3AK2CAew7vB4d b/v01C0ss1kXKdfajGhx8pO8gG6fRR4J33dt7wQfrch5wdl/v57S8UnwdeF+zqXHIB9lNn8Q MhiKsX1tDTQJl7VbYC7VxnqcWD70oQYPh/i0HuBIQAxvzUsONSxxXn3df/m5BjLK0Jkuma3h tucCad6oQChHLDOrQTwgL4t7yJABFuZTYQ+J94XXdo4tELF8/u8CR4zAWx+1QsHBK/O00ZmN RIEIBzoMg8KJh9eaqIf8Sp0JCy4c19qSHEMcss3TiW8Ab+7sPGjvFGpB75ut9kbn3kHtSPeQ x6irJ03f5vAKCvCIQy70FEyjHi4lFGZWuQINBFhakJABEADLYBkfz/EKmcAyJLb7ddXgACfO tBbWgtpsEulswQe5fKpg+T4fuq++hcbMJMtV9wM4rRUsq0ZmmLSnx2tqCfKrBpBfVzd9m2lB h5ew01KT8L9/9Hw3R+KCZuLAyaz/pOB1JCSi0pw57skdGLZUTjDJoluZe+VUDCfN7soCTtHn UPOEekto0r/qMoXfpdyDnq6acc7/BexXFL6uqTP8Wu51A5JQ1HZ9D/FO4ZF29jXRyTElpsp9 ODNXlW1Ffh5yFhXyHVE4BGthQpUD4/KIhWDcJU5Qvfa/o8Mt2Z/KNv35S4btruKQ00o4D2HM 6+1pHiEpr5O23wR9hwFXnKLIpFoK6pY4KPAM0tCGlb3h7plM64LFNdWg7ChyA+jNsCjJF6ki ol1sYqibrYmvjEcvISpQZx6AewjekoPQSrNf2HXSdNCDkZEB5hyJFm64rNsqrmCKZ0GWBMaJ uAcJO9O1j7YnFQ+SsLgiBHyWkNrykqZEsuVdSVKbDPtnHCXwZ6VZyBbcBMyQitbA52xEKXwJ V9SzyGfMQ6Kdslw1EOInO0uoGJkq/6WwZVahRsPTKMueSNfNEDCaEjVLIxfRbGvPW35mmyE7 g0lpyvTNvqU3JPfbWvomHyfxPmocgfZdMFiYe1Zahl8duB7j8XeOipI/ErlO7pWV+FO1dPvp ltFv0Lg3AQARAQABiQI8BBgBCgAmFiEEDuW+l5KC2AufdUDxzNLtlNIXOekFAlhakJACGwwF CQHhM4AACgkQzNLtlNIXOek7nQ/9G/hJCzPJ2EMQGT2meejT46RoPS1xodR6y7yFJ/V00k7q AXT4M3Ml5w13Ft4xyuaOazVXpmtAFJ5NCkwMutt49bOAr8Ihf3+/i6+g4v7gE/I3OP8wAL6k SXBwc4EXNBaScsEePM4MEFdjRCuGE4vj629mA7Mj3yhpNOv3ic2mhhO9MxTR+Dvo1ySYWsgp aEj2xRVWmFLDpUFXdFndWdcge8KFiRKVpImjxkz5omz1bLbjnM5NMeZwzBrChF/F+gywz0wz mOKjpgFW/liodIQ77Uq34xxnKvqBBD4JcaLPtvzjvf/zAtRYiIQNaJmbDWxC/e5jvVWmpesy KQGZgtEU3YZeQYSQu95QAtTAnxeniG8n/h8ndb71X2hmCDgvL+r8hCdqQBsH6PL3t+Yepeq8 bvNzaZJOrxTcAQCMaCAnCHdVOGp2pv+X8w+u0eEFHzmGDrr3SikoLrIl5EL7buPEortDFCMS 8xQnP2KSvZPf4KzhCXDVuy8E13OQo0iIlgh2FQafza4qtfz6jZ/dEUu9jfGJltrOU78UuXs/ JE8ZmEwieqy1Ou05evusNkSHtafW5DM1Vw5ccG25OCJU3QvP/TYKWYYYmB3v4blj8uNOoCka zcEez5yZC0OC6FCPxG+ZHYyqa13X/94mf3X1idAmLJqvD1/ZJ3VTaT4CXCcDV1m5Ag0EWFqR BAEQAM3TgMH1qK16yCnp1wtmdEs9gtg+LNwjJi2V/OpEcMhepF3GLJyKaPLC/sgORvUOR1qU +w5+1eh2XeL+80GDAooXIUB9FfyQG5Gep0ZPcTIbb8VgDPk12mo/PkFXH6UB0Dx+2OB4dmG1 Yjr83wNFZSQkew0TqIgl2teG+C892g4R9BeHSimUQTEaeqAbhhlzLJJQCls0Z/dsmFgoe8kw G/PCEF05KBMcC4P4JUJUue1l54PjdSFMXJgJvX+Zmx5kLp3V4mWyobt656z6EMVxN8zcd0+J J1P6oJr5yi60jdc+iKqRxYE/E5CQfWCGGJ/2oQLVbKPX8O52JRvCFOdsjC8WJWu4c6FlWn8F gWGMQ0CHkBio4d2vK0zAsIE2Z1+PlB338kBWYv0UJs2Bwyd9OeT3Acy6GuIkXmbmsX6g4qD6 P4kzDEC3HuX8yP+oTteVCW6BLS77q+BxKWBrEhu/MpOCdUDHKBi9hxkAxLZH7htkvhl3+/xu +VQvSXNLAzAVpCdlH+mHG7wnoiqUJtwG6diAVD+QZ7BPJz1hu10jgo9GuvGQONsQSW5DIbrV sY2dKkRQ4Eekqn6pn9YG+dj7quQdRHCDvnaDWMYyGriRcFwXYBcCtas00wUgn9D6IJtJGSqc HryYYZuuuDeadyU9AXpeXcz/DtlFbV4fqsTdjTvzABEBAAGJBHIEGAEKACYWIQQO5b6XkoLY C591QPHM0u2U0hc56QUCWFqRBAIbAgUJAeEzgAJACRDM0u2U0hc56cF0IAQZAQoAHRYhBDgn YFHqR3+j5JU5MhSYrcbBkjI3BQJYWpEEAAoJEBSYrcbBkjI3x0QP/jHi6WT9bD3JJPJljwHS CuHIoTwD32TWT57GxL8rzBmA3WNlx+xtAE3gVxHZGwSC6H6np7KDUpRYo7zIptgMAIUIgzyH HFajKW3a0JzGW7KkorTIBA8zm17Xg6HaNDOiOg+PtLZGqDcFB/1AVCNNz3vM4yMx00WDIqcU 3ZyDAdy2l1IJhnG8BH+g4oSYqAsKKiCd9/XCf3H7zLKoxLQVG76+AUA5e+07/B4HyTAVmfeD b1ap+gtGX87InH2vzYhAdCysibuy0M4SfaRycspw4+Qd5qgqiGnS3rvrJgg0BWVAlzg6apVL gSSmtTmmn6x+MPrsJQaMr321xqnruN0FwS2ENH61lB0eomg6ANj9+E67JGBvdo8i01occhiQ mQtJXU3JeQNu/nbv/fHMy7AqKr9rlokWcE8GgTU5wZ4OeWZ+WPFAkR5JMYy/jm1gRi53ywCR ajAezTn3sUSc4xDf8g9/PECUUAJT4Aw1Ucl/JRDlVloJlGlwqcpA2ux3dEKpAvCBvN98gy4/ uImUXFJQ1J5/3mxRGKkx9hDQFl2HWv5J5J1WQuArJ8GwlJqtRNAzzpF1xaP34KUgGWbATgUI y2ZhNhUfiSQ1pxlL8bkjotYU2bOmH7zfLq/HyvR/18ry6miksXcMzbER67BAJUhYIxAqpwWP mkBaFWqJEgRnug4aUF4QAJ2Cap1Qep5g0AGrnSkDiyxcpMMEfUdS8K1xC6eLl0h4lx14P0hJ b0ZEB19fC6uYylEXVcZOvBTFAEqWWMAjlUNHg+rxQyPKV34BilX0OeksNxYCLncTJy4takDo iQg6DZnip7n9o5QewqQWDs+xzeVowEJFwK59n3IVV/PpNc/BdExO6Q8m1ARWItPRuQswc2XG RDT4YKt6Hr5aR9U8SDgEEc8DwEC7vAVPsSbPkQj8rJMKp4tkPF+LYMHOG/7NNvHXVhYYxJTr C9EYXN8EhMXOFweoWlR8PZiBmSKABWLNTO/2u5zS1QVoIWffPoWYyE7CWCddrvMWL0viCDXh 0RpR49mfBrgxPMoh4pnwoyXNJ52Lakfz2qEpjHtX8OQLrnFb/s3er2+TdYbhT2Jg2e3fIset +w7a9qL+8IH1AeA2MZms1Yq7ZPznp8yVoowO1s685OJV2/W5q3p7rq7gczpRz/wnTs4wilBS PHArEZOw/NENblr2jbFtxkuk7fVRAuiKOD8jJL5Z84QSGaHPXF+X1GgiybIklBNMLdKXsL2a PcyHydUUUCGI+754mosFM8sUdESlAWAGhnwiW4hikiHGFO1KBPDBKVFgXp29o5qiO++Ja4Yh 87/veThr80t69YpQ+3T0IHoZrr3pHomMgcRjwwZe3RTy7XEekgyEMQOouQINBFolmcUBEADR AgdOeCJzYor85suSpRSKcJk2e+tETZMITdloSDglUuC0+CHPShwIs6WMnr6ED9au5PinB5fQ JIJvaoOOz0296PFDALMBoqh/sdRdqp+Sh+kwSlTVRAOF97x3O3jF0nnvQhVKBclSd2r/tfiE ZXB5UxKgOS3dg8+SsriIpaVEtxHQ4mHnAIbasilfh2ESsVab5maE+pmsdZvUVFzl3KeVfnZL tIFo84fYner8gCb0KrOGCeBl+kiOaCzK2TGpEEbNdgagFtL5eCl6RQwpJOOJ2wMTbHl53uSv t29+DAGNOYF4mYKtwe7vBKiaPdVhRy6ePFC5bH9sgG/i+pxGhcGBaTluIBy0AK6e55qIdPhL /8Uis/dTomP3D72/sss0EWNxajOBUpewl3KextEgaS2lNTPi2nS469iAfc+UAGfDKESZ3hJL OzVRSA1FHI0GAyMR0d6v/bDemO2JP8Lw4ooHXDZ1O5qqvJ/I3tuua1n7tnVwCIiM43kViSnA ybGqvcbDMIsMTf+0htd5scRBn/fuSG2ECsMeI7QLTNJbntJQXanD7S9QLXtK7O2oRmkg7ZMl 06xFBTstaZoEgzNKzHOOVr+dLd9ZreuMmssYtm/ZlwFueKo4vaWJn60LBUqrBZCDYbv1LrmF c53eTAfH7Xn1FpkV3gdlT3iOL/7CFyH2ywARAQABiQI8BBgBCgAmFiEEDuW+l5KC2AufdUDx zNLtlNIXOekFAlolmcUCGwwFCQIEzAAACgkQzNLtlNIXOel0wA//eWWaWXYOBPwPI0M2LopA YiMFeBm2H06RXUEbmxrobqOTUPPVkLGYxl+0SK26WJ/RJBMCHHs7P1IVWtCwFghX9sgd+pnf /lKLugNEyNC5veG6zS7S14dQdazYvQZg4WVqf6ECTQwlzjylBJZsHfndeqZG3w6WY3f4sp0l 7ke75ocXGced+DgHWsUDErRJjpi6uBjefie5WpGBZg2+OWK3uBor0WnyVRQKX1I79RV2QaKm AC4YFACJ5v8r8HbN2Yw0P4YYZ3o3qeUTetWv3xsWRrUX/5B3OLtfIfx2KJlq9DeZxxNgYS9v 3AF3mhgMpH2mzLxOsNBr6BOlXEZ8VgJIFNE9/MEbRgKppZ7uz2envpEXdCnqsER9rAUKD9AQ 2yhraV1ztFtpL1mRxq9brLoq+pzx7AtONlDBnpkosjjp1tQKljAZPfC5u1O87jpzQGq/GkAO ppR0TEYovhBA0peqimOfHgJoAGd25vNU/9ObMFtzg+jmlAMNMbLHiPniQz91m8q0qRQCo66K ZGauYamCsjAOQZny6kXhKZcXfp3E+5Sy6tunISWVklggkruO1MxITuB3sBOmblwvu/bhbZtz PLKkvvXQzK6W1+MdFxh0pjCw6nmLs0Cz9LmNAnqbKQuUmBeL8l/GPjigA1kktFFSjdQ8ZK9c 9jbeAZmrZ+Dk1S25Ag0EWiWaIAEQANfHL6Gd3CobCd/nhzIYgOAH0Oi6itu+/rkjJvRYntPG kuHqrhtE+rThEoY36mbAFGwIfOZGetpJnF+KKoJGMyg5J7Mw3/lJf0oQulud5AYDNDnjvDbG g4IvrTNUmrHR8xE33Tn14q27C93ViGfWs6W2Rem5FxSgRyRe+LiB9kHCNjn+TztJPKE5zzuA 6LW1Dd4asnSovSb3F7zlC2jeTkCyIisoVmUVVamgKxU4J9MOdeW4QT2hNko+IeK4gWPJzczk 8fBRQtFnHA1seXEu852K6X+2YMXa8R1QO5oADUmjhw3PMhqttO4ll49MUikSf50yhe52R2+T U9ssuiOt8YNfevcEPy4Xz1hlj97a0aL9hKmsPWy99VC4v4EiPQbbH42FjwQzQU5SLkODCtg1 BxKF4ODYx8UBbe+x3CZtscYZrnobzjR8JAGqYvh6VVDzQVXqbx1tfMHaXCu3Q2eaf3lARa9M kKMzAccUFqgu1V1mWnK6AJMtb/sf0qfoB3xhyUZYn7zm/X257y0Kjf8n4s8GWT03RlfNkYqa H5PP6k+TcKaWow/ob2SfvWypWAUoA/mbp4RYsB6We/23DJrGoTV6og2RbtJw3DNUEyIZ+ZQd BPg/v8NLpvk2fIeJW7O2GLmWdYj84ToOJmO7ZvT8hjWD9vuD9RRcJfpRw/PV8ePXABEBAAGJ BHIEGAEKACYWIQQO5b6XkoLYC591QPHM0u2U0hc56QUCWiWaIAIbAgUJAgTMAAJACRDM0u2U 0hc56cF0IAQZAQoAHRYhBM4nL5TsMpmlpZ6B48rvqIMhZ1MzBQJaJZogAAoJEMrvqIMhZ1Mz ZwMP/iFnpwa/thPok4XjLgM37FQHTLKiVYzUhcWQaHfcdLj5b/kd0j0QcYcOjb2dG8KMnkze R4k+ceOzWKXUMQYuQhhLRz9Ij3IcrZYhvDS6A7L1ra3soBILlid0K9P0JTLCAoHFlDQuzo4X uwbp3CU4rP60ChyFNdvZm6Q2JKcHR9x8NUK9PmOpx0gMElfDDuIl5jytuur2g7F42OzGhKL6 TyCcg4gcIw3Vzsz+OdxkQeFNzBr4aGJZSKiy6ZBodZ77rTsKV+dhZ2cgEYnDDB6zCGXnV9YA Zt2Lwz2z+4wOkPNu4zQv1EPVB8c9vZmdXV2Wl/8g5An6XjGfMLT35Ys9nqYubYe71QJ7gbBf a5lTKouadGfDxAsoFlHZCmIHqgRbvEYH6CeFm3LH1ZcU2PJxt2cJ4mPfyxVrNUe3OI4dmZxC 0XjUNxq4kMVYPOzlQWLH8R3vzkFDzmsJ/QEkWDFm3X56k3QxewVZrPJPYsF9MEoglwD6wV6T hKO/iUVWpUcXm+w7/F/s5MxrI3aksCiRmbPpObPcKaItcMABbgdiIirmySNodMfwcSbQGZu2 y0I9107/re4nZUlS4FphpMEf7saGyy0KXYqOAKGPplCTls4KAQREabSNLB+g+VIV0km4NgTA AiuqvSkgpxrltz/cqQRtpvCnUAZzDcfKygh0m2tDvlwP+wZLWvDQdomrhSaMXaRdSUsWmm6G uTvhBg+Gm3NJg243MLlgAWjNU4prWw34S0OsQb73PVDEXyjyHRnD/OoTLBep7Ww31iqaWVAo XghG9HjZVTEtkhPNOMLusxVPBMUNS2r0W/4YfRRV769rjvaRYnbg1ZXGKhPzLc04chWE7h03 kP+hKUR1spxdKCgcsXA8OZBtk/LhiMoz4UqDqAjWy5inRu4HdiZ3iC2HLQyy8iWw29CiPh+V g2tkkWcGX7u7J8EMWZApILv5r+JnVLAxAoTlRxygAWVOjYHqtwfGTWGYwG6efVPIlPdUsQcQ 6pAPcdzqmsduIPIGvRJL4McQlt8fmTnWvFkO5eGYCxWzA1bbLaec3u2RitzFOdqWOXANWJe0 07WtGK8SnscttZZugh6FOv1bZz5vcO9YQfCPk9V6z4d8nky55oQsxxkdn7WXSw0qEAyNeUyn ytvachF499WtQXGn1QHBDFiTa7cA004XJz/m2MC6HlQeaegn99yA2dD55g1IDzRMJh1PiBg6 bqT5v6w84n/fBtF3o6PL7vBd9zSP0taU2xFgcNl0llI0mwIjM9+QByGoHxRaPC6w8cKObiYm ui94n0lapotYqqbakoJGglmG/I5WZ7uhR+LP3jtFrSSkRNa6o5XQBHoH24yrg2BGxfbjse0w pU/CA8RsuDMEWlUW5hYJKwYBBAHaRw8BAQdAuyfqSjrggnftZ36u/l9urcjUTpKcAfvHMNLf eemKOPKJArMEGAEKACYWIQQO5b6XkoLYC591QPHM0u2U0hc56QUCWlUW5gIbAgUJAeEzgACB CRDM0u2U0hc56XYgBBkWCgAdFiEE02j+deGqkvbkm5nSbB8e3sxQ+lMFAlpVFuYACgkQbB8e 3sxQ+lOA4wD+NVk7QGo2a2wuf5pnBEh0vdV7z2zOlJF3Mimnzft0kQoA/jmx9rzTgByzeyjE DpJBx+uYkfs5n09xqYeVKq6PYn4DQ9YP/R4a5F6EbNToIkuztvxHQ2f7tZYmnoiYwhuRPebB N/1HD9QahJ/6vG/PYwvQb9ntiR4T13FiNU9Be9DzRxJsUtpatX3EAGU0bYayiZ0qgP/1QgpY CYp5JtRT5KA+9Op1weMoyQicFdxvuBIYZlCY70A05ucw/XmIgrEuSPcKheRFtT0BEClsAb9m R61kgxXQ0tzaiucn6KVT6WGItxiUzSa5a5EoIV98NLZg3dU/9IEa7UO/vYe8Ybw+asObLtXW EImMwmbzKMAToMcAoAQmcUjZgXzAr6l9aI8tCqGSJHcDrAIYmYzigk2ZjSimqQfFk729U74Q aMZQXMkNYXDHDRO1ISgj/HoMcj+ZVMjqbV4GRE9+cGMrIyElAZ1s92j/YywfSUXifs6lz4at JXRCzwvbdRzEIpXYtP0iMG5iwOC6y3GrmP8ntemSj96PU9oGiGZm2HUM4t/Cw7a2squ53XkI G9eauEcTK+FJ2FIfGDNUL90wwWBE8tRuzJ4mgqg1XNM4oY4yekll47OjENA3MmONG1VloFV0 NYCxqA/knpS/3eAKB8ZA8alYHmjn+dR/Sr3L4RIQe0dMSkXE0NRsWOput09O8ZKLRklJMlSI VkJgl/l2xPimPwrB9M+XUj3DrvQqj2afgFgjR7nWKh+ppSyqG2JwwtbgC8hdm6bPEpIluDgE WnsjtBIKKwYBBAGXVQEFAQEHQGrg9bPmFaWa9Ry0OBR+qdKnlJI3vxYBYqzKp85qnKIkAwEI B4kCPAQYAQoAJhYhBA7lvpeSgtgLn3VA8czS7ZTSFznpBQJaeyO0AhsMBQkBuwTcAAoJEMzS 7ZTSFznpMJ0QAJBK3D/KLJ031tE/rfivU4hdHdRH0uHjqIkZ5op0p3sn89wb9aPATQgLsbHW 5RHQaLOTC1/rU46FuZeOUcCoh3X46Bz3R5LkVcABYy+y5u/DUCpg9cKxpnGUAXEfFKPvWKUw m+5YUjFH18JdA6am6Qv5KiS5O4LYJpiztq0PMwnp40+QTIs8Gmwj+qBUwO+6zmXOg4i3SWfB CCQmqfXSBWsXFidFmHhfYYbppTP1KwrB2UQePO6aYuw0DE/LbaZ6CGFwpYJ+ArBRu75wPVi/ hzHlrw5wwPlOem/jKicOWFlFJ9BIKFm9V7l6T9A3AIMnXfocpl57f6XSuJI2bDhLoR1pawgc VmP2+J+W4/iTeCSOF0hvEmrPeROFGKfWkHY/gUWMakdczg9ociHvU1B5zIjIRtUF2vXM91P0 WepXy4V0cwwl6Aok4Evh8EUtzsfnkbgFhajfqBVEt7Z8rf0QN65l/I4Hb+eHskLGqpGi8gn5 ODYR1y2W/ThN5BxaTuqyHOqMP+T8MUBd3q4ssP28MGZ1bV0TDFdtZQaXcl5+Up60G8ufvbFq CR+HxbBMMmy/AGRfwoB+D7/Zdcuv2RrF1z2p7iTJtdz/6NM1HWSpDCYEVLJuLVVuRwDusXcv +lrdavHRUHp+Da9/hasu9/Z7sjbUs/GtGDNugaLC9s38ROyD Message-ID: Date: Tue, 10 Jul 2018 14:10:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <23364.61514.267429.409048@gro.dd.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: base64 X-Originating-IP: [38.109.115.139] X-ClientProxiedBy: BN6PR21CA0009.namprd21.prod.outlook.com (2603:10b6:404:8e::19) To BYAPR01MB3653.prod.exchangelabs.com (2603:10b6:a02:84::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dfbd928d-17cb-4807-0ac6-08d5e690761f X-Microsoft-Antispam: =?us-ascii?Q?UriScan=3A=3BBCL=3A0=3BPCL=3A0=3BRULEID?= =?us-ascii?Q?=3A=287020095=29=284652040=29=288989117=29=285600053=29=2871?= =?us-ascii?Q?1020=29=284534165=29=284627221=29=28201703031133081=29=28201?= =?us-ascii?Q?702281549075=29=288990107=29=282017052603328=29=287153060=29?= =?us-ascii?Q?=287193020=29=3BSRVR=3ABYAPR01MB3653=3B?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B3=3A5CI?= =?us-ascii?Q?xBCmVq5aNL/C2NT1Vb5VvIGUz6t5munLQ1wCiak3Y7BXir3LUp4OemhOrviX?= =?us-ascii?Q?27GtYTFrlLw3LCnZPgNjrY88gRzG63UpIxzghh03tZR4TFd4UJBMBHxnoPX5?= =?us-ascii?Q?eu1RbmeeO0WIZTc8eRRpoV0fZZiISP5mvglKkdv5+1PsYK9wapmOLBfmZXtx?= =?us-ascii?Q?5xM03QiuW7UmkRcZ2b/jjmUS9QbWKNi3nRB5S0HD1RQSe9CzYjbMN76xlH/O?= =?us-ascii?Q?NNkvzKrNR3jh0=3B25=3AVNwqwD7VxeLlvzX5QkZajUKkeB04lLENtHjU3Jv?= =?us-ascii?Q?fS8imY2z+7kGLcfOsgeYpqyiRKeuVQXzJmmiv2UrNzYKExGi4cq7UT5tUO+f?= =?us-ascii?Q?E00YT7b5R99VYZblGGzUNnKfSkKtP5rPY6kx7IsamINOz54TUWMs4RA6m89N?= =?us-ascii?Q?ql93oEgeux81foWjrTCNYE4UbbYbbKbBvsUeGcO8YJgHOBijgrLtzsr2fxSZ?= =?us-ascii?Q?00dk42wQkvs3+hH/bOLt96qRSzajkkcQuyAx+RT4C4MrGJlkFMb18bN18hBu?= =?us-ascii?Q?kS/GcGF0IaFLXOdqlD/VRH/q7+htwZXsoW0qnJjVUcz9DIXIL5NeMYLbopjr?= =?us-ascii?Q?VIQ=3D=3D=3B31=3Am2iPETmhoIp5VqVK/CmmnKQmIWBL71E3MrvP9wXuP5H?= =?us-ascii?Q?1h0FEV3Zl0L/wBg7WU7jubpZXZZPyq95OU9U5zYXx6r939epqSILDiHo7FeI?= =?us-ascii?Q?RH1b5Th5SNsOL62Lu7wc5wSdAENhUG3irs96vOv9/lJQqjDf6ilosb5fxpfO?= =?us-ascii?Q?nJNqNe14Dr0SYp82X2vgpT7MLR/7UgE5AGJznvnicUYaWYmOWPQQ9dQxdQD7?= =?us-ascii?Q?yTxzFNAKt+iw=3D?= X-MS-TrafficTypeDiagnostic: BYAPR01MB3653: X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B20=3AS3?= =?us-ascii?Q?Z2mQVIPW7G01JPxUglTbjt+Ol31lVovLZsTzi+VZIirDd4+85h7vRGuxlVaK?= =?us-ascii?Q?CWJPWy5kxDwUE1g6iQ6FmMUDexcGwBCafJ4GPp6+zUtUxZHK29bE6DG6nZp3?= =?us-ascii?Q?IgCx4bA55ciDcB7fL+J5F8oVYmti6YbtLz0RMfu2FpNwoCnniWQFKqwIBRzm?= =?us-ascii?Q?BLLMhqdyMtFOh8D8ZWTrndxfvNV1EwrTNMZbxCdi2u0MB62ghiPvcLJ8Zz4B?= =?us-ascii?Q?3gTIrWkE1NM4rT41Ks95C79oL+1jTmlbk6m51s5E5ejs3f77bXbzC9BmbZEg?= =?us-ascii?Q?dOVLXB6Ovn1mltWBFqdEAFqXje8+KSY56kbzMJN37Gn2V1BBXEQ2RE7qcD1X?= =?us-ascii?Q?+FxvtNKsIjC0pbMINUNajux+1z7gfIUdADK7/amtPb5ioU2/X6g2kC0oDBlZ?= =?us-ascii?Q?whoroqMheKHkSnKXx09sb48bOZ5upRru9DvjxOrUklFUcvSAPq7bpY192Q4H?= =?us-ascii?Q?2ngOvkaeddoy2GdUu5FZd1GOsN9eadICvAuBuDL2InCvNqaeJMyzdMe8OUCd?= =?us-ascii?Q?1oGe26JrbvUU0XLMmFDDKWTlBYCdDhar2uREeluJTi4A3wcjMW+QFqUTNwKY?= =?us-ascii?Q?eybz5ISa1zi2mhXQQ=3D=3B4=3ANJCVEmItSdFqZ4VLvQuwKN8Gf/Ge79639?= =?us-ascii?Q?iPObwuqId1AbGUX5EzT4/N2zWdTIuh8jqGDaFqTXNdyaFDosPT4jgbPKuaFr?= =?us-ascii?Q?Gk3nWTVwPb2kaW0DLyWZABvY7YPAnXtA3zCCapsleNt3f5ntvPAPUiwnjZVq?= =?us-ascii?Q?ocATDgGF2QPGo/KXiRiZTlDQouUEw/hxDvg0wLUctaeupr/GC+aKz4ww1B/3?= =?us-ascii?Q?i1/Et4D5bH1223jRk5mct6jA4wA2NVkszXXzU56kvvIyQTfN8GnefhVik95t?= =?us-ascii?Q?jo6CQ=3D=3D?= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: =?us-ascii?Q?BCL=3A0=3BPCL=3A0=3BRULE?= =?us-ascii?Q?ID=3A=288211001083=29=286040522=29=282401047=29=288121501046?= =?us-ascii?Q?=29=285005006=29=2893006095=29=2893001095=29=283002001=29=28?= =?us-ascii?Q?10201501046=29=283231311=29=28944501410=29=2852105095=29=281?= =?us-ascii?Q?49027=29=28150027=29=286041310=29=28201703131423095=29=28201?= =?us-ascii?Q?702281528075=29=2820161123555045=29=28201703061421075=29=282?= =?us-ascii?Q?01703061406153=29=2820161123560045=29=2820161123564045=29=28?= =?us-ascii?Q?20161123562045=29=2820161123558120=29=286072148=29=282017080?= =?us-ascii?Q?71742011=29=287699016=29=3BSRVR=3ABYAPR01MB3653=3BBCL=3A0=3B?= =?us-ascii?Q?PCL=3A0=3BRULEID=3A=3BSRVR=3ABYAPR01MB3653=3B?= X-Forefront-PRVS: 0729050452 X-Forefront-Antispam-Report: =?us-ascii?Q?SFV=3ANSPM=3BSFS=3A=2810009020=29?= =?us-ascii?Q?=286049001=29=28366004=29=28346002=29=2839850400004=29=28396?= =?us-ascii?Q?003=29=28136003=29=28376002=29=28189003=29=28199004=29=28367?= =?us-ascii?Q?56003=29=286486002=29=286666003=29=28224303003=29=2822938300?= =?us-ascii?Q?1=29=28105586002=29=28106356001=29=2866066001=29=2811346002=29?= =?us-ascii?Q?=2864126003=29=28446003=29=2865806001=29=2865956001=29=28436?= =?us-ascii?Q?003=29=28478600001=29=28476003=29=282616005=29=287126003=29=28?= =?us-ascii?Q?956004=29=28486006=29=2825786009=29=28229853002=29=283168600?= =?us-ascii?Q?4=29=2816526019=29=2858126008=29=28110136005=29=2816576012=29?= =?us-ascii?Q?=2847776003=29=2854906003=29=28316002=29=28186003=29=2877096?= =?us-ascii?Q?007=29=2826005=29=2850466002=29=282906002=29=2881156014=29=28?= =?us-ascii?Q?97736004=29=28386003=29=288936002=29=2881166006=29=283846002?= =?us-ascii?Q?=29=28305945005=29=286116002=29=287736002=29=2853936002=29=28?= =?us-ascii?Q?5660300001=29=2868736007=29=2823676004=29=2852116002=29=2857?= =?us-ascii?Q?5784001=29=2876176011=29=284326008=29=2831696002=29=28658260?= =?us-ascii?Q?07=29=286246003=29=282486003=29=3BDIR=3AOUT=3BSFP=3A1101=3BS?= =?us-ascii?Q?CL=3A1=3BSRVR=3ABYAPR01MB3653=3BH=3A=5B127=2E0=2E0=2E1=5D=3B?= =?us-ascii?Q?FPR=3A=3BSPF=3ANone=3BLANG=3Ako=3BPTR=3AInfoNoRecords=3BMX=3A?= =?us-ascii?Q?1=3BA=3A1=3B?= Received-SPF: None (protection.outlook.com: aclu.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?Q?1=3BBYAPR01MB3653=3B23=3A98YpJ?= =?utf-8?Q?JG5GmYCjTTpwBkSpCQGLsb1W0FxnZhN/z5HETD228YTdBrFA2Okv+IEysnDzWhG?= =?utf-8?Q?uXF3LKuQnBdaklQEuFwWjpdaez0TL7tJYJZY325RBJFvtlzN4ypPdFXdRhSouXD?= =?utf-8?Q?6CiePKAn6QseGr4R1o1bn7GZaY1WIDkcEG+AI9guDP/ivR+OobH2gnIMKH2OmIA?= =?utf-8?Q?51lJT5rAPbC46lh3JUJJ0z1jFHDzUHN/K/6g8wtKDa/+HHYaFY41lv7HzYsJl+F?= =?utf-8?Q?HjM5DXYky1J3ZR8akVs6UXKLz4iDX6uYzhB9UkZ3KxYQb7ibRPOBk4Zi3JMAP/f?= =?utf-8?Q?yO4FVBsrh84nAhwFHLGwHO+ANTX7Q2IvUfkmC8gL43iviGa84TgzL9G5pp/NIF4?= =?utf-8?Q?hQMuj3N0Uv36PZkiRWkMvf1wv3rcsZaSBix8k3tgDL3A3551IKofCAbjaD1MsyI?= =?utf-8?Q?ETHOFUElyd16+xHxIseMpRb13lppSmrMSxgbRsDq2Yzevjbd3cUg5z68nQYGeKM?= =?utf-8?Q?gE5qymgGjzH0Ew/rOI2AIgZniEutVmdrZbbN8GEmcHmV+J3Uwt7zfdG36kfsB1+?= =?utf-8?Q?ISyO9uXXMdWLrbM4rj01HUmw16hDGkqRkD8HLsVfyu8XVPHdX2wYNP1QNYuOlG/?= =?utf-8?Q?aInKAmkn5L45NwNv2pBy6qRVTPXpH0Job/z2bi/7mrWzxKU8G/WMjjPWKbnn2bQ?= =?utf-8?Q?BUHS6spwZoYeDwiBjQJKHAXwEhhDjQvoECYXS7Q3082GXFC6tB1k9Z1dePvrEk7?= =?utf-8?Q?OoJiiLpAh/JBqdiEY6JpXW4pGktsI5JVENIb3Tj/+Fa/JiNVarN7zJBR32MZrWi?= =?utf-8?Q?O9n4Og58OysYSdbwPw3zdOt+yrRwl1TZ7bQu4Pd/MPm8FuCHazj4M6aeOEl1vcL?= =?utf-8?Q?l9AzuRJus1rdOwXEvSfvAGyjd1O2jciAm8XNkc6Yikg6CVLXpXFGBg3lKuNa4xP?= =?utf-8?Q?0H9lERdKVXczjZBH6vTieBho5Y4o6grqoWYAslBF8ayDLe27RkPGBAmxTAb5Nnx?= =?utf-8?Q?Mt9Wc4J42dphC4zRwzuoRy2RXIEZkW2heZK0Ed0X5aEKd0YrTm1vsxVLSKMHoGO?= =?utf-8?Q?uCD0rmhrYiavzDHom+tURvyeyC5N7D48PnGhjKvMFFxcKPqfj58wKCU26+ZCD/z?= =?utf-8?Q?LQUd/AIZoSbh3hYHB8x60HAAh5kLitq80dUP0V34YG5ea1Hl3DrEwWuQwnlFm6i?= =?utf-8?Q?P6B6KdYgi9Rlr9qqvKcTeUc758y9wZjRDMOBPkwMjBb4yr+49/+ag3tP9C18OGg?= =?utf-8?Q?Ny5eIM6dz+zCbl5eZGPYOS1lmxX2jXQlxa6WKL1zKBWu61RG8Qw5MNOLw6YfJzv?= =?utf-8?Q?jmJXTfMx0Q/He3dihFRzK9S+ZOhiXVGNx5v4Qoq8gtl9cvNztQ8OhI7BmdQJy8Q?= =?utf-8?Q?jVD7KFJfjEaLpmWV3mcAAuSOz+ZCGFxXB8kdfVA=3D=3D?= X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Z+f/u02kpxhtdSIyqM23ANc1d0?= =?us-ascii?Q?W1ohusslT1c2oBn6W3Vc/cLP4aS0Z60cQykMWYgdXRZLm1/NP6DYMMYHV8UE?= =?us-ascii?Q?m4Bv+he27MbOD7BiFIkJcEDWESRGXyJHg4JAGKMWas25FNqZf37G6oUjOkdr?= =?us-ascii?Q?nvULyeqHZ+dJU4LbE3i20HgUo3grlkqJ4qkmA+VvUlFu4yg9z/dPex9ZLfy8?= =?us-ascii?Q?n+1Vva9J9ZI48FaZRik4PNlicChs+3hpqiIiMCjZBInuzUdZZ1p3zxiuPQSM?= =?us-ascii?Q?ozSXHmFH4oM+uxfuGa/2jnT/44oip41sAnXeR85XX3MSvkw/5wfX8UDUxFGW?= =?us-ascii?Q?jAURMdX6A9VlYjQRhkAe1WHsWWBpr2SS0ucFY=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B6=3AQAB?= =?us-ascii?Q?xAAw0oh5gDM8sjNLLrSwTJ2xP9PCR0dHzMyYetMpX4abhlPxkC/zo3L1hldi?= =?us-ascii?Q?agafuMNxLvb9lhWTmnl1bCtJO3kpXX23ljNlzCknzejovQVqBWgwM0z9oQYX?= =?us-ascii?Q?4rXygVkhPA/M4UQk/EnWNfmOYl2CAZtkort3IoJUMOcXGOqyvPUtzsS0ge7v?= =?us-ascii?Q?nfsWj4Tdn+2q/D5euDVOh2BMenHDZHpWkIewYYeGbsuw6Y7oxlmSQeDC2FBy?= =?us-ascii?Q?PpGO6KANZDzv2+e8AkLv70I/VQz/2uNnOGI92/ELULvvXhb/p1cbc+xNpQvy?= =?us-ascii?Q?dWDDIXLfMgdw70FQuYxJMpsX2aQSid+YauagY88WqlKnwlUpdrzs2KP3f9dd?= =?us-ascii?Q?rFAk7yy097oUvF4lgCr0aRwJKrnFiWDExEg4LD5iJWjtQZbO8eQoWaqGVWcE?= =?us-ascii?Q?uDMrclD9d3jg9Nrxmj6cle1P5eCmsPzIzUqlul2FK8Sg5aQ=3D=3D=3B5=3A?= =?us-ascii?Q?KgJh0xzpYvGBWaVvJoYTnDA82zI3Oit4uGw2aGytl00gzBbPCXFC9+neGqaF?= =?us-ascii?Q?SkrkFtF9qJh8ofHtfHHRMyj8EEm8Xc2eTb9wt14QE5/s5KLLnlj9Qbb58Wyw?= =?us-ascii?Q?VlKfXLzw0O31fff5VLBpkH8Qf+iPeaoS/TgpzlkesiIb2DkzVCc=3D=3B24=3A?= =?us-ascii?Q?qyGaxbLra8G+1bsBvX0KDZd2BJeY2il87Uq2fzHTaxT+gSX8G/UCUro5y+hn?= =?us-ascii?Q?4l8725RMoV52/vszZPm6pX3ClgIFRS3B/COUIRPPaD6edTg=3D?= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B7=3AS+a?= =?us-ascii?Q?wicWnMVN2mwYdcqjtBtFOscYsc+DKxv5BKZDir9ZJYd3lAeFeSoh/3iTFLqj?= =?us-ascii?Q?WfLCVx//cGhtphPV8O1pMdT2bBZj2SWBBYy6gwYlV3Fam6uR/0zqw2TJ4h8T?= =?us-ascii?Q?JGbRFfftFRp5t+8CA/FrwL8WdDTfYQDQXKlOsMrZXjIFoVWEOtfV+ANAEyuC?= =?us-ascii?Q?1VI23c13Wi8T7xOUsTmagY8bn2kTi5idVMCTi5PJIdEfZa0/OIYgqiujmK5N?= =?us-ascii?Q?952LT0PY7tdTm?= X-OriginatorOrg: aclu.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2018 18:10:46.5602 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dfbd928d-17cb-4807-0ac6-08d5e690761f X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 735676e9-2494-4a0f-bf31-4bdea1e91986 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB3653 X-Vaultive-Router: decrypted Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:11:09 -0000 T24gMDcvMTAvMjAxOCAwMTo0MyBQTSwgRGF2ZSBMYXdyZW5jZSB3cm90ZToNCg0KPiBJbiB0 aGUgbGFyZ2UgSSBhZ3JlZSB3aXRoIHlvdSwgYnV0IEkgdGhpbmsgdGhlcmUncyBtb3JlIHRv IGl0IHRoYW4NCj4gdGhhdC4gIElmIGl0IHB1c2hlZCBtZSBETlNTRUMgcmVjb3JkcyB0aGF0 IEkgY291bGQgdmVyaWZ5IG15c2VsZiBmcm9tDQo+IG15IG93biBjb25maWd1cmVkIHRydXN0 IGFuY2hvciwgd2h5IGNhbid0IEkgdHJ1c3QgdGhlbSB0aGVuPw0KDQphbHRlcm5hdGVseSwg aWYgaSBrbm93IHRoYXQgaSdtIGdvaW5nIHRvIHZlcmlmeSB0aGUgZGF0YSBpbiB0aGVtIHNv bWUNCm90aGVyIHdheSAoZS5nLiB2aWEgWC41MDkgY2VydGlmaWNhdGUgdmVyaWZpY2F0aW9u IGluIGEgVExTIGNvbm5lY3Rpb24pLA0KaXMgaXQgZXZlbiAidHJ1c3QiIHRvIHNheSB0aGF0 IHlvdSBtaWdodCBiZSB3aWxsaW5nIHRvIHRyeSB1c2luZyB0aGUNCmRhdGEgaW4gdGhvc2Ug cmVjb3JkcyB0byBzZWUgd2hldGhlciB5b3UgY2FuIGNyZWF0ZSBhbiBhdXRoZW50aWNhdGVk DQpjb25uZWN0aW9uPw0KDQpJJ20gbm90IHNheWluZyBpdCdzIGEgc2xhbSBkdW5rOiB0aGVy ZSBhcmUgcHJpdmFjeSBjb25jZXJucyBpbiBib3RoDQpkaXJlY3Rpb25zLiBidXQgaSB0aGlu ayB0aGUgc2l0dWF0aW9uIGlzIHZlcnkgY29udGV4dC1zcGVjaWZpYy4gIGNlcnRhaW4NCmNs aWVudHMgaGF2ZSBzcGVjaWZpYyBuZWVkcyBmb3IgdGhlc2UgcmVjb3JkcyB0byB2YWxpZGF0 ZSBpbiBzb21lDQpwYXJ0aWN1bGFyIHdheXMsIGJ1dCBvdGhlciBjbGllbnRzIGhhdmUgZGlm ZmVyZW50IG5lZWRzLiAgSSBob3BlIHRoZQ0KZGlzY3Vzc2lvbiB3aWxsIGJlIHZlcnkgc3Bl Y2lmaWMgYWJvdXQgd2hpY2ggY2xpZW50cyB3ZSdyZSB0YWxraW5nIGFib3V0DQotLSBub3Qg anVzdCB3aGljaCBzcGVjaWZpYyB0cmFuc3BvcnQgdGhlIEROUyByZWNvcmRzIGFycml2ZSBv dmVyLg0KDQoJLS1ka2cNCg0KDQotLSANCkRhbmllbCBLYWhuIEdpbGxtb3INClNlbmlvciBT dGFmZiBUZWNobm9sb2dpc3QNClNwZWVjaCwgUHJpdmFjeSwgYW5kIFRlY2hub2xvZ3kgUHJv amVjdA0KQW1lcmljYW4gQ2l2aWwgTGliZXJ0aWVzIFVuaW9uDQorMS4yMTIuMjg0LjczMzYN Ck9wZW5QR1AgZmluZ2VycHJpbnQ6IDBFRTVCRTk3OTI4MkQ4MEI5Rjc1NDBGMUNDRDJFRDk0 RDIxNzM5RTkNClByb25vdW5zOiBoZS9oaW0vaGlz From nobody Tue Jul 10 11:13: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 BECA81311A5; Tue, 10 Jul 2018 11:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nt6l760SQ4E8; Tue, 10 Jul 2018 11:13:34 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 90936130F04; Tue, 10 Jul 2018 11:13:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:37534) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fcx8k-000b7f-gQ (Exim 4.91) (return-path ); Tue, 10 Jul 2018 19:13:30 +0100 Date: Tue, 10 Jul 2018 19:13:29 +0100 From: Tony Finch To: Dave Lawrence cc: Paul Vixie , DoH WG , driu@ietf.org, Ben Schwartz , dnsop , Patrick McManus , Daniel Kahn Gillmor , HTTP Working Group In-Reply-To: <23364.61514.267429.409048@gro.dd.org> Message-ID: References: <5B447154.5010307@redbarn.org> <23364.61514.267429.409048@gro.dd.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:13:48 -0000 Dave Lawrence wrote: > > In the large I agree with you, but I think there's more to it than > that. If it pushed me DNSSEC records that I could verify myself from > my own configured trust anchor, why can't I trust them then? I've been idly wondering about this from the point of view of RFC 2181 trust ranking: to what extent does it make sense to promote the rank of data (e.g. additional records) that has been validated? The risk, I think, is replaying stale data - there shouldn't be any worse consequences. So it should amount to a DoS attack (and there are easier ways to achieve one of those). Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Northerly 3 or 4, occasionally 5 in east. Moderate. Mainly fair. Good. From nobody Tue Jul 10 11:25:08 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 C2875130EAA; Tue, 10 Jul 2018 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, 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 8edN_97smWhc; Tue, 10 Jul 2018 11:09:39 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710110.outbound.protection.outlook.com [40.107.71.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A2E131036; Tue, 10 Jul 2018 11:09:38 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=k9BZoUmLZ12sPFY6boOH52R0h7rbFM2eySAoMhW1DjA=; b=s7YIRkT4wtA0WSKFcJI2lBuZmdpAPwxViBQi8xMRzd2FrvoBYbzM8dMIkqJ/T1Qw++bnYVQSN7EN/4B2rsynqaFXOWF++TnAOXOVm79jBz2vFQj+e8Sho2W1n0P/pzdUDLmy653GLjv0J/AHm0kpUulHEQaEsggJjIf3ZQ24Kg0= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Tue, 10 Jul 2018 18:09:34 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3%2]) with mapi id 15.20.0952.017; Tue, 10 Jul 2018 18:09:34 +0000 From: Mike Bishop To: Ryan Sleevi , Adam Roach CC: Ted Lemon , Joe Abley , DoH WG , "driu@ietf.org" , dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Thread-Topic: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal Thread-Index: AQHUGHcUEnMDtFq0KECSgsWzR+27KaSIv4hg Date: Tue, 10 Jul 2018 18:09:34 +0000 Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> 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; BYAPR08MB4903; 7:JTavA3z8oo217M6erlWzeqkgZ4iDn0tvPxzFCjnBkj7XhMn7+H7StFADGupE1nCM5Ek/j6cFbdc5Dgn2a+7dy40Ue7Nlu37lW0k4rzQvfnajybPjlFhGMxobmnMRbAOoDgqA8W8WCSy8Sc1WUYJQ28Id0OJRZeK0/sXL1PNp3nc4h32N2vzTdbudmiQOcBCk2aFLKtikb/M362Jk6nX/rlA8B0/6xkzeVgk4YE46ZNYeHOLwk0Kum4ufhz6bOJge x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f76556fb-7879-4bcf-4252-08d5e6904a9a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4903; x-ms-traffictypediagnostic: BYAPR08MB4903: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(2016111802025)(20161123564045)(20161123562045)(20161123560045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4903; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4903; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(366004)(396003)(39830400003)(199004)(189003)(25786009)(106356001)(14454004)(966005)(74482002)(11346002)(186003)(68736007)(26005)(45080400002)(478600001)(105586002)(76176011)(446003)(86362001)(7696005)(5070765005)(316002)(476003)(6506007)(53546011)(110136005)(99286004)(486006)(102836004)(54906003)(33656002)(236005)(74316002)(55016002)(9686003)(6306002)(93886005)(7736002)(54896002)(8936002)(8676002)(81156014)(81166006)(66066001)(53936002)(256004)(14444005)(229853002)(4326008)(97736004)(6116002)(2900100001)(6436002)(3846002)(790700001)(5660300001)(7416002)(19609705001)(5250100002)(53386004)(6246003)(2906002)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4903; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: U+BdcX6mwRUFbJ4Ikn/doYbxngkiyu3crljeQOtugikpKO2PlH9nGXF82W5KF8BWWi7RnY9Iiy6Iyeqhp4D/4akQMqo1tct2xj1twOWkjqho/SNml8BI+JDbENdWjf2xoHrka1l5/wTGIAYOUHXjCURZ3AanFgiGhCCGyNtJ1HsX2TwP/UBUocuDdwmvfu7pA07Z3Cl+kO/eIj/atdTUkJXfM1eA/foXeG0Yjl97uKQS4uoDJzdMD1x8u0waOI+jur+pKHc59+wt764m9JTP1a7MJG1NRJp/wTTCuyXnODnVJ0c+9uaX1KY/ZW3ZQDYpvBtAEInEwbB9DaeHe7i65RXdvmisMse793PTeX0L/TA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: f76556fb-7879-4bcf-4252-08d5e6904a9a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 18:09:34.1283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4903 Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 11:25:07 -0700 Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:09:43 -0000 --_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGUgbXVsdGktQ0ROIGNhc2UgaXMgdGhlIHNjYXJpZXN0IGFzcGVjdCBvZiBjb2FsZXNj aW5nIGFuZCB0aGUgdmFyaW91cyBETlMgdHJpY2tzIHdl4oCZdmUgYmVlbiBkb2luZyBpbiByZWNl bnQgeWVhcnMuICBUaGUgc2VydmVyIG1heSBub3QgYmUgbWFsaWNpb3VzLCBtYXkgbm90IGV2ZW4g YmUgbWlzY29uZmlndXJlZCDigJMgc2l0ZSBYIHVzZXMgRE5TIHRvIGR5bmFtaWNhbGx5IHNoYXJl IGxvYWQgYmV0d2VlbiBDRE5zIEEgYW5kIEYuICBJZiBYIGRlY2lkZXMgdG8gc3RhcnQgbW92aW5n IG1vcmUgbG9hZCB0byBBLCBGIGNvdWxkIGluIGFsbCBnb29kIGZhaXRoIGNvbnRpbnVlIHRvIHJv dXRlIGNsaWVudHMgdG8gaXRzZWxmIGJ5IHByb3ZpZGluZyBjYWNoZWQsIHNpZ25lZCBETlMgcmVj b3Jkcy4NCg0KVGhlIGluZHVzdHJ5IG5vcm0gaXMgdGhhdCBjaGFuZ2luZyB0aGUgRE5TIHJlY29y ZOKAmXMgQ05BTUUgdG8gYSBkaWZmZXJlbnQgQ0ROIGlzIHRoZSBjdXQtb3ZlciwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIHRoZSBvdGhlciBDRE4gcmVtYWlucyBjb25maWd1cmVkLiAgSXTigJlzIGVm ZmVjdGl2ZWx5IGFjdGluZyBhcyBhIOKAnGhvdCBzdGFuZGJ5LuKAnSAgSWYgaXQgaGFkIHRvIHBy b3ZpZGVkIGJldHRlciBwcm9vZiBvZiBmcmVzaG5lc3MsIHRoYXQgbWlnaHQgYmUgc3VmZmljaWVu dCwgYnV0IGhvdyBmcmVzaCBpcyBzdWZmaWNpZW50bHkgZnJlc2g/ICBBbmQgZG9lcyBETlNTRUMg cHJvdmlkZSB0aGF0IGZyZXNobmVzcyBndWFyYW50ZWU/DQoNCkhvd2V2ZXIsIEYgY291bGQgZG8g dGhpcyB0b2RheSB3aXRoIEFsdC1TdmMgYW5kIGhhdmUgdGhlIHNhbWUgaW1wYWN0LiAgU2Vjb25k YXJ5IENlcnRpZmljYXRlcyBwcm92aWRlcyBhbm90aGVyIHdheSB0aGlzIG1pZ2h0IGhhcHBlbi4g IFNvIHRoaXMgc2hpcCBtaWdodCBoYXZlIGFscmVhZHkgc2FpbGVkLg0KDQpGcm9tOiBSeWFuIFNs ZWV2aSBbbWFpbHRvOnJ5YW4taWV0ZkBzbGVldmkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAx MCwgMjAxOCAxMDo1MiBBTQ0KVG86IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+DQpDYzog VGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPjsgSm9lIEFibGV5IDxqYWJsZXlAaG9wY291bnQu Y2E+OyBEb0ggV0cgPGRvaEBpZXRmLm9yZz47IGRyaXVAaWV0Zi5vcmc7IGRuc29wIFdHIDxkbnNv cEBpZXRmLm9yZz47IFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMuY2E+OyBQYXRyaWNrIE1jTWFu dXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsgUGhpbGlwIEhvbWJ1cmcgPHBjaC1kbnNvcC0zQHUt MS5waGljb2guY29tPjsgSFRUUCBXb3JraW5nIEdyb3VwIDxpZXRmLWh0dHAtd2dAdzMub3JnPg0K U3ViamVjdDogUmU6IFtEcml1XSBbRE5TT1BdIFtEb2hdIFJlc29sdmVybGVzcyBETlMgU2lkZSBN ZWV0aW5nIGluIE1vbnRyZWFsDQoNCg0KDQpPbiBUdWUsIEp1bCAxMCwgMjAxOCBhdCAxOjA1IFBN LCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4g d3JvdGU6DQpPbiA3LzEwLzE4IDExOjQxIEFNLCBUZWQgTGVtb24gd3JvdGU6DQpPbiBUdWUsIEp1 bCAxMCwgMjAxOCBhdCAxMjozNCBQTSwgSm9lIEFibGV5IDxqYWJsZXlAaG9wY291bnQuY2E8bWFp bHRvOmphYmxleUBob3Bjb3VudC5jYT4+IHdyb3RlOg0KPiBCdXQgdGhpcyBpcyByZWFsbHkgZXF1 aXZhbGVudCBpbiBqdXN0IGFib3V0IGV2ZXJ5IGltcG9ydGFudCB3YXkgdG8gc2VuZGluZyB0aGUg bm9ybWFsIDxpbWcgc3JjPSJodHRwczovL2V4YW1wbGUuY29tL2ltZy9mLmpwZyI+IGFsb25nIHdp dGggYSBwdXNoZWQgRE5TIHJlY29yZCB0aGF0IGluZGljYXRlcyB0aGF0ICJleGFtcGxlLmNvbTxo dHRwOi8vZXhhbXBsZS5jb20+IiByZXNvbHZlcyB0byAiMTkyLjAuMi4xIiAtLSBhbmQgdGhpcyBs YXR0ZXIgdGhpbmcgaXMgKHRvIG15IHVuZGVyc3RhbmRpbmcsIGF0IGxlYXN0KSBpbiBzY29wZSBv ZiB0aGUgY29udmVyc2F0aW9uIHRoYXQgUGF0cmljayBpcyBwcm9wb3NpbmcgdG8gaGF2ZS4NCg0K TXkgcXVlc3Rpb24gaXMgd2h5IHlvdSB3b3VsZCBpbnZvbHZlIHRoZSBETlMgYXQgYWxsIGlmIGFs bCB0aGUNCnBlcmZvcm1hbmNlLWJhc2VkIHJlc29sdXRpb24gZGVjaXNpb25zIGNhbiBiZSBtYWRl IHdpdGhvdXQgaXQuIFlvdSdyZQ0KanVzdCBhZGRpbmcgY29zdCBhbmQgY29tcGxleGl0eSB3aXRo b3V0IGJlbmVmaXQNCg0KVGhlIGlwPSBtb2RpZmllciB3b3VsZCBiZSBhIGdyZWF0IHdheSB0byBh cnJhbmdlIGZvciBzb21ldGhpbmcgdG8gbG9vayBsaWtlIGl0IGNhbWUgZnJvbSBhIGRpZmZlcmVu dCBzb3VyY2UgdGhhbiBpdHMgYWN0dWFsIHNvdXJjZS4gICBJJ20gc3VyZSB0aGVyZSdzIGFuIGF0 dGFjayBzdXJmYWNlIGluIHRoZXJlIHNvbWV3aGVyZS4NCg0KDQoNCktlZXBpbmcgaW4gbWluZCB0 aGF0IHRoZSBjZXJ0aWZpY2F0ZSBwcm92aWRlZCBieSB3aGF0ZXZlciBtYWNoaW5lIHlvdSByZWFj aGVkIHdvdWxkIG5lY2Vzc2FyaWx5IGhhdmUgdG8gbWF0Y2ggdGhlIFVSTCdzIG9yaWdpbiwgdGhp cyBpcyB2ZXJ5IG11Y2ggb25lIG9mIHRoZSBxdWVzdGlvbnMgdGhhdCBpcyBiZWluZyBhc2tlZDog aXMgdGhlcmU/DQoNCi9hDQpZZXMuIENvbnNpZGVyIFNpdGUgQSAoZm9vLmV4YW1wbGUpIGFuZCBT aXRlIEIgKGJhci5leGFtcGxlKS4gQm90aCBwb2ludCB0aGVtc2VsdmVzIHRvIENETiAxLCB3aGlj aCB0aGVuIG9idGFpbnMgYSBjZXJ0aWZpY2F0ZSBmb3IgYm90aCB0aGVpciBuYW1lcyBpbiBzdWJq ZWN0QWx0TmFtZXMuIFNpdGUgQiB0aGVuIGRlY2lkZXMgdGhhdCBDRE4gMSBpcyBhbiB1bnJlbGlh YmxlIHBhcnRuZXIsIGFuZCBnb2VzIENETiAyLCB1cGRhdGluZyBETlMgYXBwcm9wcmlhdGVseS4N Cg0KVGhpcyBpcyB0aGUgc2FtZSBwcm9ibGVtIGluIGNvbnNpZGVyaW5nIHRoZSBIVFRQLzIgY29h bGVzY2luZyB3aXRob3V0IGRvaW5nIEROUyByZXNvbHV0aW9uIChlaXRoZXIgYmVjYXVzZSBvZiBw b29yIHNlY3VyaXR5IHBvc3R1cmUgb3IgYnkgY29tYmluaW5nIE9SSUdJTiArIFNlY29uZGFyeSBD ZXJ0aWZpY2F0ZXMpLiBSRkMgODMzNiBicmllZmx5IHRvdWNoZXMgb24gdGhpcyAoIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzM2I3NlY3Rpb24tNCApIGJ1dCBkb2Vzbid0IHJlYWxs eSBleHBsb3JlIHRoZSBwb2xpY3kgaW1wbGljYXRpb25zIG9mIHRoZSBwcm9wb3NlZCBvciByZWNv bW1lbmRlZCBtaXRpZ2F0aW9ucy4NCg0KSWYgeW91IHN0YXJ0IHdpdGggbm8gbWl0aWdhdGlvbnMs IHRoZSBuZXQgZWZmZWN0IG9mIGJvdGggYW4gaXA9IG9yIGEgRE5TLWlnbm9yaW5nIE9SSUdJTiBm cmFtZSBpcyB0byBlZmZlY3RpdmVseSB0cmVhdCB0aGUgY2VydGlmaWNhdGUgYXMgYSA4MjUtZGF5 IEROUyBUVEwuIEJ5IGZyYW1pbmcgdGhlIHByb2JsZW0gYXMgIldoYXQncyB0aGUgd29yc3QgdGhh dCBjb3VsZCBoYXBwZW4gaWYgRE5TIGVudHJpZXMgaGFkIHRoZWlyIFRUTHMgaWdub3JlZCBhbmQg d2VyZSBjYWNoZWQgZm9yIDgyNSBkYXlzIiwgdGhhdCBtaWdodCBoZWxwIGV4cGxvcmUgdGhpbmdz IGZ1cnRoZXIuIFRoZSBzdWdnZXN0aW9uIG9mIE9DU1AgcmVkdWNlcyB0aGF0IFRUTCB0byA3IGRh eXMgKGVmZmVjdGl2ZWx5OyBkdWUgdG8gTWljcm9zb2Z0J3MgY29udHJhY3R1YWwgcmVxdWlyZW1l bnRzIG9uIHB1YmxpY2x5IHRydXN0ZWQgQ0FzKSwgYnV0IHRoYXQncyBzdGlsbCBzdWJzdGFudGlh bGx5IGxvbmdlci4NCg0KVGhhdCdzIHdoeSBpbnZvbHZpbmcgRE5TIGlzIGF0IGxlYXN0IHJlbGV2 YW50IHRvIHRoYXQgZGlzY3Vzc2lvbiwgZXNwZWNpYWxseSBnaXZlbiB0aGF0IHB1YmxpY2x5IHRy dXN0ZWQgY2VydGlmaWNhdGVzIGFyZSB0aGVtc2VsdmVzIHByZWRpY2F0ZWQgb24gRE5TLiBGdXJ0 aGVyLCBjb25zaWRlcmluZyB0aGF0IHRoZSBDQSBvbmx5IGhhcyB0byB2YWxpZGF0ZSBhIEROUyBv bmNlIHBlciA4MjUtZGF5IHBlcmlvZCwgYW5kIGNhbiBpc3N1ZSB1bmxpbWl0ZWQgODI1LWRheSBj ZXJ0aWZpY2F0ZXMgZHVyaW5nIHRoYXQgcGVyaW9kLCB0aGVuIHRoZSBlZmZlY3RpdmUgZXh0ZW5z aW9uIG9mIHJlbHlpbmcgc29sZWx5IG9uIGNlcnRpZmljYXRlcyAxNjUwIGRheXMgbWludXMgYSBz ZWNvbmQuDQo= --_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_ 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 cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpnbWFp bC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlIG11bHRpLUNETiBjYXNl IGlzIHRoZSBzY2FyaWVzdCBhc3BlY3Qgb2YgY29hbGVzY2luZyBhbmQgdGhlIHZhcmlvdXMgRE5T IHRyaWNrcyB3ZeKAmXZlIGJlZW4gZG9pbmcgaW4gcmVjZW50IHllYXJzLiZuYnNwOyBUaGUgc2Vy dmVyIG1heSBub3QgYmUgbWFsaWNpb3VzLCBtYXkgbm90IGV2ZW4gYmUgbWlzY29uZmlndXJlZCDi gJMgc2l0ZSBYIHVzZXMgRE5TIHRvIGR5bmFtaWNhbGx5IHNoYXJlIGxvYWQgYmV0d2Vlbg0KIENE TnMgQSBhbmQgRi4mbmJzcDsgSWYgWCBkZWNpZGVzIHRvIHN0YXJ0IG1vdmluZyBtb3JlIGxvYWQg dG8gQSwgRiBjb3VsZCBpbiBhbGwgZ29vZCBmYWl0aCBjb250aW51ZSB0byByb3V0ZSBjbGllbnRz IHRvIGl0c2VsZiBieSBwcm92aWRpbmcgY2FjaGVkLCBzaWduZWQgRE5TIHJlY29yZHMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbmR1c3RyeSBub3JtIGlzIHRoYXQgY2hhbmdpbmcgdGhl IEROUyByZWNvcmTigJlzIENOQU1FIHRvIGEgZGlmZmVyZW50IENETiBpcyB0aGUgY3V0LW92ZXIs IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgb3RoZXIgQ0ROIHJlbWFpbnMgY29uZmlndXJlZC4m bmJzcDsgSXTigJlzIGVmZmVjdGl2ZWx5IGFjdGluZyBhcyBhIOKAnGhvdCBzdGFuZGJ5LuKAnSZu YnNwOyBJZiBpdCBoYWQgdG8gcHJvdmlkZWQgYmV0dGVyIHByb29mIG9mIGZyZXNobmVzcywNCiB0 aGF0IG1pZ2h0IGJlIHN1ZmZpY2llbnQsIGJ1dCBob3cgZnJlc2ggaXMgc3VmZmljaWVudGx5IGZy ZXNoPyZuYnNwOyBBbmQgZG9lcyBETlNTRUMgcHJvdmlkZSB0aGF0IGZyZXNobmVzcyBndWFyYW50 ZWU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIEYgY291bGQgZG8gdGhpcyB0b2Rh eSB3aXRoIEFsdC1TdmMgYW5kIGhhdmUgdGhlIHNhbWUgaW1wYWN0LiZuYnNwOyBTZWNvbmRhcnkg Q2VydGlmaWNhdGVzIHByb3ZpZGVzIGFub3RoZXIgd2F5IHRoaXMgbWlnaHQgaGFwcGVuLiZuYnNw OyBTbyB0aGlzIHNoaXAgbWlnaHQgaGF2ZSBhbHJlYWR5IHNhaWxlZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IFJ5YW4gU2xlZXZpIFttYWlsdG86cnlhbi1pZXRmQHNsZWV2 aS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDEwLCAyMDE4IDEwOjUyIEFN PGJyPg0KPGI+VG86PC9iPiBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gVGVkIExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0OzsgSm9lIEFibGV5 ICZsdDtqYWJsZXlAaG9wY291bnQuY2EmZ3Q7OyBEb0ggV0cgJmx0O2RvaEBpZXRmLm9yZyZndDs7 IGRyaXVAaWV0Zi5vcmc7IGRuc29wIFdHICZsdDtkbnNvcEBpZXRmLm9yZyZndDs7IFBhdWwgV291 dGVycyAmbHQ7cGF1bEBub2hhdHMuY2EmZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0O3BtY21hbnVz QG1vemlsbGEuY29tJmd0OzsgUGhpbGlwIEhvbWJ1cmcgJmx0O3BjaC1kbnNvcC0zQHUtMS5waGlj b2guY29tJmd0OzsgSFRUUA0KIFdvcmtpbmcgR3JvdXAgJmx0O2lldGYtaHR0cC13Z0B3My5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRHJpdV0gW0ROU09QXSBbRG9oXSBSZXNvbHZl cmxlc3MgRE5TIFNpZGUgTWVldGluZyBpbiBNb250cmVhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBKdWwgMTAsIDIwMTggYXQgMTowNSBQTSwgQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkYW1Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGFtQG5vc3RydW0uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzEwLzE4IDExOjQxIEFNLCBUZWQgTGVtb24gd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJnbWFpbC0iPk9uIFR1ZSwgSnVsIDEwLCAyMDE4IGF0IDEyOjM0IFBNLCBKb2Ug QWJsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYWJsZXlAaG9wY291bnQuY2EiIHRhcmdldD0iX2Js YW5rIj5qYWJsZXlAaG9wY291bnQuY2E8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iZ21haWwtIj4mZ3Q7IEJ1dCB0aGlzIGlzIHJlYWxseSBlcXVpdmFsZW50IGluIGp1 c3QgYWJvdXQgZXZlcnkgaW1wb3J0YW50IHdheSB0byBzZW5kaW5nIHRoZSBub3JtYWwgJmx0O2lt ZyBzcmM9JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9pbWcvZi5qcGciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL2ltZy9mLmpwZzwvYT4mcXVvdDsmZ3Q7IGFs b25nIHdpdGggYSBwdXNoZWQgRE5TIHJlY29yZA0KIHRoYXQgaW5kaWNhdGVzIHRoYXQgJnF1b3Q7 PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXhhbXBsZS5jb208 L2E+JnF1b3Q7IHJlc29sdmVzIHRvICZxdW90OzE5Mi4wLjIuMSZxdW90OyAtLSBhbmQgdGhpcyBs YXR0ZXIgdGhpbmcgaXMgKHRvIG15IHVuZGVyc3RhbmRpbmcsIGF0IGxlYXN0KSBpbiBzY29wZSBv ZiB0aGUgY29udmVyc2F0aW9uIHRoYXQgUGF0cmljayBpcyBwcm9wb3NpbmcgdG8gaGF2ZS48L3Nw YW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+TXkgcXVlc3Rpb24gaXMgd2h5IHlv dSB3b3VsZCBpbnZvbHZlIHRoZSBETlMgYXQgYWxsIGlmIGFsbCB0aGU8L3NwYW4+PGJyPg0KPHNw YW4gY2xhc3M9ImdtYWlsLSI+cGVyZm9ybWFuY2UtYmFzZWQgcmVzb2x1dGlvbiBkZWNpc2lvbnMg Y2FuIGJlIG1hZGUgd2l0aG91dCBpdC4gWW91J3JlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJn bWFpbC0iPmp1c3QgYWRkaW5nIGNvc3QgYW5kIGNvbXBsZXhpdHkgd2l0aG91dCBiZW5lZml0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGlwPSBtb2RpZmllciB3b3VsZCBiZSBhIGdyZWF0IHdheSB0byBhcnJhbmdl IGZvciBzb21ldGhpbmcgdG8gbG9vayBsaWtlIGl0IGNhbWUgZnJvbSBhIGRpZmZlcmVudCBzb3Vy Y2UgdGhhbiBpdHMgYWN0dWFsIHNvdXJjZS4gJm5ic3A7IEknbSBzdXJlIHRoZXJlJ3MgYW4gYXR0 YWNrIHN1cmZhY2UgaW4gdGhlcmUgc29tZXdoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPktlZXBpbmcgaW4gbWluZCB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBwcm92aWRlZCBi eSB3aGF0ZXZlciBtYWNoaW5lIHlvdSByZWFjaGVkIHdvdWxkIG5lY2Vzc2FyaWx5IGhhdmUgdG8g bWF0Y2ggdGhlIFVSTCdzIG9yaWdpbiwgdGhpcyBpcyB2ZXJ5IG11Y2ggb25lIG9mIHRoZSBxdWVz dGlvbnMgdGhhdCBpcyBiZWluZyBhc2tlZDogaXMgdGhlcmU/PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+L2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLiBDb25z aWRlciBTaXRlIEEgKGZvby5leGFtcGxlKSBhbmQgU2l0ZSBCIChiYXIuZXhhbXBsZSkuIEJvdGgg cG9pbnQgdGhlbXNlbHZlcyB0byBDRE4gMSwgd2hpY2ggdGhlbiBvYnRhaW5zIGEgY2VydGlmaWNh dGUgZm9yIGJvdGggdGhlaXIgbmFtZXMgaW4gc3ViamVjdEFsdE5hbWVzLiBTaXRlIEIgdGhlbiBk ZWNpZGVzIHRoYXQgQ0ROIDEgaXMgYW4gdW5yZWxpYWJsZSBwYXJ0bmVyLCBhbmQgZ29lcyBDRE4N CiAyLCB1cGRhdGluZyBETlMgYXBwcm9wcmlhdGVseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB0aGUgc2FtZSBwcm9ibGVtIGlu IGNvbnNpZGVyaW5nIHRoZSBIVFRQLzIgY29hbGVzY2luZyB3aXRob3V0IGRvaW5nIEROUyByZXNv bHV0aW9uIChlaXRoZXIgYmVjYXVzZSBvZiBwb29yIHNlY3VyaXR5IHBvc3R1cmUgb3IgYnkgY29t YmluaW5nIE9SSUdJTiAmIzQzOyBTZWNvbmRhcnkgQ2VydGlmaWNhdGVzKS4gUkZDIDgzMzYgYnJp ZWZseSB0b3VjaGVzIG9uIHRoaXMgKCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4MzM2I3NlY3Rpb24tNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzgzMzYjc2VjdGlvbi00PC9hPg0KICkgYnV0IGRvZXNuJ3QgcmVhbGx5IGV4cGxvcmUgdGhlIHBv bGljeSBpbXBsaWNhdGlvbnMgb2YgdGhlIHByb3Bvc2VkIG9yIHJlY29tbWVuZGVkIG1pdGlnYXRp b25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB5b3Ugc3RhcnQgd2l0aCBubyBtaXRpZ2F0aW9ucywgdGhlIG5ldCBlZmZlY3Qgb2YgYm90 aCBhbiBpcD0gb3IgYSBETlMtaWdub3JpbmcgT1JJR0lOIGZyYW1lIGlzIHRvIGVmZmVjdGl2ZWx5 IHRyZWF0IHRoZSBjZXJ0aWZpY2F0ZSBhcyBhIDgyNS1kYXkgRE5TIFRUTC4gQnkgZnJhbWluZyB0 aGUgcHJvYmxlbSBhcyAmcXVvdDtXaGF0J3MgdGhlIHdvcnN0IHRoYXQgY291bGQgaGFwcGVuIGlm IEROUyBlbnRyaWVzIGhhZA0KIHRoZWlyIFRUTHMgaWdub3JlZCBhbmQgd2VyZSBjYWNoZWQgZm9y IDgyNSBkYXlzJnF1b3Q7LCB0aGF0IG1pZ2h0IGhlbHAgZXhwbG9yZSB0aGluZ3MgZnVydGhlci4g VGhlIHN1Z2dlc3Rpb24gb2YgT0NTUCByZWR1Y2VzIHRoYXQgVFRMIHRvIDcgZGF5cyAoZWZmZWN0 aXZlbHk7IGR1ZSB0byBNaWNyb3NvZnQncyBjb250cmFjdHVhbCByZXF1aXJlbWVudHMgb24gcHVi bGljbHkgdHJ1c3RlZCBDQXMpLCBidXQgdGhhdCdzIHN0aWxsIHN1YnN0YW50aWFsbHkgbG9uZ2Vy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGF0J3Mgd2h5IGludm9sdmluZyBETlMgaXMgYXQgbGVhc3QgcmVsZXZhbnQgdG8gdGhhdCBkaXNj dXNzaW9uLCBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgcHVibGljbHkgdHJ1c3RlZCBjZXJ0aWZpY2F0 ZXMgYXJlIHRoZW1zZWx2ZXMgcHJlZGljYXRlZCBvbiBETlMuIEZ1cnRoZXIsIGNvbnNpZGVyaW5n IHRoYXQgdGhlIENBIG9ubHkgaGFzIHRvIHZhbGlkYXRlIGEgRE5TIG9uY2UgcGVyIDgyNS1kYXkg cGVyaW9kLA0KIGFuZCBjYW4gaXNzdWUgdW5saW1pdGVkIDgyNS1kYXkgY2VydGlmaWNhdGVzIGR1 cmluZyB0aGF0IHBlcmlvZCwgdGhlbiB0aGUgZWZmZWN0aXZlIGV4dGVuc2lvbiBvZiByZWx5aW5n IHNvbGVseSBvbiBjZXJ0aWZpY2F0ZXMgMTY1MCBkYXlzIG1pbnVzIGEgc2Vjb25kLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_-- From nobody Tue Jul 10 12:02: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 40CF5131052; Tue, 10 Jul 2018 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 TCO7Gzya_x2R; Tue, 10 Jul 2018 11:57:26 -0700 (PDT) Received: from homiemail-a129.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E81130E51; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) Received: from homiemail-a129.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a129.g.dreamhost.com (Postfix) with ESMTP id 614F010002181; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=NMzpBgH2U2T5q54GvtwFqGAauEY=; b= NCDWlsEVSi7jzISpcBch+daRshwVdcBtuZOsU++CA0HC+NWXHyE9H4eeTFDWQc8b RJUH/8kfUThiuv0AAjux+4dW/xO6iT3Qxh9kTeu/5yRuyzlqwBYOGlxlScF/HHF2 OPAkH9XogBlo9Ng7NxlTu08hA0qsE+LloC5RC2+gG2U= Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a129.g.dreamhost.com (Postfix) with ESMTPSA id 51CC410002180; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id p185-v6so127200itp.4; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) X-Gm-Message-State: APt69E2WF8f3cRuhS51sAn9dKNDGpwwp0AoSFPenPbtoX8052mJ/yNac AhDHFHOxxYgLz+Mob9ApmXHCSX1yk9IG5GBIMi8= X-Google-Smtp-Source: AAOMgpf29o/XI/QmgdbET3+qmN80+ur+RYo1h4RZGDrLvB4XnOred8MZcckL5u3Ia8MiCAPhh5JZv36/tMWwwHNTXQ0= X-Received: by 2002:a24:684d:: with SMTP id v74-v6mr20894074itb.88.1531249044728; Tue, 10 Jul 2018 11:57:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:244:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 11:57:24 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: Ryan Sleevi Date: Tue, 10 Jul 2018 14:57:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mike Bishop Cc: Ryan Sleevi , Adam Roach , Ted Lemon , Joe Abley , DoH WG , "driu@ietf.org" , dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000005fba590570a9b393" Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 12:02:16 -0700 Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:57:29 -0000 --0000000000005fba590570a9b393 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop wrote: > Yes, the multi-CDN case is the scariest aspect of coalescing and the > various DNS tricks we=E2=80=99ve been doing in recent years. The server = may not be > malicious, may not even be misconfigured =E2=80=93 site X uses DNS to dyn= amically > share load between CDNs A and F. If X decides to start moving more load = to > A, F could in all good faith continue to route clients to itself by > providing cached, signed DNS records. > Yup. And, at least for browsers that follow a Priority of Constituency model, it seems more important to ensure that site operators wishes are respected over that of the CDNs they've used, or for their being a more explicit signal from the user that it truly intends to ignore the site operator. > > > The industry norm is that changing the DNS record=E2=80=99s CNAME to a di= fferent > CDN is the cut-over, regardless of whether the other CDN remains > configured. It=E2=80=99s effectively acting as a =E2=80=9Chot standby.= =E2=80=9D If it had to > provided better proof of freshness, that might be sufficient, but how fre= sh > is sufficiently fresh? And does DNSSEC provide that freshness guarantee? > Right, these are questions that need to be answered, and not just with abstract theoretical mitigations that don't or can't be deployed. > However, F could do this today with Alt-Svc and have the same impact. > Secondary Certificates provides another way this might happen. So this > ship might have already sailed. > The ship has only sailed for those foolish enough to ship those features :) That is, these are real security concerns, they have not been satisfactorily addressed, and security conscious implementations have held off implementing these features for precisely this reason. If there are implementations that have shipped, without understanding or considering the security harm they're doing, that doesn't seem like a good argument to keep building more features on the buggy premise. If they believe they have sufficiently mitigated those very real and practical security concerns, they would hopefully be sharing those concrete strategies and tradeoffs, rather than a Security Considerations that acknowledges the dragons without adequately describing how to avoid them (or how not to). --0000000000005fba590570a9b393 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <mbishop@evequefou.be<= /a>> wrote:

Yes, the multi-CDN case is the scariest aspect of co= alescing and the various DNS tricks we=E2=80=99ve been doing in recent year= s.=C2=A0 The server may not be malicious, may not even be misconfigured =E2= =80=93 site X uses DNS to dynamically share load between CDNs A and F.=C2=A0 If X decides to start moving more load to A, F could i= n all good faith continue to route clients to itself by providing cached, s= igned DNS records.


Yup. And= , at least for browsers that follow a Priority of Constituency model, it se= ems more important to ensure that site operators wishes are respected over = that of the CDNs they've used, or for their being a more explicit signa= l from the user that it truly intends to ignore the site operator.
=C2=A0


The ship has only sailed for those foolish e= nough to ship those features :) That is, these are real security concerns, = they have not been satisfactorily addressed, and security conscious impleme= ntations have held off implementing these features for precisely this reaso= n. If there are implementations that have shipped, without understanding or= considering the security harm they're doing, that doesn't seem lik= e a good argument to keep building more features on the buggy premise.

If they believe they have sufficiently mitigated those= very real and practical security concerns, they would hopefully be sharing= those concrete strategies and tradeoffs, rather than a Security Considerat= ions that acknowledges the dragons without adequately describing how to avo= id them (or how not to).
--0000000000005fba590570a9b393-- From nobody Tue Jul 10 18:23:10 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 124E7129C6A; Tue, 10 Jul 2018 18:23:04 -0700 (PDT) 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=mnot.net header.b=g+Yk8hBc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IvVT9vFs 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 cDAILX8905zN; Tue, 10 Jul 2018 18:23:02 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42C3127332; Tue, 10 Jul 2018 18:23:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CBC9521B9E; Tue, 10 Jul 2018 21:23:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 21:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=EBQI3ObNpEyvbBEkEaz29MaPRXpnC IjpCZ+YWZBgSr4=; b=g+Yk8hBcJMp+m8oWMS2Q2a5VKksfH/m9lLU6Zk6lXiC3n TYCfUlV9L7Cy7FW5+A2u+JUrNJmmlojXjD5x6qLnxLHnirj5uL7l+B5w7hgD+Uf9 WPzdxeJsyTxjJvazpkieLdaYXsNsxO646/rnwM6WMUEBxd6+oIZbbn5SsiMYgQCb 8NtbNGD3DrgBqez0mXiBCEtIYACdKb7lsUwyasLBXGmsUWINYdANzkX2oSmoBRwz dt20Q0iO23y65hNhsepGh1HbbtCyLJ25OKSGbkFKw3FOIwW2Dzpy9TkvvzBoDPRa UNKZr/106mDCTEljuUZsUOx41GxaWlpUk6q7EoZRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EBQI3O bNpEyvbBEkEaz29MaPRXpnCIjpCZ+YWZBgSr4=; b=IvVT9vFszEsfl6nEpeDy7e IpE91xgpTXCs9vmBpm96BezyeEtorOaSvDNxz5C5zuTiErXcSM/3t+CyJXctS9E2 LSnlVn80DxAM0jDy3XG4AseNUNxnIQQjpFRpokNYgliAHt56kRCnpfS3vFKjnVrp RlgQeDd0+O4jNoOLtzKvzw/y3TDDmyv08lyBPZffTI4AWAUord1abjQHkMDMyOXp pStyeHOC7O3AdCKFetcHac1Vh1pk3IJV4YhxNTlEe4v4nrcpqM7AFde2EPcck0QM I4VsKIhm8Ll21CSr+ImwIZpngrdCe4hJek8hpQWiD2iUH4JCjech1+aymWGII98g == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 4410CE405A; Tue, 10 Jul 2018 21:22:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: Date: Wed, 11 Jul 2018 11:22:55 +1000 Cc: Adam Roach , DoH WG , driu@ietf.org, dnsop@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Doh] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:23:04 -0000 > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >=20 > On Jul 10, 2018, at 18:02, Adam Roach wrote: >=20 >> In large part because DNS provides "a richer scheme that accommodates = address families and multiple addresses with priorities". >=20 > *cups hand to ear* >=20 > Was that the sound of a distant desire to specify use of SRV for HTTP? >=20 I recently did some digging on this topic, and can try to characterise = what the issues / objections are. Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 10 18:26: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 238D6129C6A for ; Tue, 10 Jul 2018 18:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 GzKX-oSvgVO2 for ; Tue, 10 Jul 2018 18:26:33 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::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 04563130EAB for ; Tue, 10 Jul 2018 18:26:30 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id b188-v6so755572wme.3 for ; Tue, 10 Jul 2018 18:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YfCeSR1woNfcgPU/y1hMxw6bD6VluXNZEvLMN7jfyHk=; b=epwzgmBKOYv0Jw4GswxcQ93JuiWnaSLMMnJc2Bee9ek9N3X1appGNHKY5R6/ORumQI uv4sSpgLT9K9YiRnxB1ndIZ/QdK1MJ55A6GcC/+rOAtuQlkoQgiyIX1mbDuefoi/5kUk gHagYi7uW+v9JEoc5F+80co8BJlbrjIa+3tqE= 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=YfCeSR1woNfcgPU/y1hMxw6bD6VluXNZEvLMN7jfyHk=; b=glsKgRIXTDLKEhWsYq6phg2bA5Iep64eNUDRxp64C4B6/+xGqgD2BJtKpPWCZUKMSY poRJ6pRXqkssa3GbxnYYGlkmqHAbHNAlTAzP8tNyVqTQ4tgEAYLrVQgEzDuIfEbNKIjJ UP5G+xP9jl7UyJK55DUvGO+BIBpx8fu9Cy1Y6xxeLPirqkuQpPoQ08mtqWl4ayZMNxGc mrarKBiawlMi1DUpDpqXPsNOSQOiq7vH0UBYoVG0+jwPW/reM8CYyS1Ji5qxffwp967b j7FvoEfsSpGZkSdUrN8i7LSH1x55hG7mVP/80rk0JTiFaNmvMUb0UbFssJJ+xSwlosa2 avSg== X-Gm-Message-State: APt69E0q0Vh6NUFuTWIX1HFqcJjV3Tj3jhjStGowUJ/4JJfpl4jq40yz x2wUh6L8z7Xqi8XlF3WxeQVgxe2ev3+6FnEU7zDhTg== X-Google-Smtp-Source: AAOMgpdgb2b8fkyhUvXUUturruyM4O8CbifLcDpMWBkwWgq/irc0oGOSOGamPK3vkT8i1mhMBsOEfCRSLsRxhLYpH3k= X-Received: by 2002:a1c:d602:: with SMTP id n2-v6mr15643972wmg.150.1531272388413; Tue, 10 Jul 2018 18:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:e44a:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 18:26:27 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Tue, 10 Jul 2018 21:26:27 -0400 Message-ID: To: Mark Nottingham Cc: Joe Abley , dnsop , DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000c4241e0570af229d" Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:26:35 -0000 --000000000000c4241e0570af229d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes On Tue, Jul 10, 2018 at 9:22 PM, Mark Nottingham wrote: > > > > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > > > On Jul 10, 2018, at 18:02, Adam Roach wrote: > > > >> In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > > *cups hand to ear* > > > > Was that the sound of a distant desire to specify use of SRV for HTTP? > > > > I recently did some digging on this topic, and can try to characterise > what the issues / objections are. > > Would people be interested in a (hopefully brief) side meeting to discuss > and maybe come to a shared understanding of the problem space? > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =C3=93lafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com --000000000000c4241e0570af229d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes=C2=A0

<= br>
On Tue, Jul 10, 2018 at 9:22 PM, Mark Notting= ham <mnot@mnot.net> wrote:

> On 11 Jul 2018, at 3:55 am, Joe Abley <jabley@hopcount.ca> wrote:
>
> On Jul 10, 2018, at 18:02, Adam Roach <adam@nostrum.com> wrote:
>
>> In large part because DNS provides "a richer scheme that acco= mmodates address families and multiple addresses with priorities".
>
> *cups hand to ear*
>
> Was that the sound of a distant desire to specify use of SRV for HTTP?=
>

I recently did some digging on this topic, and can try to characterise what= the issues / objections are.

Would people be interested in a (hopefully brief) side meeting to discuss a= nd maybe come to a shared understanding of the problem space?

Cheers,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



--
= =C3=93lafur Gudmundsson |=C2=A0Engineering= Director=C2=A0
--000000000000c4241e0570af229d-- From nobody Tue Jul 10 18:30: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 101A9130E9E; Tue, 10 Jul 2018 18:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 W0BTN5dMyGL7; Tue, 10 Jul 2018 18:30:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 08C37129C6A; Tue, 10 Jul 2018 18:30:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E824C3AB043; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A3D2C160072; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8FB1D16006B; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W4OLdSWo7R8c; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0AB5016006A; Wed, 11 Jul 2018 01:30:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Wed, 11 Jul 2018 11:30:20 +1000 Cc: Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:30:27 -0000 > On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >=20 >=20 >=20 >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>=20 >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>=20 >>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>=20 >> *cups hand to ear* >>=20 >> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>=20 >=20 > I recently did some digging on this topic, and can try to characterise = what the issues / objections are. I think there are three main objections. 1) Wildcards don=E2=80=99t work with prefixes. 2) Additional data isn=E2=80=99t always returned it may require multiple = round trips. 3) Additional data processing doesn=E2=80=99t support negative = responses. All of these issues are trivially easy to fix. It just require = willingness to implement. 1) is addressed by defining a new type(s) rather than using prefixes. 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. > Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 10 18:32: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 254F4130EB2; Tue, 10 Jul 2018 18:32:10 -0700 (PDT) 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=mnot.net header.b=NYCbfOXc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y0na1WHh 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 VGH7azKCzaBf; Tue, 10 Jul 2018 18:32:08 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E109130E9E; Tue, 10 Jul 2018 18:32:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9D1CF21BBE; Tue, 10 Jul 2018 21:32:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 21:32:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=SJHSDQW0ZFcwV65ySt4qqfPe9vcr9 QOjwKmSeAa7pWg=; b=NYCbfOXce98kVuWEG9ADfmdO1R9Ek6Hm5ixKgvUBzyMg1 d26kZlhTJupBDJB+eAXFamjueLCOKvIZCDY0522an3Ll1L+MOVMnLbawFZgvDjrl ggFeU1+dhRhnnauuSVP/kjF4iZ+ng55WP0mUnsjeqOl6pEzxF/veXoFX+880Y7ps ffkO70SO9WgbAzIIVDtQWcoXkw9qAamna9Dr2QrwDfuERBy0St6/37DPzqaDfe3x 7s/YzeLQYb6wKCshK/1ss3ikyrtPq/05bYxKRvcrt3kFt/gOqRHSqG5V9De7B2zX H3JYeF1M9COJ6PuUF6+sh7uwcZGeYCzciFYRfpYpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SJHSDQ W0ZFcwV65ySt4qqfPe9vcr9QOjwKmSeAa7pWg=; b=Y0na1WHh81Eu/3+fy4GWto sDOJH9PQaPtrntWB6OyGCTf+qi9QkrPJYm7bV//ch6h/QxMFvcKgdTys1b6YCWRe YgcK4/QHfuu5MSsl+W3l/E1NuA4C5KXl1ktZvelRyfdn/jg87uC936hZmwXphEnX YBkhVEoNwBU5+r4gS+Gftpid3GnMA4u5IXCMYxkeKX4pWPZ8+q8FtRBAB4P4RO4s 18dHLpLJKe8ZFY3sWEPAcgShno7b8bVpmYgtrVyXCsJ2witkh32PvWksSJ0veGWY Z+mFKbpKDlci1OBzVDl6ply4fkRBfkdKgkHDgEMD9d0FsAbILk5X6ZjctP2TCj5Q == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 06702E405A; Tue, 10 Jul 2018 21:32:04 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> Date: Wed, 11 Jul 2018 11:32:02 +1000 Cc: Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:32:11 -0000 I didn't find those, but I found many others. I'll start collecting. How about Tuesday, say 6:45-7:45pm? > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >=20 >=20 >=20 >> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >>=20 >>=20 >>=20 >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>>=20 >>> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>>=20 >>>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>>=20 >>> *cups hand to ear* >>>=20 >>> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>>=20 >>=20 >> I recently did some digging on this topic, and can try to = characterise what the issues / objections are. >=20 > I think there are three main objections. >=20 > 1) Wildcards don=E2=80=99t work with prefixes. > 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. > 3) Additional data processing doesn=E2=80=99t support negative = responses. >=20 > All of these issues are trivially easy to fix. It just require = willingness to implement. >=20 > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. > 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >=20 >=20 >> Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 10 18:37:35 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 A87A9130EAB; Tue, 10 Jul 2018 18:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 peqrUSp4J1Pb; Tue, 10 Jul 2018 18:37:26 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 EAD30130DD6; Tue, 10 Jul 2018 18:37:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BF4A73AB041; Wed, 11 Jul 2018 01:37:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 82A1E160072; Wed, 11 Jul 2018 01:37:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B13016006B; Wed, 11 Jul 2018 01:37:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iRbvBX2HhmUx; Wed, 11 Jul 2018 01:37:22 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A1B5D16006A; Wed, 11 Jul 2018 01:37:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> Date: Wed, 11 Jul 2018 11:37:16 +1000 Cc: Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <57193515-CDC7-442A-892F-D0DDF259B1E6@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:37:28 -0000 Fine by me. > On 11 Jul 2018, at 11:32 am, Mark Nottingham wrote: >=20 > I didn't find those, but I found many others. >=20 > I'll start collecting. How about Tuesday, say 6:45-7:45pm? >=20 >=20 >=20 >> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >>=20 >>=20 >>=20 >>> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >>>=20 >>>=20 >>>=20 >>>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>>>=20 >>>> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>>>=20 >>>>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>>>=20 >>>> *cups hand to ear* >>>>=20 >>>> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>>>=20 >>>=20 >>> I recently did some digging on this topic, and can try to = characterise what the issues / objections are. >>=20 >> I think there are three main objections. >>=20 >> 1) Wildcards don=E2=80=99t work with prefixes. >> 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. >> 3) Additional data processing doesn=E2=80=99t support negative = responses. >>=20 >> All of these issues are trivially easy to fix. It just require = willingness to implement. >>=20 >> 1) is addressed by defining a new type(s) rather than using prefixes. >> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >>=20 >>=20 >>> Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? >>>=20 >>> Cheers, >>>=20 >>> -- >>> Mark Nottingham https://www.mnot.net/ >>>=20 >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 10 18:51:14 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 AF0CE12E039; Tue, 10 Jul 2018 18:51:12 -0700 (PDT) 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, SPF_PASS=-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 c7u3_RiCoBjg; Tue, 10 Jul 2018 18:51:11 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C44127148; Tue, 10 Jul 2018 18:51:11 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9248F47C3F; Tue, 10 Jul 2018 21:51:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23365.25230.573067.921128@gro.dd.org> Date: Tue, 10 Jul 2018 21:51:10 -0400 From: Dave Lawrence To: Mark Nottingham Cc: Mark Andrews , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:51:13 -0000 Mark Nottingham writes: > I'll start collecting. How about Tuesday, say 6:45-7:45pm? Last session ends at 6:20 and social starts at 7, not sure how late the last bus (if any?) will be leaving the hotel. From nobody Tue Jul 10 18:53:00 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 8F51112E039; Tue, 10 Jul 2018 18:52:55 -0700 (PDT) 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, SPF_PASS=-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 4eqy6DODHyjO; Tue, 10 Jul 2018 18:52:54 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D51127148; Tue, 10 Jul 2018 18:52:54 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E103347C47; Tue, 10 Jul 2018 21:52:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23365.25333.904112.575031@gro.dd.org> Date: Tue, 10 Jul 2018 21:52:53 -0400 From: Dave Lawrence To: Mark Nottingham , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley In-Reply-To: <23365.25230.573067.921128@gro.dd.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:52:56 -0000 Dave Lawrence writes: > Mark Nottingham writes: > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. Nevermind, walking distance to social, under 1km. Maybe still though shifting it a little earlier, like 18:30. From nobody Tue Jul 10 18:58: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 34CC3130E82; Tue, 10 Jul 2018 18:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 w53nu-PMZs57; Tue, 10 Jul 2018 18:58:18 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 02304130DE8; Tue, 10 Jul 2018 18:58:18 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C9B933AB041; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9A3A616006A; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8610816006B; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BgkaAGvZRlmq; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DB21016006A; Wed, 11 Jul 2018 01:58:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <23365.25230.573067.921128@gro.dd.org> Date: Wed, 11 Jul 2018 11:58:13 +1000 Cc: Mark Nottingham , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:58:23 -0000 > On 11 Jul 2018, at 11:51 am, Dave Lawrence wrote: >=20 > Mark Nottingham writes: >> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >=20 > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. It=E2=80=99s a 9 minute walk (4 blocks). --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 10 19:25: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 CF14912E039; Tue, 10 Jul 2018 19:25:47 -0700 (PDT) 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=mnot.net header.b=DSgUxvRN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AIFvcHOZ 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 K-3S97mUPoZi; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32C1130DCD; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E10DA21B81; Tue, 10 Jul 2018 22:25:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 22:25:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=OYJezIELdhXV3tTTU1inb6Ed+WHTS e5+6W7TmEh1do4=; b=DSgUxvRNgy00Q43sJgwrAkXlvKvb7YKX1OWKU/ZAEj40e SMEf/FQpmkWxrwtSAj+bXot/jNjVtafWwMhGSwFeRkxdjheKVbuHreDO2qgaf/0V DpSXiGswyZwNdKVd5S+4DmweYxzTEGveIIjSgTCTMsZuocGSr3h2qnDU3CTRXV7C h1HiHLk4FBPf9r1HdBBcnDg1eP08BebgrcX9ns2ZLIfcIQKxcyS3N1zfQfwSolUv WvWuzkbNz1O7oHgjZJimxctkQV5yQpURDX1SuMyxRY8h6uXCzuubxmK7OGFMtCRk JxMET7miwsvRQGyC4iODca9lrlmolf8Y8p8fdPXLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=OYJezI ELdhXV3tTTU1inb6Ed+WHTSe5+6W7TmEh1do4=; b=AIFvcHOZkwWpYJHvYtp/Qj y0yc8UmbeeuNZvIhoUxN1i91zf6g481eWqviewGANIQMOZ4RLroL/JVLV/WMJQ+R gtmKreQytMxRrPircT097nWawRdN2ZGxC4gKzF89S5I0SuvdaMZrAomXELo+1LSw PmfpZ/NI3xb2+jhx+tkXOa/iBLH7P1TpCYjJrp1aJ81aVhM+RseqP821UhqVQBJy Ho99IFrX/e4J/t4TDM829kXKihB0AwcQhl62vuOgcaSGgJ/DIkUXuxVssDou71f0 gxQ7pVYMM/TGQt5CIynPaztoqD2WOGv+ojJG2mvySkLVheCMS/cIROLUCYJvwQMw == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D277E4516; Tue, 10 Jul 2018 22:25:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: <23365.25333.904112.575031@gro.dd.org> Date: Wed, 11 Jul 2018 12:25:38 +1000 Cc: DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Doh] SRV and HTTP - 18:30 Tuesday X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:25:48 -0000 Sure, with the understanding that we'll probably start a few minutes = after that, given the session end at 16:20 (I'm chairing then, it = usually takes a little while to get out). I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. Cheers, > On 11 Jul 2018, at 11:52 am, Dave Lawrence wrote: >=20 > Dave Lawrence writes: >> Mark Nottingham writes: >>> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >>=20 >> Last session ends at 6:20 and social starts at 7, not sure how late >> the last bus (if any?) will be leaving the hotel. >=20 > Nevermind, walking distance to social, under 1km. Maybe still though > shifting it a little earlier, like 18:30. >=20 > _______________________________________________ > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 10 22:53:48 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 83A9B130E02; Tue, 10 Jul 2018 22:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 dxMXrxxtdsgY; Tue, 10 Jul 2018 22:53:39 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFE1126F72; Tue, 10 Jul 2018 22:53:39 -0700 (PDT) Received: from [169.254.214.146] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 4BB7A22078; Wed, 11 Jul 2018 07:53:36 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Mark Andrews" Cc: "Mark Nottingham" , "DoH WG" , "Adam Roach" , driu@ietf.org, dnsop@ietf.org, "HTTP Working Group" , "Joe Abley" Date: Wed, 11 Jul 2018 07:53:35 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> In-Reply-To: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 05:53:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11 Jul 2018, at 3:30, Mark Andrews wrote: > I think there are three main objections. > > 1) Wildcards don=E2=80=99t work with prefixes. > 2) Additional data isn=E2=80=99t always returned it may require multipl= e round trips. > 3) Additional data processing doesn=E2=80=99t support negative response= s. 4) Various libraries in PHP and ultimately lib curl do not include SRV in= the resolution 5) New resource record types are very hard to implement (same argument as= why we use TXT for SPF and not SPF for example) 6) You "only" change hostname with SRV and not a "complete change of the = URL" > All of these issues are trivially easy to fix. It just require willing= ness to implement. > > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing additio= nal data before returning. Named has code in review for this for SRV as = proof of concept. > 3) is addressed by adding some signalling between the client and recurs= ive server to indicate if the additional section is complete or not. 4) Is of course "just code" in lib curl and what not 5) Is like (4) but possibly harder if you want it implemented in PHP, jav= ascript etc and not in the underlying libraries 6) This is why I came up with URI which is supposed to be a competitor to= "well known URI" paf --=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCW0WbXw8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182jdACgjBgO7Src+l5thvu8Y74cmzloG8QAn1eSfRQ+ COid72LPngyhhRJW9jgM =wxLI -----END PGP SIGNATURE----- --=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_=-- From nobody Tue Jul 10 23:21:57 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 E8359130EBF; Tue, 10 Jul 2018 23:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 yyei5UxS3VbC; Tue, 10 Jul 2018 23:21:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 7479E130E13; Tue, 10 Jul 2018 23:21:40 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 16E803AB03F; Wed, 11 Jul 2018 06:21:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D9F4B16006A; Wed, 11 Jul 2018 06:21:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B051316006B; Wed, 11 Jul 2018 06:21:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1WPY288j99Zw; Wed, 11 Jul 2018 06:21:39 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C51FB16006A; Wed, 11 Jul 2018 06:21:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> Date: Wed, 11 Jul 2018 16:21:35 +1000 Cc: Mark Nottingham , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 06:21:44 -0000 > On 11 Jul 2018, at 3:53 pm, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 > On 11 Jul 2018, at 3:30, Mark Andrews wrote: >=20 >> I think there are three main objections. >>=20 >> 1) Wildcards don=E2=80=99t work with prefixes. >> 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. >> 3) Additional data processing doesn=E2=80=99t support negative = responses. >=20 > 4) Various libraries in PHP and ultimately lib curl do not include SRV = in the resolution Then PHP is not STD 13 compliant. Resolver libraries are supposed to be = able resolve UNKNOWN records per STD 13 and that includes SRV. As for lib curl, there is not a RFC that says to lookup SRV records for = HTTP or HTTPS. > 5) New resource record types are very hard to implement (same argument = as why we use TXT for SPF and not SPF for example) SPF was just plain unwillingness to complete the transition. The code = was out there. It was being deployed. TXT to SPF transition was never = part of the experiment, it was in addition to the experiment. No resources record is hard to implement. What hard is getting someone = to commit 30 minutes to 1 hour of time to do something at all. That is = what it takes most pieces of software to add a new record type. Thats = been true since I started in the DNS back in the early 90=E2=80=99s. > 6) You "only" change hostname with SRV and not a "complete change of = the URL >> All of these issues are trivially easy to fix. It just require = willingness to implement. >>=20 >> 1) is addressed by defining a new type(s) rather than using prefixes. >> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >=20 > 4) Is of course "just code" in lib curl and what not >=20 > 5) Is like (4) but possibly harder if you want it implemented in PHP, = javascript etc and not in the underlying libraries >=20 > 6) This is why I came up with URI which is supposed to be a competitor = to "well known URI" >=20 > paf --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 11 07:54:37 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 3B21E130EDF; Wed, 11 Jul 2018 01:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 6qimPhtgKsj3; Wed, 11 Jul 2018 01:23:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 387C5130ED6; Wed, 11 Jul 2018 01:23:29 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:dc58:aeeb:87f9:51f8] (unknown [IPv6:2001:67c:1220:80c:dc58:aeeb:87f9:51f8]) by mail.nic.cz (Postfix) with ESMTPSA id E462F600FF; Wed, 11 Jul 2018 10:23:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1531297405; bh=LHnuk7xCUvKAhdUEXuQO/0trUrxPE3WKUOHJmcTstec=; h=To:From:Date; b=oR02KeTY6sBXzaFYnJl1HshzUA6KpdfLjWPQrVfY4FtgzaIauvpnwTjpeUDhDy75Q 8fYbCD5CE/pRb8n92SCwnT68kAF3xWAoNHnz9SGqT0dwgNVQ4LBipeNxQOcNawhVDU DlBmpl+rAgS3Gy8WY67TX9ZMfWRd8POl2r/Y6fyo= To: Ryan Sleevi , Mike Bishop Cc: DoH WG , Adam Roach , "driu@ietf.org" , Philip Homburg , dnsop WG , Ted Lemon , Patrick McManus , Paul Wouters , Joe Abley , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= xsFNBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABzSJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+wsF9BBMBCAAnBQJYa4wfAhsDBQkDwmcABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEM6N1qGlCiHkjGoP/3fvimzczcaqPM8lgY9fKKcr2DhH 42HF+fXsj0SvPeEoYDuWwIcsTGna6sdmrhCD/mB6eCNivAOcZYDH7j3YDgdFX2xy1sRY0ylF uyfcOT1Qn1xNTglSaf00gUWDgLBQB/USphB9Of6U1ka4gLJpCWKoZ3cLQe09cUpq9HOZYs/g WSNx9UTr06fcO0rtgZpg+IZJN/R2ORhQBwk4n2Dtx5J+Xyoy7ht1Fwz07BWAGJ4P8oJOhsi1 LukDD8ul3+6IeoSbRvyGpP6boegaMwxPR10VgsrYU2t1cK58iRv/xJ3TClb0JBn5aI3Bmh1j mPROrC55tvxRoeRLmxXHzbPZpWdbRjEcf9SEiAGNTgo9C+eXbubeSETWgisfJhZ4ebhkHnfz e+e+hvbaTSoFyMbKeOlfoYCmaDRBgT53i72HIkvO+HrVcmulZytw/yyOHuwObEFVgn3AeORv rb8I1kiv5W4wnZxDslhCeRR+wMGiKhc9ewU/mg3Rqo6GN+8mT0DHnsHuq1lu3WYslfNYkBSo nFcctFD2KXVozrwpn3vWJ4Qt6qu5XS1lDCD5WshZXh7qoISWnnMqsMyBW/R7WyiABeIz4uOg SkRwT2wSUYr+JtBZIjREy2JQDVhjf18DL1Qa7OxSes8YwWSx1pQAzwbfFx0gzRDyIT/39le4 pX430yTQzsFNBFhri/0BEADFp4ZfxSoKTAad0IkFK9CVoZ6XKywYLFNPPhzw++gbvHL2EX7Q qhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQou0FeSNnzRGb607U8OFOPQ+ei92Mm 1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkhwtWU/6yo+RZs7cFRuihuLl8FuoP0 A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAwGDtjWkBVawpoHWwq58OQSx5piwyO CnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdWJw5OV9BoA7UTHG95xVHV5QiEm6q6 igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8mmKyS8E+mSh3djmqdJNHF1pJqKxA xPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03duzocyU95DfP/lwNJr5SH918Vf1t7 WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkSeXNoMlHJOIqbqm7N414I0HytbENf 7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw3f3Gn3+PDzGEHI9sfQv/mYvO77oR SGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6IfZZ0OIWKLSRa/DQARAQABwsFlBBgB CAAPBQJYa4v9AhsMBQkDwmcAAAoJEM6N1qGlCiHkn54P/AgyzrffYzRq6d7vHfFhd8HzHHrU BtOK+5182DME1JX9Aow5Dy9kbfxAfTc4tbCY5EnhoUICbmVAJ5wL5lrGxQPSnulIyF8OmJjc VlGI6zXYvP0VHZ/L8dPcf+RPqhMCPpaxe2+h5XpPxvOkDLlnCrsA4J1bAGW5kpxdGnY4aRrv aKhtGMqgSwSx25l3RnoOROU/hTDV4EHCuTkMRfILmsuNT7It40iL5nyDiJ8o3p1CLjRwUzVn 4r4jE8DXhbWXaKJ0KQZpKiQDVV7qJcJIeBJvZpFfxJ44LxBct9TkC69ROntYhd6M7031DT3P IYW9VyMhLN5dRfzhEdFUc+3AlnoOOKcGwYiCnH2DwDva3ZicOAH8099mWZcwVL/sjKKbJGPo JbdT9C3gSnsoa3uBbsiChRhAno80Jsk/igb4QaMw4PsS3230kfBGkQ/oAPPM0iJ9kn8NXB/9 iBe5cKEUiiYQfSn9x1HyG0sT3/jSYaq3obmBNHJE24w/RKWoPsaKjoyaInAuU5L0cNZ30OWd eWFREIxlajFl2vXb9nCc80/i6PceJySiyJgd5cYEL4hfn/B6RXph9kAJySsqlIZoBhcwneGX mAS0M41jJjuIQdt5pkLhM9XoXjBFMGGtA/CtiicEgitItJfVCxdLG4bZOCrfPmevMGLxpEmB GouQ9dVQ Organization: CZ.NIC Message-ID: <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz> Date: Wed, 11 Jul 2018 10:23:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Wed, 11 Jul 2018 07:54:36 -0700 Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 08:23:34 -0000 On 10.7.2018 20:57, Ryan Sleevi wrote: > > > On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop > wrote: > > Yes, the multi-CDN case is the scariest aspect of coalescing and the > various DNS tricks we’ve been doing in recent years.  The server may > not be malicious, may not even be misconfigured – site X uses DNS to > dynamically share load between CDNs A and F.  If X decides to start > moving more load to A, F could in all good faith continue to route > clients to itself by providing cached, signed DNS records. > > > Yup. And, at least for browsers that follow a Priority of Constituency > model, it seems more important to ensure that site operators wishes are > respected over that of the CDNs they've used, or for their being a more > explicit signal from the user that it truly intends to ignore the site > operator. >   > > ____ > > __ __ > > The industry norm is that changing the DNS record’s CNAME to a > different CDN is the cut-over, regardless of whether the other CDN > remains configured.  It’s effectively acting as a “hot standby.”  If > it had to provided better proof of freshness, that might be > sufficient, but how fresh is sufficiently fresh?  And does DNSSEC > provide that freshness guarantee? > > > Right, these are questions that need to be answered, and not just with > abstract theoretical mitigations that don't or can't be deployed. Signatures in DNSSEC (i.e. RRSIG records) have validity period with 1-second granularity so in theory it allows fine-tunning. Of course shorter validity means more cryptographic operations to update signatures etc. Taking into account that Cloudflare signs all recorsd on the fly, it is clearly feasible for CDN to generate fresh signatures on every DNS request. Petr Špaček @ CZ.NIC > However, F could do this today with Alt-Svc and have the same > impact.  Secondary Certificates provides another way this might > happen.  So this ship might have already sailed. > > > The ship has only sailed for those foolish enough to ship those features > :) That is, these are real security concerns, they have not been > satisfactorily addressed, and security conscious implementations have > held off implementing these features for precisely this reason. If there > are implementations that have shipped, without understanding or > considering the security harm they're doing, that doesn't seem like a > good argument to keep building more features on the buggy premise. > > If they believe they have sufficiently mitigated those very real and > practical security concerns, they would hopefully be sharing those > concrete strategies and tradeoffs, rather than a Security Considerations > that acknowledges the dragons without adequately describing how to avoid > them (or how not to). From nobody Wed Jul 11 09:24:51 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 D3DBE130F59; Wed, 11 Jul 2018 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ogre.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 f9i0FTXmC-1o; Wed, 11 Jul 2018 09:24:47 -0700 (PDT) Received: from cosmo.ogre.com (cosmo4.ogre.com [71.6.165.248]) (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 28D7D130F58; Wed, 11 Jul 2018 09:24:47 -0700 (PDT) Received: by cosmo.ogre.com (8.15.2/8.15.2) with ESMTPSA id w6BGOiVN008931 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jul 2018 09:24:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ogre.com; s=03062012; t=1531326285; bh=4epcr6NZvRK6VAwstEbx4ltZJzuEdPI0QD7spVgkygU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=crrWJBjtd/ISL4gYU6NiricdESriDJW4eq5DgPoeeXCMduztOc3HH72LQ+ymoRx6f 1puQ0zyO6DxcdyR+t6qWkq7Njh1fb7wyr7z1dnk95S+M00fgxFsio9GbdRJXuz9AxI QwLjcHz3qgASTAvUOAJGjVgo9ggdkSO+cl2qG1tU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Leif Hedstrom In-Reply-To: Date: Wed, 11 Jul 2018 10:24:43 -0600 Cc: Joe Abley , Adam Roach , DoH WG , driu@ietf.org, dnsop@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <4C5A84AA-C599-4294-AE55-52B2CC233D40@ogre.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Doh] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:24:49 -0000 > On Jul 10, 2018, at 7:22 PM, Mark Nottingham wrote: >=20 >=20 >=20 >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>=20 >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>=20 >>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>=20 >> *cups hand to ear* >>=20 >> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>=20 >=20 > I recently did some digging on this topic, and can try to characterise = what the issues / objections are. >=20 > Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? Definitely. We (Traffic Server) added some support for SRV a while back, = but it=E2=80=99s mostly a hack. Cheers, =E2=80=94 Leif From nobody Wed Jul 11 12:20:40 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 154EE130EDB; Wed, 11 Jul 2018 12:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 amgDUdEG8A1T; Wed, 11 Jul 2018 12:20:34 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8101130E57; Wed, 11 Jul 2018 12:20:33 -0700 (PDT) Received: from [169.254.207.132] (90-226-123-103-no2430.tbcn.telia.com [90.226.123.103]) by mail.frobbit.se (Postfix) with ESMTPSA id 517DA22ED4; Wed, 11 Jul 2018 21:20:30 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Mark Andrews" Cc: "Mark Nottingham" , "DoH WG" , "Adam Roach" , driu@ietf.org, dnsop@ietf.org, "HTTP Working Group" , "Joe Abley" Date: Wed, 11 Jul 2018 21:20:29 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <6899AB89-7B85-496E-B231-1CB6B4341166@frobbit.se> In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 19:20:38 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 11 Jul 2018, at 8:21, Mark Andrews wrote: > As for lib curl, there is not a RFC that says to lookup SRV records for= HTTP or HTTPS. Agree, and I have wanted it to be part of HTTP/2, or at least resolve thi= s mess, but it did not happen. This is my recurring discussion with Daniel when we have beer :-D paf --=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCW0ZYfQ8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182GbwCeMx1GiHJXZOAS2NM/OXmcCGgJtQ0An1ar1f6U nEWOKucUj8qAXhAglCcO =yBaV -----END PGP SIGNATURE----- --=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_=-- From nobody Wed Jul 11 14:24:46 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 31CA4130FBB; Wed, 11 Jul 2018 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=2.851] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 lXDXVN-Pjbo7; Wed, 11 Jul 2018 14:24:32 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CF1130FCB; Wed, 11 Jul 2018 14:24:32 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 95D0D20047613; Wed, 11 Jul 2018 14:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=xPKVnZ4/vNP10qcQ0dMbRsKEbkA=; b=dvbs53irB00 eznSocVoVCNHX2rcDhbmBJBxlClzec1bANNMl/xXPwd0cj0QqsWwmje0/jaeFr+K fRNh7kVzRPIuFFjs6HuHUnv5ydtGHAJ0fEPi6NrKeGQxhXnKL/85Sinhrmm6mcNS FJz5Z3NpYlYTZjO1vJ3FPx1Rcj6/Cyu8= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id D0D432004760B; Wed, 11 Jul 2018 14:24:29 -0700 (PDT) Date: Wed, 11 Jul 2018 16:24:28 -0500 From: Nico Williams To: Mark Nottingham Cc: Mark Andrews , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Message-ID: <20180711212427.GA9723@localhost> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 21:24:41 -0000 > > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > > > > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > > > > > > > *cups hand to ear* > > > >=20 > > > > Was that the sound of a distant desire to specify use of SRV for > > > > HTTP? > >=20 > > I think there are three main objections. > >=20 > > 1) Wildcards don=E2=80=99t work with prefixes. > > 2) Additional data isn=E2=80=99t always returned it may require multi= ple round trips. > > 3) Additional data processing doesn=E2=80=99t support negative respon= ses. > >=20 > > All of these issues are trivially easy to fix. It just require willi= ngness to implement. > >=20 > > 1) is addressed by defining a new type(s) rather than using prefixes. While that is correct, and truly, it is trivial to implement, it is not trivial to deploy: too many DNS hosting providers would have to update UIs. Let me add my voice in favor of new RR types by which to replace SRV RRs. URI is one of them, for the sorts of things we do in Kerberos for KDC discovery, but no really appropriate for resolving HTTP authorities. > > 2) is addressed by getting recursive servers to fill in missing addit= ional data before returning. Named has code in review for this for SRV a= s proof of concept. That would be very nice indeed. Unbound will need that too. > > 3) is addressed by adding some signalling between the client and recu= rsive server to indicate if the additional section is complete or not. Well, OK, but as with (2) that requires recursive resolver critical mass. Not necessarily a big deal, though it will take enough time that many apps will need to support falling back to doing multiple queries one by one. Nico --=20 From nobody Wed Jul 11 14:29: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 705BB1277BB; Wed, 11 Jul 2018 13:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 mEhFFremXvW0; Wed, 11 Jul 2018 13:42:39 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D86F130E18; Wed, 11 Jul 2018 13:42:39 -0700 (PDT) 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:X-MS-Exchange-SenderADCheck; bh=AuPPMbGuiP2BK/A6GT1Ed5mpiV1rsFP8iQ5Qmq38fkU=; b=JHgeRrcyDDymIlqoTGuyjTZ9x2Ts2meHeixxxbdy9itn1vUM6clkTt+zmxjpyLH8TsVK0aWf/ppsY5/cRYI/JTIxs2mG0e8PawAVz0heXGL7lZZAj31Rk4AFGtVuWSc/GQrplc06hLNryLTvRV8odFVDvhSNPC2gizsYtyR0nmU= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4887.namprd08.prod.outlook.com (20.176.255.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Wed, 11 Jul 2018 20:42:34 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3%2]) with mapi id 15.20.0952.017; Wed, 11 Jul 2018 20:42:34 +0000 From: Mike Bishop To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , Ryan Sleevi CC: DoH WG , Adam Roach , "driu@ietf.org" , Philip Homburg , dnsop WG , Ted Lemon , Patrick McManus , Paul Wouters , Joe Abley , HTTP Working Group Thread-Topic: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal Thread-Index: AQHUGPBzCI/u0plagkGhGyhgf/ZcS6SKfHmA Date: Wed, 11 Jul 2018 20:42:34 +0000 Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz> In-Reply-To: <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz> 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; BYAPR08MB4887; 7:gzqzOItI00S+HqG48e1K+TOt7VFKLj70VIBcJjZZFNPwVCYeehc1dYkd0qSOW1+Nd+v6e4xn1J/rbjXn79RyO9ktGjzjUJz7JqU2ByxtQEMSccwMoSeX/wcOCXDupr/tQ6D8+hzlDDuc6RuA5dCrIXwL6wjYmLf2QD/B0mVBf5hQ+WkBcnunAVmCpILGedyNDmNIZ8UPc5B2s+5lm7Ekd098WFUggyo15c2fWj3Md0hVPCbvvdi3owBg4abeeBZq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a8502440-8072-41ac-753b-08d5e76ed4f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4887; x-ms-traffictypediagnostic: BYAPR08MB4887: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(209352067349851)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4887; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4887; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39830400003)(376002)(346002)(396003)(199004)(189003)(13464003)(74482002)(105586002)(25786009)(81166006)(102836004)(6506007)(229853002)(53546011)(8676002)(81156014)(76176011)(7416002)(256004)(5660300001)(74316002)(68736007)(2900100001)(8936002)(99286004)(33656002)(7736002)(6436002)(97736004)(53936002)(305945005)(14454004)(9686003)(106356001)(7696005)(2906002)(55016002)(4326008)(110136005)(476003)(316002)(93886005)(54906003)(478600001)(14444005)(6116002)(86362001)(11346002)(3846002)(486006)(5250100002)(26005)(446003)(186003)(66066001)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4887; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: MqriETs1p1yQf89wt096RDlwyExowc2x9L4Vv0gQQ4yTCjBdwCPElbejjhHgdqHMnv327Pu6no3943DtLL3tFlsrb5krpu9smppMKUiiRAP0UnSAa9ekt1ma1OvKMznR0/lg2xQnfSLlUETIvdkFMrGleCUVeL9T3UyVldQT2Z1QJmKlQdin4+eH4G1QIbL1DXf2labXi1orLVAnnMzwtQjWhdh9bvlqgidqO1VSLPJKX7AE89e6BmWwnibJs69nxdqR9WnzUe5dFQ6+xuCeuNmlGrnFGv6m8lqEd6RLfzT5/KfVC//sruYu7vyurPXEbPJfzu9PsYnaog6qHFUpAygqFin+pSEZou3/UuVVB/M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: a8502440-8072-41ac-753b-08d5e76ed4f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2018 20:42:34.5785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4887 Archived-At: X-Mailman-Approved-At: Wed, 11 Jul 2018 14:29:08 -0700 Subject: Re: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 20:42:43 -0000 QnV0IGl0J3Mgbm90IG5lY2Vzc2FyaWx5IHRoZSBDRE4gdGhhdCdzIGdlbmVyYXRpbmcgdGhlIHNp Z25lZCByZWNvcmRzIGluIHRoZSBnZW5lcmFsIGNhc2UuICBZb3UncmUgd2FudGluZyBwcm9vZiB0 aGF0IHRoZSBjdXN0b21lcidzIGRvbWFpbiBpcyBwb2ludGVkIHRvIHRoYXQgQ0ROLCBzbyBpdCdz IHNpZ25lZCBieSB3aG9ldmVyIG1hbmFnZXMgdGhlIEROUyBpbmZyYXN0cnVjdHVyZSBpbnN0ZWFk LiAgVGhhdCBjb3VsZCBiZSBvbmUgb2YgdGhlIENETnMsIG9yIHRoZSBjdXN0b21lcidzIG9wZXJh dGlvbnMgdGVhbSwgb3IgYSB0aGlyZC1wYXJ0eSBwcm92aWRlciBhbHRvZ2V0aGVyLg0KDQpCdXQg eWVzLCBjbGVhcmx5IGl0J3MgcG9zc2libGUgZm9yIGF0IGxlYXN0IHNvbWUgcGFydGllcyB0byBk byBvbmxpbmUgc2lnbmluZyBpbiByZWFsLXRpbWUuICBUaGF0J3MgYXQgdmFyaWFuY2Ugd2l0aCB0 aGUgYWlyZ2FwcGVkIHNpZ25hdHVyZSBrZXkgZGVzaWduIEkndmUgaGVhcmQgaW4gb3RoZXIgY2Fz ZXMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQZXRyIMWgcGHEjWVrIFtt YWlsdG86cGV0ci5zcGFjZWtAbmljLmN6XSANClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMSwgMjAx OCAxOjIzIEFNDQpUbzogUnlhbiBTbGVldmkgPHJ5YW4taWV0ZkBzbGVldmkuY29tPjsgTWlrZSBC aXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPg0KQ2M6IERvSCBXRyA8ZG9oQGlldGYub3JnPjsg QWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47IGRyaXVAaWV0Zi5vcmc7IFBoaWxpcCBIb21i dXJnIDxwY2gtZG5zb3AtM0B1LTEucGhpY29oLmNvbT47IGRuc29wIFdHIDxkbnNvcEBpZXRmLm9y Zz47IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFu dXNAbW96aWxsYS5jb20+OyBQYXVsIFdvdXRlcnMgPHBhdWxAbm9oYXRzLmNhPjsgSm9lIEFibGV5 IDxqYWJsZXlAaG9wY291bnQuY2E+OyBIVFRQIFdvcmtpbmcgR3JvdXAgPGlldGYtaHR0cC13Z0B3 My5vcmc+DQpTdWJqZWN0OiBSZTogW0RvaF0gW0RyaXVdIFtETlNPUF0gUmVzb2x2ZXJsZXNzIERO UyBTaWRlIE1lZXRpbmcgaW4gTW9udHJlYWwNCg0KT24gMTAuNy4yMDE4IDIwOjU3LCBSeWFuIFNs ZWV2aSB3cm90ZToNCj4gDQo+IA0KPiBPbiBUdWUsIEp1bCAxMCwgMjAxOCBhdCAyOjA5IFBNLCBN aWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmUgDQo+IDxtYWlsdG86bWJpc2hvcEBldmVx dWVmb3UuYmU+PiB3cm90ZToNCj4gDQo+ICAgICBZZXMsIHRoZSBtdWx0aS1DRE4gY2FzZSBpcyB0 aGUgc2Nhcmllc3QgYXNwZWN0IG9mIGNvYWxlc2NpbmcgYW5kIHRoZQ0KPiAgICAgdmFyaW91cyBE TlMgdHJpY2tzIHdl4oCZdmUgYmVlbiBkb2luZyBpbiByZWNlbnQgeWVhcnMuwqAgVGhlIHNlcnZl ciBtYXkNCj4gICAgIG5vdCBiZSBtYWxpY2lvdXMsIG1heSBub3QgZXZlbiBiZSBtaXNjb25maWd1 cmVkIOKAkyBzaXRlIFggdXNlcyBETlMgdG8NCj4gICAgIGR5bmFtaWNhbGx5IHNoYXJlIGxvYWQg YmV0d2VlbiBDRE5zIEEgYW5kIEYuwqAgSWYgWCBkZWNpZGVzIHRvIHN0YXJ0DQo+ICAgICBtb3Zp bmcgbW9yZSBsb2FkIHRvIEEsIEYgY291bGQgaW4gYWxsIGdvb2QgZmFpdGggY29udGludWUgdG8g cm91dGUNCj4gICAgIGNsaWVudHMgdG8gaXRzZWxmIGJ5IHByb3ZpZGluZyBjYWNoZWQsIHNpZ25l ZCBETlMgcmVjb3Jkcy4NCj4gDQo+IA0KPiBZdXAuIEFuZCwgYXQgbGVhc3QgZm9yIGJyb3dzZXJz IHRoYXQgZm9sbG93IGEgUHJpb3JpdHkgb2YgQ29uc3RpdHVlbmN5IA0KPiBtb2RlbCwgaXQgc2Vl bXMgbW9yZSBpbXBvcnRhbnQgdG8gZW5zdXJlIHRoYXQgc2l0ZSBvcGVyYXRvcnMgd2lzaGVzIA0K PiBhcmUgcmVzcGVjdGVkIG92ZXIgdGhhdCBvZiB0aGUgQ0ROcyB0aGV5J3ZlIHVzZWQsIG9yIGZv ciB0aGVpciBiZWluZyBhIA0KPiBtb3JlIGV4cGxpY2l0IHNpZ25hbCBmcm9tIHRoZSB1c2VyIHRo YXQgaXQgdHJ1bHkgaW50ZW5kcyB0byBpZ25vcmUgdGhlIA0KPiBzaXRlIG9wZXJhdG9yLg0KPiDC oA0KPiANCj4gICAgIF9fX18NCj4gDQo+ICAgICBfX8KgX18NCj4gDQo+ICAgICBUaGUgaW5kdXN0 cnkgbm9ybSBpcyB0aGF0IGNoYW5naW5nIHRoZSBETlMgcmVjb3Jk4oCZcyBDTkFNRSB0byBhDQo+ ICAgICBkaWZmZXJlbnQgQ0ROIGlzIHRoZSBjdXQtb3ZlciwgcmVnYXJkbGVzcyBvZiB3aGV0aGVy IHRoZSBvdGhlciBDRE4NCj4gICAgIHJlbWFpbnMgY29uZmlndXJlZC7CoCBJdOKAmXMgZWZmZWN0 aXZlbHkgYWN0aW5nIGFzIGEg4oCcaG90IHN0YW5kYnku4oCdwqAgSWYNCj4gICAgIGl0IGhhZCB0 byBwcm92aWRlZCBiZXR0ZXIgcHJvb2Ygb2YgZnJlc2huZXNzLCB0aGF0IG1pZ2h0IGJlDQo+ICAg ICBzdWZmaWNpZW50LCBidXQgaG93IGZyZXNoIGlzIHN1ZmZpY2llbnRseSBmcmVzaD/CoCBBbmQg ZG9lcyBETlNTRUMNCj4gICAgIHByb3ZpZGUgdGhhdCBmcmVzaG5lc3MgZ3VhcmFudGVlPw0KPiAN Cj4gDQo+IFJpZ2h0LCB0aGVzZSBhcmUgcXVlc3Rpb25zIHRoYXQgbmVlZCB0byBiZSBhbnN3ZXJl ZCwgYW5kIG5vdCBqdXN0IHdpdGggDQo+IGFic3RyYWN0IHRoZW9yZXRpY2FsIG1pdGlnYXRpb25z IHRoYXQgZG9uJ3Qgb3IgY2FuJ3QgYmUgZGVwbG95ZWQuDQoNClNpZ25hdHVyZXMgaW4gRE5TU0VD IChpLmUuIFJSU0lHIHJlY29yZHMpIGhhdmUgdmFsaWRpdHkgcGVyaW9kIHdpdGggMS1zZWNvbmQg Z3JhbnVsYXJpdHkgc28gaW4gdGhlb3J5IGl0IGFsbG93cyBmaW5lLXR1bm5pbmcuIE9mIGNvdXJz ZSBzaG9ydGVyIHZhbGlkaXR5IG1lYW5zIG1vcmUgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zIHRv IHVwZGF0ZSBzaWduYXR1cmVzIGV0Yy4NCg0KVGFraW5nIGludG8gYWNjb3VudCB0aGF0IENsb3Vk ZmxhcmUgc2lnbnMgYWxsIHJlY29yc2Qgb24gdGhlIGZseSwgaXQgaXMgY2xlYXJseSBmZWFzaWJs ZSBmb3IgQ0ROIHRvIGdlbmVyYXRlIGZyZXNoIHNpZ25hdHVyZXMgb24gZXZlcnkgRE5TIHJlcXVl c3QuDQoNClBldHIgxaBwYcSNZWsgIEAgIENaLk5JQw0KDQoNCj4gICAgIEhvd2V2ZXIsIEYgY291 bGQgZG8gdGhpcyB0b2RheSB3aXRoIEFsdC1TdmMgYW5kIGhhdmUgdGhlIHNhbWUNCj4gICAgIGlt cGFjdC7CoCBTZWNvbmRhcnkgQ2VydGlmaWNhdGVzIHByb3ZpZGVzIGFub3RoZXIgd2F5IHRoaXMg bWlnaHQNCj4gICAgIGhhcHBlbi7CoCBTbyB0aGlzIHNoaXAgbWlnaHQgaGF2ZSBhbHJlYWR5IHNh aWxlZC4NCj4gDQo+IA0KPiBUaGUgc2hpcCBoYXMgb25seSBzYWlsZWQgZm9yIHRob3NlIGZvb2xp c2ggZW5vdWdoIHRvIHNoaXAgdGhvc2UgDQo+IGZlYXR1cmVzDQo+IDopIFRoYXQgaXMsIHRoZXNl IGFyZSByZWFsIHNlY3VyaXR5IGNvbmNlcm5zLCB0aGV5IGhhdmUgbm90IGJlZW4gDQo+IHNhdGlz ZmFjdG9yaWx5IGFkZHJlc3NlZCwgYW5kIHNlY3VyaXR5IGNvbnNjaW91cyBpbXBsZW1lbnRhdGlv bnMgaGF2ZSANCj4gaGVsZCBvZmYgaW1wbGVtZW50aW5nIHRoZXNlIGZlYXR1cmVzIGZvciBwcmVj aXNlbHkgdGhpcyByZWFzb24uIElmIA0KPiB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQg aGF2ZSBzaGlwcGVkLCB3aXRob3V0IHVuZGVyc3RhbmRpbmcgb3IgDQo+IGNvbnNpZGVyaW5nIHRo ZSBzZWN1cml0eSBoYXJtIHRoZXkncmUgZG9pbmcsIHRoYXQgZG9lc24ndCBzZWVtIGxpa2UgYSAN Cj4gZ29vZCBhcmd1bWVudCB0byBrZWVwIGJ1aWxkaW5nIG1vcmUgZmVhdHVyZXMgb24gdGhlIGJ1 Z2d5IHByZW1pc2UuDQo+IA0KPiBJZiB0aGV5IGJlbGlldmUgdGhleSBoYXZlIHN1ZmZpY2llbnRs eSBtaXRpZ2F0ZWQgdGhvc2UgdmVyeSByZWFsIGFuZCANCj4gcHJhY3RpY2FsIHNlY3VyaXR5IGNv bmNlcm5zLCB0aGV5IHdvdWxkIGhvcGVmdWxseSBiZSBzaGFyaW5nIHRob3NlIA0KPiBjb25jcmV0 ZSBzdHJhdGVnaWVzIGFuZCB0cmFkZW9mZnMsIHJhdGhlciB0aGFuIGEgU2VjdXJpdHkgDQo+IENv bnNpZGVyYXRpb25zIHRoYXQgYWNrbm93bGVkZ2VzIHRoZSBkcmFnb25zIHdpdGhvdXQgYWRlcXVh dGVseSANCj4gZGVzY3JpYmluZyBob3cgdG8gYXZvaWQgdGhlbSAob3IgaG93IG5vdCB0bykuDQoN Cg== From nobody Wed Jul 11 15:02: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 0499E130ED9 for ; Wed, 11 Jul 2018 15:02:29 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 tvLqV762hhgv for ; Wed, 11 Jul 2018 15:02:27 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F53130E73 for ; Wed, 11 Jul 2018 15:02:26 -0700 (PDT) Received: from 88-212-170-147.customer.gigaclear.net ([88.212.170.147]:64641 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fdNBl-0004wd-PS (Exim 4.72) for doh@ietf.org (return-path ); Wed, 11 Jul 2018 23:02:21 +0100 To: doh@ietf.org References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> From: Ray Bellis Message-ID: <97a765f4-fa30-e5d8-8755-cf7859296a84@bellis.me.uk> Date: Wed, 11 Jul 2018 23:02:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <20180711212427.GA9723@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:02:30 -0000 On 11/07/2018 22:24, Nico Williams wrote: >>> 1) is addressed by defining a new type(s) rather than using prefixes. > > While that is correct, and truly, it is trivial to implement, it is not > trivial to deploy: too many DNS hosting providers would have to update > UIs. How much critical DNS intrastructure would have to be upgraded to support something like ANAME ? Ray From nobody Wed Jul 11 15:26:03 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 DA7A712872C for ; Wed, 11 Jul 2018 15:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org 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 qfUmHE9Neg77 for ; Wed, 11 Jul 2018 15:25:52 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 ECCE3130DE1 for ; Wed, 11 Jul 2018 15:25:51 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id t14-v6so17222517uao.8 for ; Wed, 11 Jul 2018 15:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xw/jjrYq+qCbhfhCI8wuejqR6md3s7xQ7PHmneUYKWo=; b=dEeZ4/Z6cYdhqqr5vBOPHSN7LbJLnOQWTk2Pf5N8JeQbR98km1erh0AtndzZF4Exbq k7ThdK/QqOXk+koLnyYE3LxSGYIZn5sUSsbeo8J5oz1kP5xX5ymCOgFAFN2M5DQTyvsJ qMZ16flqwkXodYWoaZ9P31s8QpFBJ7DOCG4/s= 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=Xw/jjrYq+qCbhfhCI8wuejqR6md3s7xQ7PHmneUYKWo=; b=nXKmKpoJvniVniuLvNEHFUOrBkMi+TrKhSjCk/YhXmwwQHWc3KQtmmiFDv0udldcSb AR3rDoDtByUg6MvXF6Bm8sgAn38UZJ+oYZU8goQVIwinV7Ng3eXWOwC5Y7gzJ2BDZShL ARrG1soTRjCg+BhOK5Syt6hYI8CBx4YGmrRshShNaTes2op6VSxL4u4lqgzDTRQgMRtN Pp3odAwZ5shLPxd/ehN5vnz+1fCqoU+/Bj8NgfpPn7X45GV6XdnJ6RbWijzehhDWfC+y 7qYZ/a4d7TVbf4iinS9euR4FwZSA1Hh/QXnVwPPLbdkk/PQIT8iVJ+xpczTuH3E8gkmH SLlg== X-Gm-Message-State: AOUpUlGIfq7e7eZS1ZJ2FtpBGMJlElS6MGdh8PvMrkRb9uRG+d8LrhnQ 96Zw4IzmvNcFR/7Aw9aPwCDvkxoYUHIKAmcqNt+B2g== X-Google-Smtp-Source: AAOMgpeK4Z0Mh1j5Tda/qfL/lcnZqk8GyR/UQsbH94dECtaKOqgMe1f5d/ACGZTeqX9vIq+U+AqdJ2l0Q9vx5jfaQP4= X-Received: by 2002:ab0:4b17:: with SMTP id h23-v6mr360465uaf.84.1531347950636; Wed, 11 Jul 2018 15:25:50 -0700 (PDT) MIME-Version: 1.0 References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> From: Joseph Lorenzo Hall Date: Wed, 11 Jul 2018 18:25:38 -0400 Message-ID: To: Mark Nottingham Cc: marka@isc.org, doh@ietf.org, Adam Roach , driu@ietf.org, dnsop , HTTP Working Group , jabley@hopcount.ca Content-Type: multipart/alternative; boundary="000000000000a017e90570c0ba9f" Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:25:56 -0000 --000000000000a017e90570c0ba9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in, but will need to catch up on the convo... I'll do so. BTW, don't look at the Yelp/Foursquare reviews for the social venue... yike= s On Tue, Jul 10, 2018 at 9:32 PM Mark Nottingham wrote: > I didn't find those, but I found many others. > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > > > > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > > > > > >> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: > >> > >> > >> > >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > >>> > >>> On Jul 10, 2018, at 18:02, Adam Roach wrote: > >>> > >>>> In large part because DNS provides "a richer scheme that accommodate= s > address families and multiple addresses with priorities". > >>> > >>> *cups hand to ear* > >>> > >>> Was that the sound of a distant desire to specify use of SRV for HTTP= ? > >>> > >> > >> I recently did some digging on this topic, and can try to characterise > what the issues / objections are. > > > > I think there are three main objections. > > > > 1) Wildcards don=E2=80=99t work with prefixes. > > 2) Additional data isn=E2=80=99t always returned it may require multipl= e round > trips. > > 3) Additional data processing doesn=E2=80=99t support negative response= s. > > > > All of these issues are trivially easy to fix. It just require > willingness to implement. > > > > 1) is addressed by defining a new type(s) rather than using prefixes. > > 2) is addressed by getting recursive servers to fill in missing > additional data before returning. Named has code in review for this for > SRV as proof of concept. > > 3) is addressed by adding some signalling between the client and > recursive server to indicate if the additional section is complete or not= . > > > > > >> Would people be interested in a (hopefully brief) side meeting to > discuss and maybe come to a shared understanding of the problem space? > >> > >> Cheers, > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --000000000000a017e90570c0ba9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in, but will need to catch up on the convo...= I'll do so.

BTW, don't look at the Yelp/F= oursquare reviews for the social venue... yikes

On Tue, Jul 10, 2018 at 9:32 PM Mark No= ttingham <mnot@mnot.net> wrote:<= br>
I didn't find those, but I foun= d many others.

I'll start collecting. How about Tuesday, say 6:45-7:45pm?



> On 11 Jul 2018, at 11:30 am, Mark Andrews <marka@isc.org> wrote:
>
>
>
>> On 11 Jul 2018, at 11:22 am, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>
>>
>>> On 11 Jul 2018, at 3:55 am, Joe Abley <jabley@hopcount.ca> wrote:
>>>
>>> On Jul 10, 2018, at 18:02, Adam Roach <adam@nostrum.com> wrote:
>>>
>>>> In large part because DNS provides "a richer scheme t= hat accommodates address families and multiple addresses with priorities&qu= ot;.
>>>
>>> *cups hand to ear*
>>>
>>> Was that the sound of a distant desire to specify use of SRV f= or HTTP?
>>>
>>
>> I recently did some digging on this topic, and can try to characte= rise what the issues / objections are.
>
> I think there are three main objections.
>
> 1) Wildcards don=E2=80=99t work with prefixes.
> 2) Additional data isn=E2=80=99t always returned it may require multip= le round trips.
> 3) Additional data processing doesn=E2=80=99t support negative respons= es.
>
> All of these issues are trivially easy to fix.=C2=A0 It just require w= illingness to implement.
>
> 1) is addressed by defining a new type(s) rather than using prefixes.<= br> > 2) is addressed by getting recursive servers to fill in missing additi= onal data before returning.=C2=A0 Named has code in review for this for SRV= as proof of concept.
> 3) is addressed by adding some signalling between the client and recur= sive server to indicate if the additional section is complete or not.
>
>
>> Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space?
>>
>> Cheers,
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= INTERNET: marka@isc.org=

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

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


--
Jo= seph Lorenzo Hall
Chief Technologist, Center for Democracy & Technol= ogy [https://www.cdt.org<= /a>]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: <= a href=3D"https://josephhall.org/gpg-key" target=3D"_blank">https://josephh= all.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F8= 6 6987 40A9 A871

--000000000000a017e90570c0ba9f-- From nobody Wed Jul 11 15:51:57 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 6CB30130E5D; Wed, 11 Jul 2018 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 ff8MedgjyJ12; Wed, 11 Jul 2018 15:51:48 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 980461274D0; Wed, 11 Jul 2018 15:51:48 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 640033AB044; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4B821160043; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 32CE4160072; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GchlsJqYTP_c; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 522C1160043; Wed, 11 Jul 2018 22:51:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <20180711212427.GA9723@localhost> Date: Thu, 12 Jul 2018 08:51:43 +1000 Cc: Mark Nottingham , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:51:51 -0000 > On 12 Jul 2018, at 7:24 am, Nico Williams = wrote: >=20 >>> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >>>=20 >>>>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>>>>=20 >>>>> *cups hand to ear* >>>>>=20 >>>>> Was that the sound of a distant desire to specify use of SRV for >>>>> HTTP? >>>=20 >>> I think there are three main objections. >>>=20 >>> 1) Wildcards don=E2=80=99t work with prefixes. >>> 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. >>> 3) Additional data processing doesn=E2=80=99t support negative = responses. >>>=20 >>> All of these issues are trivially easy to fix. It just require = willingness to implement. >>>=20 >>> 1) is addressed by defining a new type(s) rather than using = prefixes. >=20 > While that is correct, and truly, it is trivial to implement, it is = not > trivial to deploy: too many DNS hosting providers would have to update > UIs. Garbage. There really isn=E2=80=99t. People keep saying something = can=E2=80=99t be done because there are too many X. X get replaced. X get updated. As for = DNS hosting providers that support a given type, we create a site and report what software by version and date and what DNS hosting providers support the type native or unknown formats. We also don=E2=80=99t have to achieve 100%. People can move to DNS = hosters that do support the type or host their own DNS. Every DNS hoster that = provides slave/secondary services already supports they type as UNKNOWN has been = out there so long. > Let me add my voice in favor of new RR types by which to replace SRV > RRs. URI is one of them, for the sorts of things we do in Kerberos = for > KDC discovery, but no really appropriate for resolving HTTP = authorities. >=20 >>> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >=20 > That would be very nice indeed. Unbound will need that too. >=20 >>> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >=20 > Well, OK, but as with (2) that requires recursive resolver critical > mass. Not necessarily a big deal, though it will take enough time = that > many apps will need to support falling back to doing multiple queries > one by one. They can do the queries in parallel, that 2 RTTs. > Nico > --=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 11 17:48:42 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 108C2130E97; Wed, 11 Jul 2018 17:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=2.851] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 jS1a9811JnNQ; Wed, 11 Jul 2018 17:48:39 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3B5130DE3; Wed, 11 Jul 2018 17:48:39 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 0BCE03000271F; Wed, 11 Jul 2018 17:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=XUvykv0i+MVCLEuiTnSgoj3pEdc=; b=aNxOtNF46AC b9z/WAA977x+krL+m+XxaE5gYb0QW6dNSEXgotPxZcYydOohemLaPKWjaQUYZh+v hTyF2tCe4LJj22ygmT6SJiLmI1bvz9UQ+EgaSt9Vpg85wde7WDML5b+29/wWy50W gwUpIarzhfS8mUQo1FmFgD746Soek8SA= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 475E63000271E; Wed, 11 Jul 2018 17:48:38 -0700 (PDT) Date: Wed, 11 Jul 2018 19:48:36 -0500 From: Nico Williams To: Mark Andrews Cc: Mark Nottingham , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Message-ID: <20180712004835.GB9723@localhost> References: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:48:42 -0000 On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: > >>> 1) is addressed by defining a new type(s) rather than using prefixe= s. > >=20 > > While that is correct, and truly, it is trivial to implement, it is n= ot > > trivial to deploy: too many DNS hosting providers would have to updat= e > > UIs. >=20 > Garbage. There really isn=E2=80=99t. People keep saying something can= =E2=80=99t be done > because there are too many X. X get replaced. X get updated. As for = DNS > hosting providers that support a given type, we create a site and repor= t > what software by version and date and what DNS hosting providers suppor= t > the type native or unknown formats. I didn't mean to say not to go this way. On the contrary, we should. Just that this is an issue. > We also don=E2=80=99t have to achieve 100%. People can move to DNS hos= ters that > do support the type or host their own DNS. Every DNS hoster that provi= des > slave/secondary services already supports they type as UNKNOWN has been= out > there so long. Ah yeah, that's true -- not a great UI, but it works. > >>> 2) is addressed by getting recursive servers to fill in missing add= itional data before returning. Named has code in review for this for SRV= as proof of concept. > >=20 > > That would be very nice indeed. Unbound will need that too. > >=20 > >>> 3) is addressed by adding some signalling between the client and re= cursive server to indicate if the additional section is complete or not. > >=20 > > Well, OK, but as with (2) that requires recursive resolver critical > > mass. Not necessarily a big deal, though it will take enough time th= at > > many apps will need to support falling back to doing multiple queries > > one by one. >=20 > They can do the queries in parallel, that 2 RTTs. Yes, that's a big deal. From nobody Wed Jul 11 18:30: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 221DE130DC7; Wed, 11 Jul 2018 18:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 q1UkgWiTfb9x; Wed, 11 Jul 2018 18:30:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 2EF9512F1A2; Wed, 11 Jul 2018 18:30:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id EC7313AB03F; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D5F39160076; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C0567160075; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vorCVgjZ3GOH; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 71EEA160043; Thu, 12 Jul 2018 01:30:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <20180712004835.GB9723@localhost> Date: Thu, 12 Jul 2018 11:30:16 +1000 Cc: Mark Nottingham , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> <20180712004835.GB9723@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [DNSOP] SRV and HTTP X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 01:30:25 -0000 > On 12 Jul 2018, at 10:48 am, Nico Williams = wrote: >=20 > On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: >>>>> 1) is addressed by defining a new type(s) rather than using = prefixes. >>>=20 >>> While that is correct, and truly, it is trivial to implement, it is = not >>> trivial to deploy: too many DNS hosting providers would have to = update >>> UIs. >>=20 >> Garbage. There really isn=E2=80=99t. People keep saying something = can=E2=80=99t be done >> because there are too many X. X get replaced. X get updated. As = for DNS >> hosting providers that support a given type, we create a site and = report >> what software by version and date and what DNS hosting providers = support >> the type native or unknown formats. >=20 > I didn't mean to say not to go this way. On the contrary, we should. > Just that this is an issue. >=20 >> We also don=E2=80=99t have to achieve 100%. People can move to DNS = hosters that >> do support the type or host their own DNS. Every DNS hoster that = provides >> slave/secondary services already supports they type as UNKNOWN has = been out >> there so long. >=20 > Ah yeah, that's true -- not a great UI, but it works. >=20 >>>>> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >>>=20 >>> That would be very nice indeed. Unbound will need that too. >>>=20 >>>>> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >>>=20 >>> Well, OK, but as with (2) that requires recursive resolver critical >>> mass. Not necessarily a big deal, though it will take enough time = that >>> many apps will need to support falling back to doing multiple = queries >>> one by one. >>=20 >> They can do the queries in parallel, that 2 RTTs. >=20 > Yes, that's a big deal. It=E2=80=99s a self correcting problem though. Recursive nameservers do = get upgraded. If we could have got people on board back when I first submitted https://datatracker.ietf.org/doc/draft-andrews-http-srv/ everyone would = be using it and I suspect recursive servers would have been optimised to fetch = the additional data before returning. There is nothing in the RFC=E2=80=99s that says = you can=E2=80=99t stall the response to fetch additional data. This isn=E2=80=99t hard. It just = requires people to stop arguing and =E2=80=9CJust Do It=E2=80=9D. Also writing documentation that says =E2=80=9Cif the query has these = properties, fetch missing additional data=E2=80=9D will help. We could have done 5 or 6 transitions since 2000 on both the DNS and = HTTP sides. While there are long tails most of the world upgrades within 3 years. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jul 16 07:29:56 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 2EF60130EE8; Mon, 16 Jul 2018 07:29:43 -0700 (PDT) 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=mnot.net header.b=f4JYfvGw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uFJqdxZh 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 VFNSlrcAvWit; Mon, 16 Jul 2018 07:29:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07318131066; Mon, 16 Jul 2018 07:29:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 690A321C1B; Mon, 16 Jul 2018 10:29:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 16 Jul 2018 10:29:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=NUYyW+RlAusd7DdGyNwOXaRoVY1Km v9zD4VDHkOqB1c=; b=f4JYfvGwLBnEAFDpK1c4ly4zaKNBB+JexwsaRc8mV8g9E COUN9YCacdVWfgJiZB2c81XytAIHoMiJmH6U96rk91IDSVEZwl/YbSYeoMpJC5yb pVy6O6pj/iprCkdiOdgEUuvHERLa5ATEk9lyo5r4rYh47NWqBDGW69pE11aSnew+ 4kCykZb21nsGD0IJCxUVF9IMVnOZp8/XUrMj5LcokQ5MFBX/wEretNLmfdHWKKLH qx6/+rZ47bAbuEFWHSld+eLyETqhrbINUG3F+etTRo+gcvmf2A9GqaDgeBO9HkxA INA7tBsvG/8zAZ1he++GUUHE0hG0LComwY9JUj5OQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NUYyW+ RlAusd7DdGyNwOXaRoVY1Kmv9zD4VDHkOqB1c=; b=uFJqdxZhn+x26v/myz4Dib vcVUCUJ+xXJRboUN7jQfKVdqS5i7mVesdWjgKYAEEM4pRTTd+9+1ACeCrJudpwuk fZBQ8ORynGLnrokmu6IuCxWs4pJ/D26agyX8Dre3QwRzlSM1Ki+gEcX+QonmsbXm srd2D25JW/yYY4PoQ3AcpQlOhbBTCaYhWt/oq56bng8MciB7pIXLSviyUFwqX1v4 b4CO96krSapxRO1xiSVr6HJvt0unPkqSp+1XJtVJpyRDWtQtv4bR/socm+bJJnGY Cj/RfZzbkH9NYyL1vWF6APAf24KaYcrACVSgY/q+t0XOKxafcJHZP/NOuorLHwYA == X-ME-Proxy: X-ME-Sender: Received: from dhcp-9c22.meeting.ietf.org (dhcp-9c22.meeting.ietf.org [31.133.156.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 1D76A10261; Mon, 16 Jul 2018 10:29:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Nottingham In-Reply-To: <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> Date: Mon, 16 Jul 2018 10:29:38 -0400 Cc: DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 14:29:44 -0000 Room change - we're now in Square Dorchester (the bigger room). Cheers, > On 10 Jul 2018, at 10:25 pm, Mark Nottingham wrote: >=20 > Sure, with the understanding that we'll probably start a few minutes = after that, given the session end at 16:20 (I'm chairing then, it = usually takes a little while to get out). >=20 > I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. >=20 > Cheers, >=20 >=20 >> On 11 Jul 2018, at 11:52 am, Dave Lawrence wrote: >>=20 >> Dave Lawrence writes: >>> Mark Nottingham writes: >>>> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >>>=20 >>> Last session ends at 6:20 and social starts at 7, not sure how late >>> the last bus (if any?) will be leaving the hotel. >>=20 >> Nevermind, walking distance to social, under 1km. Maybe still though >> shifting it a little earlier, like 18:30. >>=20 >> _______________________________________________ >> DRIU mailing list >> DRIU@ietf.org >> https://www.ietf.org/mailman/listinfo/driu >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 17 16:43: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 6570A130E2E; Tue, 17 Jul 2018 16:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_PASS=-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 BalmXVON2zoL; Tue, 17 Jul 2018 16:43:18 -0700 (PDT) Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C0C128BAC; Tue, 17 Jul 2018 16:43:17 -0700 (PDT) Received: from [2001:67c:370:128:72e7:8f03:3ad9:63f1] by time-travellers.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ffZei-00016W-TR; Tue, 17 Jul 2018 23:45:21 +0000 Cc: DoH WG , driu@ietf.org, dnsop@ietf.org, HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> From: Shane Kerr Message-ID: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> Date: Tue, 17 Jul 2018 19:43:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> Content-Type: multipart/mixed; boundary="------------FC0954ACC0D8D1366B9E07A1" Content-Language: en-US Archived-At: Subject: Re: [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:43:19 -0000 This is a multi-part message in MIME format. --------------FC0954ACC0D8D1366B9E07A1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, I took some random notes at the meeting. Apologies for any errors or misstatements. Cheers, -- Shane --------------FC0954ACC0D8D1366B9E07A1 Content-Type: text/markdown; name="srv-vs-http.md" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="srv-vs-http.md" 2018-07-17 Bar BoF with about 35 people. Mark Nottingham leads the discussion. Why not SRV for HTTP? Some work before: * draft-andrews-srv-http * New URI scheme also died. Use cases for SRV: 1. Load balancing 2. Service on alternate port Mark Andrews: Gets around CNAME at apex issue in DNS. Ray Bellis: Missing wildcard support, HTTPS only, more stuff. Mark Nottingham: From the web side, we have constraints. Have to be backwards compatible and cannot have a flag day. On the web it is critical to maintain security boundary based on the name. Martin Thompson: When we are talking about an unauthenticated method (DNSSEC notwithstanding), we are uncomfortable although that is changing. Ray Bellis: No reason not to have a record that matches this requirement. Mark Nottingham: Assumption was "just use SRV", but if we mean "SRV done right" then it is a different discussion. Cullen Jennings: What about getting it in a way that you can use it in every operating system? Mark Andrews: That is dead easy. If your resolver code does not support unknown RTYPEs then you are not compliant. Olafur Gudmondsson: One pain point is provisioning systems, the other is various libraries. Steward Cheshire: Within a C API it is easy. If Javascript it is more difficult. Mark Nottingham: I didn't see many web people concerned about how hard it is to set up a new record type. Erik Nygren: The performance hit of looking it up does not justify the work. But there is a new record type called ALTSVC is like an extensible SRV that covers additional use cases. It negotiates what port to use, and some other things which are actively being looked at (such as encrypted SNI). Mark Nottingham: This allows different name treated as the same origin. Not a working group document - being considered. Tale: About performance... that has been a major obstacle. Vendors want to get answers as quickly as possible. You could do server-side processing, but this doesn't help across boundaries and also, server-sides RR more difficult to get out. Patrick McManus: Protocol version negotiation in the DNS is attractive in many ways. But blocking is a real thing. ALTSVC fixes this by allowing connection to be made after or while connected to the primary service. Ben Schwartz: two modes, totally asynchronous or blocking. Tale: Asynchronous does not really address the same problem as SRV, since you have to connect to the primary origin which may be what you want to address. Ask Hansen: Server operators can get much better control, and clients implemented correctly can also get better behavior. ..... Paul Hoffman: What would you like now? We could do stuff. Mark Nottingham: Now that we have use cases, what are the appropriate paths now. Ray Bellis: SRV is for service type to target mapping. CNAME is supposed to be for hostname mapping, and that means every service. SRV is service-specific. Erik Nyren: Things that have transitional properties are very important. Always be a need for A and AAAA records at least for some decades. Mark Andrews: I have always expected legacy clients. [ discussion about deprecating technologies ] Kazuho Oku: Key distributed via DNS is a separate record, and also cannot handle the multiple CDN record since key cannot be shared. Ray Bellis: ANAME shifts work to resolvers; a really bad idea. Ben Schwartz: There are certain cases in TCP where you can risk a SYN/ACK, one RTT. Mark Nottingham: Interaction between web and DNS folks. I am not expecting a lot, but we should talk together and work better and learn the pain points and so on. Martin Thompson: Unfiltered messages coming through. We actually get TTL's from platforms (except Windows). This is a transition problem and we need to look at this in terms of transition problems. Browsers have an influence but they are not the only HTTPS clients. Mark Andrews: SPF working group did not give themselves enough time to switch from TXT to SPF. It requires libraries to be upgraded, along with browsers, and whatever else needs to be upgraded. This takes 3 or 4 years. Mark Nottingham: I am hearing that we don't know how to get from now to the end state. We need a roadmap. We need to meet security and performance while transitioning. Ben Schwartz: Some people seem to think transition is infinite. I think that it is large but probably finite. Are are there alternative means to reach our goals that cost less? Martin Thompson: I was not proposing that it was intractable transition. The apex problem is a pain, and externalizes the problem in various awful ways, and it would be better if we had a different system. HTTP is everywhere, embedded in all sorts of things. If the goal is to exterminate the current resolution... I don't see how every single person could be motivated to move. I can see some of them - certainly a browser - but there is a lot of HTTP out there. Patrick McManus: Service versus host in the industry is not a very important distinction. Load balancing solved in other ways. Apex issue may be an issue. Ray Bellis: Add an experimental type to BIND and just try it out. Kazuho Oku: I would prefer defining it in a way that provides consistency to convert to the same set of A or CNAME records. Ask Hansen: More like EDNS client subnet than MX records. Small percentage of servers that need it. Mark Nottingham: No specific actions. Where to discuss? [ everyone wants to discuss somewhere ] Action: Adam Roach will set up a mailing list. --------------FC0954ACC0D8D1366B9E07A1-- From nobody Tue Jul 17 16:44: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 5925F128BAC; Tue, 17 Jul 2018 16:44:19 -0700 (PDT) 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 WUCoO0nimX5e; Tue, 17 Jul 2018 16:44:17 -0700 (PDT) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F06B130E4F; Tue, 17 Jul 2018 16:44:17 -0700 (PDT) Received: from dhcp-99b3.meeting.ietf.org (dhcp-99b3.meeting.ietf.org [31.133.153.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 80FDD2420FDE; Tue, 17 Jul 2018 23:44:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> Date: Wed, 18 Jul 2018 00:44:12 +0100 Cc: dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <48D7628C-8984-4210-80EE-EF8D41BCFE01@rfc1035.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> To: Shane Kerr X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [Driu] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:44:20 -0000 > On 18 Jul 2018, at 00:43, Shane Kerr = wrote: >=20 > I took some random notes at the meeting. Apologies for any errors or = misstatements. Many thanks Shane!= From nobody Tue Jul 17 18:55:07 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 34DB0130F04; Tue, 17 Jul 2018 18:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, 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 pO3C5kYIPYR9; Tue, 17 Jul 2018 18:54:56 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 8DC27130EDD; Tue, 17 Jul 2018 18:54:56 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id o11-v6so1112917wmh.2; Tue, 17 Jul 2018 18:54:56 -0700 (PDT) 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=swIbP99lbMlE18rsde009tjZxF39Sd4AXNd5LtW8okA=; b=Je3IyU3AqGap3pAkYJmNcLVCyeOFoPx4E1neopqd+PBb3MlW232Y/UKmw9u0XfuOcu HOoMz81Db5BdrS1DUmWV8dYc8C7JEUYU8pBlFNAH9uI2KcYFIXDyanRWJR3Xpd0JnIOx vUosM0zNTadmenIpcWcxyec0Lckjfn8stDIhsEcC2x+xvSg8AqWG1EXkdbmRj5/+FWBu qsD0QklmvYXYdgibeLgGXHItGOP3HXDJw15mCBvgFnVy89E7rDWiRx2jFf/74F5Q2Vsr FBYF9vXQmVISu6jLOd7rfFkPO9IK+Jc0IpWKiQepZwzSXqa825MUfs0qx5+amGqM/PHn 5yOQ== 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=swIbP99lbMlE18rsde009tjZxF39Sd4AXNd5LtW8okA=; b=GFz1kyb2/GekaUSwLsXJTyrOSsPOFlF9FzcQ2GSZYUgh4QXv3tMp4winyHvGQ9i6/j GlxvaFmFHa8ETzLJuaxP96mOP6FbBNlQXZkYEpO6Wc7JNgLuiV8hQ+B4qzWVwFGU7W7H dvDAxaaXdeHG21Xl/0cPh9yGSnUGpBYdtwXB29seOZIn5mxoRQOA2EqSr1NGKQrDM7Xq kqW/FUIepZwAbBIyllATldqPvVJJYvdVpF7kLpY78JHTUyzKJPUxsHf80eoK8YBguDvE WHIo8ZRvsdU7tzy5yUTicv21qxsizgK8uO7c4m/DkrI5fwqr9rRj2oB7u9/Sm6OJm9yL 0l9Q== X-Gm-Message-State: AOUpUlF79vQmhEggw/Vf9l3Zg6pjjMkfU/OwnvpwPHtqhXFabYoG9GB4 p9zF2L4IIHdXgj9nO/E/bnQkpvqbzI95hFH4A+R0ig== X-Google-Smtp-Source: AAOMgpeFdxEV6o6Z3VBcMH+Ysml56QN8qgQQrlSUHhTik4cnJYKKeLHNk2tk2RH94ckgn4OOUEGhKPZlY0j2kCxHmq0= X-Received: by 2002:a1c:b584:: with SMTP id e126-v6mr296664wmf.136.1531878895181; Tue, 17 Jul 2018 18:54:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 18:54:54 -0700 (PDT) In-Reply-To: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> From: Tim Wicinski Date: Tue, 17 Jul 2018 21:54:54 -0400 Message-ID: To: Shane Kerr Cc: dnsop , DoH WG , driu@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000062e16005713c5998" Archived-At: Subject: Re: [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 01:54:59 -0000 --00000000000062e16005713c5998 Content-Type: text/plain; charset="UTF-8" These are great notes Shane. We're going to talk about APEX records in the DNSOP session in the morning. Tim On Tue, Jul 17, 2018 at 7:43 PM, Shane Kerr wrote: > All, > > I took some random notes at the meeting. Apologies for any errors or > misstatements. > > Cheers, > > -- > Shane > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --00000000000062e16005713c5998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These are great notes Shane.=C2=A0

We&#= 39;re going to talk about APEX records in the DNSOP session in the morning.= =C2=A0

Tim


On Tue, Jul 17, 2018 at 7= :43 PM, Shane Kerr <shane@time-travellers.org> wrote= :
All,

I took some random notes at the meeting. Apologies for any errors or missta= tements.

Cheers,

--
Shane

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


--00000000000062e16005713c5998-- From nobody Wed Jul 18 05:31: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 4D960131160; Wed, 18 Jul 2018 05:31:21 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 1YZSytCytc5q; Wed, 18 Jul 2018 05:31:19 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAD913115F; Wed, 18 Jul 2018 05:31:19 -0700 (PDT) Received: from bh-rezlocal-wmc1-vlan104.gw.mcgill.ca ([192.197.121.70]:57736 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fflbt-0004ye-E0 (Exim 4.72) (return-path ); Wed, 18 Jul 2018 13:31:13 +0100 To: Shane Kerr Cc: dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> From: Ray Bellis Message-ID: Date: Wed, 18 Jul 2018 08:31:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 12:31:22 -0000 On 17/07/2018 19:43, Shane Kerr wrote: > Ray Bellis: ANAME shifts work to resolvers; a really bad idea. correction here - what I actually said was that in the transitional phase ANAME shifts work to * authoritatives *. Ray From nobody Wed Jul 18 07:03:00 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 18FF9130E31 for ; Wed, 18 Jul 2018 07:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 a0sp4mibcD8n for ; Wed, 18 Jul 2018 07:02:53 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 33C32126F72 for ; Wed, 18 Jul 2018 07:02:53 -0700 (PDT) Received: from [2001:67c:1232:144:b95e:e6e:30c8:a361] (port=56585) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ffn2V-0003uH-HQ for doh@ietf.org; Wed, 18 Jul 2018 15:02:51 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_5B8F93FF-EFE7-4ABD-8C1F-C421D4CF1AA0" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: References: <153192232867.2882.433616342941784102.idtracker@ietfa.amsl.com> To: doh@ietf.org Date: Wed, 18 Jul 2018 10:02:44 -0400 X-Mailer: Apple Mail (2.3445.9.1) X-BlackCat-Spam-Score: 14 Archived-At: Subject: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 14:02:57 -0000 --Apple-Mail=_5B8F93FF-EFE7-4ABD-8C1F-C421D4CF1AA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All,=20 We=E2=80=99ve just submitted a very short draft outlining a privacy = profile for DoH called DoHPE. It is very basic at the moment but it would be great to get some = feedback on the idea here and to see if the WG sees this as something = that should go through this group or head somewhere else. Since the = guidelines are purely HTTP related, this does feel like the right = audience to review the document at least in the first instance.=20 Sara.=20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-dickinson-doh-dohpe-00.txt > Date: 18 July 2018 at 09:58:48 GMT-4 > To: "Sara Dickinson" , "Willem Toorop" = >=20 >=20 > A new version of I-D, draft-dickinson-doh-dohpe-00.txt > has been successfully submitted by Sara Dickinson and posted to the > IETF repository. >=20 > Name: draft-dickinson-doh-dohpe > Revision: 00 > Title: DoHPE: DoH with Privacy Enhancements > Document date: 2018-07-18 > Group: Individual Submission > Pages: 8 > URL: = https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt > Status: = https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/ > Htmlized: = https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe >=20 >=20 > Abstract: > This document describes DoHPE (DoH with Privacy Enhancements) - a > privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] > clients. The profile provides guidelines on the composition of DoH > messages, designed to minimize disclosure of identifying = information. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 --Apple-Mail=_5B8F93FF-EFE7-4ABD-8C1F-C421D4CF1AA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = All, 

We=E2=80=99= ve just submitted a very short draft outlining a privacy profile for DoH = called DoHPE.

It= is very basic at the moment but it would be great to get some feedback = on the idea here and to see if the WG sees this as something that should = go through this group or head somewhere else. Since the guidelines are = purely HTTP related, this does feel like the right audience to review = the document at least in the first instance. 

Sara. 


Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-dickinson-doh-dohpe-00.txt
Date: = 18 July 2018 at 09:58:48 = GMT-4
To: = "Sara Dickinson" <sara@sinodun.com>, = "Willem Toorop" <willem@nlnetlabs.nl>


A new version = of I-D, draft-dickinson-doh-dohpe-00.txt
has been = successfully submitted by Sara Dickinson and posted to the
IETF repository.

Name: = draft-dickinson-doh-dohpe
Revision: 00
Title:= = DoHPE: DoH with Privacy Enhancements
Document = date: = 2018-07-18
Group: Individual Submission
Pages:= = 8
URL: =            https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-= 00.txt
Status: =         https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/=
Htmlized:       https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe=


Abstract:
=   This document describes DoHPE (DoH with Privacy = Enhancements) - a
  privacy and anonymity = profile for DoH [I-D.ietf-doh-dns-over-https]
=   clients.  The profile provides guidelines on the = composition of DoH
  messages, designed to = minimize disclosure of identifying information.




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.

The IETF Secretariat


= --Apple-Mail=_5B8F93FF-EFE7-4ABD-8C1F-C421D4CF1AA0-- From nobody Wed Jul 18 13:22: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 12B03131006 for ; Wed, 18 Jul 2018 13:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 j0ydzcx7lQpk for ; Wed, 18 Jul 2018 13:22:52 -0700 (PDT) Received: from mail-it0-x244.google.com (mail-it0-x244.google.com [IPv6:2607:f8b0:4001:c0b::244]) (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 50355130EC8 for ; Wed, 18 Jul 2018 13:22:52 -0700 (PDT) Received: by mail-it0-x244.google.com with SMTP id s7-v6so5976241itb.4 for ; Wed, 18 Jul 2018 13:22:52 -0700 (PDT) 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=Zc1fRTgrs/cdzATKXmo853fX2+zL1CHmG1rC8VyrOu0=; b=X5/Bh+TZMiXKRfBoufMg8WUXIpiQqjuL7KuEUWh7f26rThZ/UUk4Htu2BQ7guxJ0Es DaHmgZtQqVjGZBxF6aiGEhJK9k3Chi15K/FzbXVoZ9br5v/0UNwrTW/hfGJ6gv9wR8k8 QB+8wuaRVl33xLgnnIu4QKZz4EoZWCUAblt2z3rpJmFodEbpHsLwJXyKu2ky6h3chLDn aod2YOsHEmmLW6SpL2waqF+Dd5Q9azfYwlSEtG6MEsVSUDo1CK7vrs00iiOiPpcFBXKy dt/T9wu594yEStOFDqTXYHBy90E4DR1yXUFTtgbHQulPSgnXx6rnijBZqat+gC7M98Wq DB6Q== 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=Zc1fRTgrs/cdzATKXmo853fX2+zL1CHmG1rC8VyrOu0=; b=VZg9HjGw9Ui7RV7LsMCOrY7rQeC5U6L9wYiUcqu4gHYgnWbzzuOKLUh6Ye24VrPjeA SuQ4zkYbfS15qZxEvkfmhCQKPHEHz5YL+3oEu7jD6RXQ0kBHY64Fd4Pj09yNwIn8vWTw RqkB2pX6CcXR4g86St1CrmZhlb+RAT9kZNenRmw3IOINe7Kg2Vi1ezsaANOW4C2HV2yo PsHjGLX1zzvnChNrFAmSXBD5wXAkcPDMtG8ScsGiyGtgLoQiaPo5WVWcxXXhbZqVdMZf xz4F7eeVR7yECZM8VXxvVzz7Ra3mqv95RSoZYw+VL3ozDUG04DYCS7RnQuoVYhTuq8jD Kn1g== X-Gm-Message-State: AOUpUlFn+dMrPV7QM0xyGdeaJa/NGgfzjXE7z71X9v7C5enXq0OVyeqZ koSHCBIoXVJLuctd8hegIw6fr+9H0pWeM2zGPT0MaVQb X-Google-Smtp-Source: AAOMgpcwTzKHtK9QxEf7/4qU6Up+vcoR21x4a9ldUuY6S28pPRlFG9E+/rTBW0fot93HyrjUp6sfiN/qTEmuz8vpuZ0= X-Received: by 2002:a24:d30d:: with SMTP id n13-v6mr2856069itg.87.1531945370985; Wed, 18 Jul 2018 13:22:50 -0700 (PDT) MIME-Version: 1.0 References: <153192232867.2882.433616342941784102.idtracker@ietfa.amsl.com> In-Reply-To: From: Ben Schwartz Date: Wed, 18 Jul 2018 16:22:35 -0400 Message-ID: To: Sara Dickinson Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b3445405714bd3ec" Archived-At: Subject: Re: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 20:22:56 -0000 --000000000000b3445405714bd3ec Content-Type: multipart/alternative; boundary="000000000000a7c94205714bd306" --000000000000a7c94205714bd306 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this draft could use review from readers familiar with HTTP. I hope that people with knowledge of HTTP will help us to understand whether this draft's recommendations would result in a significant increase in user privacy. For the draft's authors, I have a question: does this draft's "privacy threat model" include a DOH server that uses active measures to differentiate clients? Or is it scoped only to passive discrimination between different client implementations? As for other issues, I think the draft might need to consider header order. I also couldn't find an easy list of mandatory headers in RFC 7540, so that list might be worth repeating. On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson wrote: > Hi All, > > We=E2=80=99ve just submitted a very short draft outlining a privacy profi= le for > DoH called DoHPE. > > It is very basic at the moment but it would be great to get some feedback > on the idea here and to see if the WG sees this as something that should = go > through this group or head somewhere else. Since the guidelines are purel= y > HTTP related, this does feel like the right audience to review the docume= nt > at least in the first instance. > > Sara. > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-dickinson-doh-dohpe-00.txt= * > *Date: *18 July 2018 at 09:58:48 GMT-4 > *To: *"Sara Dickinson" , "Willem Toorop" < > willem@nlnetlabs.nl> > > > A new version of I-D, draft-dickinson-doh-dohpe-00.txt > has been successfully submitted by Sara Dickinson and posted to the > IETF repository. > > Name: draft-dickinson-doh-dohpe > Revision: 00 > Title: DoHPE: DoH with Privacy Enhancements > Document date: 2018-07-18 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt > Status: > https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/ > Htmlized: https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe > > > Abstract: > This document describes DoHPE (DoH with Privacy Enhancements) - a > privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] > clients. The profile provides guidelines on the composition of DoH > messages, designed to minimize disclosure of identifying information. > > > > > 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. > > The IETF Secretariat > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000a7c94205714bd306 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this draft could use review from readers familiar = with HTTP.=C2=A0 I hope that people with knowledge of HTTP will help us to = understand whether this draft's recommendations would result in a signi= ficant increase in user privacy.

For the draft's= authors, I have a question: does this draft's "privacy threat mod= el" include a DOH server that uses active measures to differentiate cl= ients?=C2=A0 Or is it scoped only to passive discrimination between differe= nt client implementations?

As for other issues, I = think the draft might need to consider header order.=C2=A0 I also couldn= 9;t find an easy list of mandatory headers in RFC 7540, so that list might = be worth repeating.

On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson <sara@sinodun.com> wrote:
Hi All,=C2=A0

We=E2=80=99ve just submitted a very sh= ort draft outlining a privacy profile for DoH called DoHPE.

<= /div>
It is very basic at the moment but it would be great to get some = feedback on the idea here and to see if the WG sees this as something that = should go through this group or head somewhere else. Since the guidelines a= re purely HTTP related, this does feel like the right audience to review th= e document at least in the first instance.=C2=A0

S= ara.=C2=A0


Begi= n forwarded message:

Subject: New Version Notification for draft-dickins= on-doh-dohpe-00.txt
18 July 2018 at 09:58:48 GMT-4
To: "Sa= ra Dickinson" <sara@sinodun.com>, "Willem Toorop" <willem@nlnetlabs.nl>


A new version of I-D, draft-dickinson-doh-dohpe-= 00.txt
has been successfully submitted by Sara Dickinson and posted to t= he
IETF repository.

Name: draft-= dickinson-doh-dohpe
Revision: 00
Title: DoHPE: DoH with Privacy Enhancements
Document date:<= span class=3D"m_-5487741669272203371Apple-tab-span" style=3D"white-space:pr= e-wrap"> 2018-07-18
Group: Indiv= idual Submission
Pages: 8
URL: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe= -00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/=
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools= .ietf.org/html/draft-dickinson-doh-dohpe-00
Htmlized: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc= /html/draft-dickinson-doh-dohpe


Abstract:
=C2=A0=C2=A0Th= is document describes DoHPE (DoH with Privacy Enhancements) - a
=C2=A0= =C2=A0privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] =C2=A0=C2=A0clients.=C2=A0 The profile provides guidelines on the compos= ition of DoH
=C2=A0=C2=A0messages, designed to minimize disclosure of i= dentifying information.




Please note that it may take a c= ouple of minutes from the time of submission
until the htmlized version = and diff are available at tools.ietf.org.

The IETF Secretariat


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000a7c94205714bd306-- --000000000000b3445405714bd3ec 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBd2ITn9JMALRm9x2v7KEcT l4PR+jP+gDpCaOuC8Qb8UzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA3MTgyMDIyNTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAx8h/NSSiVOdLpt4NxHZkfNKHTulrZ5WOip18oJh7 ASykYrHlwNpmWCHr3e8qCXN8BVBGjegBlnRP6dcRymlFFqH98bUMDAV+aCRS2t3PTgYH75OuRAqm fI/RBH3WrgCebf3NTNV6fdOY42Psq0VIrKPVmpXke9t+j/wdQwxl98cdPNViERgPtWV/eEDi7gbZ w0JhEf+9NHDJK5ef8Eeq3+mwT9LCwwCjY1je1VLnGQ5JOItp+3chfD9AOgxqEd69aRNzf4L4XaFG N0U0RLqG8MOyPGMad+2VJPjzezu4keuU8PoYVcAkKG/S83yYJ++M8dJZNtD8CboMVi/8azC8gg== --000000000000b3445405714bd3ec-- From nobody Thu Jul 19 07:52:46 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 25A991310E1 for ; Thu, 19 Jul 2018 07:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 O14kalbO1xIV for ; Thu, 19 Jul 2018 07:52:29 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2: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 8B4DC130EBF for ; Thu, 19 Jul 2018 07:52:29 -0700 (PDT) Received: from [2001:67c:1232:144:d42:eb7c:2d4a:e5b3] (port=51574) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fgAI3-0002Ma-S8; Thu, 19 Jul 2018 15:52:28 +0100 From: Sara Dickinson Message-Id: <81486098-95E9-49BE-9C04-F0EBEC2A2085@sinodun.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2442AD86-833C-4B75-B865-98D49BE7F114"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 19 Jul 2018 10:52:20 -0400 In-Reply-To: Cc: DoH WG To: Ben Schwartz References: <153192232867.2882.433616342941784102.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) X-BlackCat-Spam-Score: -16 Archived-At: Subject: Re: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 14:52:44 -0000 --Apple-Mail=_2442AD86-833C-4B75-B865-98D49BE7F114 Content-Type: multipart/alternative; boundary="Apple-Mail=_9147EC0D-5E17-406F-B9BA-C39866CCE96A" --Apple-Mail=_9147EC0D-5E17-406F-B9BA-C39866CCE96A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Jul 2018, at 16:22, Ben Schwartz wrote: >=20 > I think this draft could use review from readers familiar with HTTP. = I hope that people with knowledge of HTTP will help us to understand = whether this draft's recommendations would result in a significant = increase in user privacy. Completely agree. >=20 > For the draft's authors, I have a question: does this draft's "privacy = threat model" include a DOH server that uses active measures to = differentiate clients? Or is it scoped only to passive discrimination = between different client implementations? Both of these. >=20 > As for other issues, I think the draft might need to consider header = order. Yes - a couple of other folks have mentioned that too. > I also couldn't find an easy list of mandatory headers in RFC 7540, = so that list might be worth repeating. There doesn=E2=80=99t seem to be a simple example in any draft I found = so the current text is a bit of a cop-out. I was wondering if it would = make more sense to have the list in draft-ietf-httpbis-bcp56bis-06 as a = general clarification and then this document could reference that? Or Stephane suggested pointing to RFC 7230 (plus a bit of RFC 7231) = instead. But actually I now think example messages would be the most = explicit way to show what DoHPE messages should look like. Sara. >=20 > On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson > wrote: > Hi All, >=20 > We=E2=80=99ve just submitted a very short draft outlining a privacy = profile for DoH called DoHPE. >=20 > It is very basic at the moment but it would be great to get some = feedback on the idea here and to see if the WG sees this as something = that should go through this group or head somewhere else. Since the = guidelines are purely HTTP related, this does feel like the right = audience to review the document at least in the first instance. >=20 > Sara. >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-dickinson-doh-dohpe-00.txt >> Date: 18 July 2018 at 09:58:48 GMT-4 >> To: "Sara Dickinson" >, = "Willem Toorop" > >>=20 >>=20 >> A new version of I-D, draft-dickinson-doh-dohpe-00.txt >> has been successfully submitted by Sara Dickinson and posted to the >> IETF repository. >>=20 >> Name: draft-dickinson-doh-dohpe >> Revision: 00 >> Title: DoHPE: DoH with Privacy Enhancements >> Document date: 2018-07-18 >> Group: Individual Submission >> Pages: 8 >> URL: = https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt = >> Status: = https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/ = >> Htmlized: = https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 = >> Htmlized: = https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe = >>=20 >>=20 >> Abstract: >> This document describes DoHPE (DoH with Privacy Enhancements) - a >> privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] >> clients. The profile provides guidelines on the composition of DoH >> messages, designed to minimize disclosure of identifying = information. >>=20 >>=20 >>=20 >>=20 >> 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 = . >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh = --Apple-Mail=_9147EC0D-5E17-406F-B9BA-C39866CCE96A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Jul 2018, at 16:22, Ben Schwartz <bemasc@google.com> = wrote:

I think this draft could use review from readers = familiar with HTTP.  I hope that people with knowledge of HTTP will = help us to understand whether this draft's recommendations would result = in a significant increase in user privacy.

Completely agree. 


For the draft's authors, I have a question: does this draft's = "privacy threat model" include a DOH server that uses active measures to = differentiate clients?  Or is it scoped only to passive = discrimination between different client = implementations?

Both of these. 


As for other issues, I = think the draft might need to consider header = order.

Yes = - a couple of other folks have mentioned that too.

  I also couldn't find an = easy list of mandatory headers in RFC 7540, so that list might be worth = repeating.

There doesn=E2=80=99t seem to be a simple example = in any draft I found so the current text is a bit of a cop-out. I was = wondering if it would make more sense to have the list = in draft-ietf-httpbis-bcp56bis-06 as a general clarification and = then this document could reference that?

Or Stephane suggested pointing to RFC 7230 (plus a = bit of RFC 7231) instead. But actually I now think example messages = would be the most explicit way to show what DoHPE messages should look = like. 

Sara. 



On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson <sara@sinodun.com> = wrote:
Hi = All, 

We=E2=80=99= ve just submitted a very short draft outlining a privacy profile for DoH = called DoHPE.

It= is very basic at the moment but it would be great to get some feedback = on the idea here and to see if the WG sees this as something that should = go through this group or head somewhere else. Since the guidelines are = purely HTTP related, this does feel like the right audience to review = the document at least in the first instance. 

Sara. 


Begin forwarded = message:

From: internet-drafts@ietf.org
Subject: New Version = Notification for draft-dickinson-doh-dohpe-00.txt
Date: 18 July 2018 at 09:58:48 GMT-4
To: "Sara Dickinson" <sara@sinodun.com>, "Willem Toorop" <willem@nlnetlabs.nl>


A new version = of I-D, draft-dickinson-doh-dohpe-00.txt
has been = successfully submitted by Sara Dickinson and posted to the
IETF repository.

Name: draft-dickinson-doh-dohpe
Revision: 00
Title: DoHPE: DoH with Privacy = Enhancements
Document date: 2018-07-18
Group: Individual Submission
Pages: 8
URL: =            https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-= 00.txt
Status: =         https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/=
Htmlized:       https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe=


Abstract:
=   This document describes DoHPE (DoH with Privacy = Enhancements) - a
  privacy and anonymity = profile for DoH [I-D.ietf-doh-dns-over-https]
=   clients.  The profile provides guidelines on the = composition of DoH
  messages, designed to = minimize disclosure of identifying information.




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.

The IETF = Secretariat


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

= --Apple-Mail=_9147EC0D-5E17-406F-B9BA-C39866CCE96A-- --Apple-Mail=_2442AD86-833C-4B75-B865-98D49BE7F114 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEzBAEBCAAdFiEEARfKBmwUrVFTxWi2+uOzGhY+Sp0FAltQpaQACgkQ+uOzGhY+ Sp0z9wf/d92qfPveie1ecsthOIPTZVFN8msMp/Byr4aV7GoJDN+YvChnEU8yB2G/ ocUJ5bO9LfrQamacyvNKsRuCmiEFxa3Ppv9CkKXZ1G5cThOpGIBYXup9Q22QisoQ uaREPr/5SM6bCASOH/j0jyRNnP/7rx+KSoTB1SANdxEaP9gvWB0kAKgcbY57scB6 CrB53LVHqsor0ll353+aIOKnQNsyfna1BHVNXDSi6pFvS5VSLWPJR57XyvWDWPUx VvcMOoVibtAHzA9JBoTIUucHGd1ZH7adnaL8jRR9Z9b8gqaCioF6OVp/SkBmxNLI gohHUKk+HXdvvzxXfuuJjGL65DSbCQ== =RfKE -----END PGP SIGNATURE----- --Apple-Mail=_2442AD86-833C-4B75-B865-98D49BE7F114-- From nobody Thu Jul 19 08:23:56 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 A3EEC130E1B for ; Thu, 19 Jul 2018 08:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZnRAfT6oGe1Q for ; Thu, 19 Jul 2018 08:23:47 -0700 (PDT) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::244]) (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 C1ADE130D7A for ; Thu, 19 Jul 2018 08:23:46 -0700 (PDT) Received: by mail-oi0-x244.google.com with SMTP id w126-v6so15636018oie.7 for ; Thu, 19 Jul 2018 08:23:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WyS8SoPxQR+U9JsZwHVlURb2GoM9iOsOmuzvRvYwx4g=; b=VVCND1v9UhyLOD3Mb12YyDYXubYc6ly12hX4UUdg3W8oiQRsoaWezc1kTvctqylrPi Eabs+gUlW/esSsiyxnFPkgbPJZZtFEyzKxWe6BKgyjcNAETi8M3Mu1Wq5IoiWg1mLy+4 +lFIFmJ6QtB7emWLOmlyRJnoA3rsXSs5b1jQpu1Okaumian4fYAI95d/GB3uGh2VyeHE CWYx4bT3+R8KzgZ6ONZ/+dWPzoZYhfMDtIt4yCGIpWMFZ1OnOMKUvWR5QYKMoOwZ83Fi OC7eBAWwGGW+Y9GMWMjGwR5uGsKKPjAdf4NKPact39eI3sZPY0rse2HxRzx/aytGG1EU Qmvg== 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:content-transfer-encoding; bh=WyS8SoPxQR+U9JsZwHVlURb2GoM9iOsOmuzvRvYwx4g=; b=F47RaCFqlRJmZ32okm/6CjDx6Qj+Vr8SaNtK+7/VjfFiIHAoN9VZFutUEj7WskS3Ys ZdVYTyzwClKo/cSzFRdoGDYtKGDeQGwJVEl4VLZxxHbW3f0R845sYtauA9jw2f8bV+d5 C9jT/N1rQT9mqpvJwFkuRDATcBlbrE4VwBuUKefeuujvMkwZEbjhpReQCes1+OsB1eNb 8C2BmtXBJIZlsBPWFas5jPr/j7+gnG47GZ+IT1Cc7g9pCcl/RrFdbcVGz0VGooDXjnNr 99mVc4tHLtEOLTklU1pbZHrl8L6DH2F5Y4Nfpd7K2acOTQKIolGFsFvbAG2ixvXe6eRn 6Ugg== X-Gm-Message-State: AOUpUlFXCMQYWcPVO28ukxYckgaIHpG5nbMN6YckDRJuhzG7U6IFWPzK uTjv1jES5dcb6OLC/gAe/cKdfizX2Qx/m05peTBWHDB1GLU= X-Google-Smtp-Source: AAOMgpfJlAEDC6Ia0NP/khmdlW1EbG+B0mnkWqlLkf6dI3pfPYP7JPfHeb/mxWiC/t+Gu5Q5SQRdkqFaS0dN6wHqLkk= X-Received: by 2002:aca:5841:: with SMTP id m62-v6mr12035693oib.346.1532013825933; Thu, 19 Jul 2018 08:23:45 -0700 (PDT) MIME-Version: 1.0 References: <153192232867.2882.433616342941784102.idtracker@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Thu, 19 Jul 2018 11:23:34 -0400 Message-ID: To: bemasc=40google.com@dmarc.ietf.org Cc: sara@sinodun.com, DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:23:51 -0000 A few thoughts. The recommendations seem pretty sensible, but I remain a little uncertain about the utility of the draft. 3.2 recommends exclusive use of a connection for DoH. That could run counter to the goals because it would make traffic analysis easier. Using the same connection for heterogeneous requests makes each contribute to obscuring the others without relying on padding. It's not clear from this recommendation whether this also recommends connection reuse. More on that below. 3.1 recommends the use of a single service. That results in the operator of that service getting access to a lot of information about the activity of users. Using different servers might be a better result for privacy, making it harder for providers to use correlations between requests to extract information. The recommendation to suppress User-Agent appears to assume that there is a valuable de-anonymization signal in that header field. I don't believe that to be true. If there are relatively few User-Agent strings exposed and the amount of information in that string is minimal, this should not be a significant problem, meaning that the effective anonymity set is large. The same consideration applies to the choice of GET or POST. The recommendation against the use of cookies seems obvious, and it might be true that cookies are the most hated feature of HTTP, but I don't think that it achieves the goal. Linking requests is pretty powerful. And as long as the client is able to control linkability, cookies can be useful. For the record, I don't think that this is a bad recommendation, but it could be better grounded in concrete rationale. That is, there are many ways in which a client might link one request to another and the client should be aware of those mechanisms. That gives the client a better ability to control this. In addition to cookies, you should consider the use and reuse of persistent connections, Alternative Services (which might be cached), TLS session tickets, TFO cookies, and any other information that might be used to link requests. Overall, the set of recommendations here is pretty lightweight. I'm not sure that this is really that useful a document to publish. The application of this to a very specific usage of DNS is OK, but maybe this is something advice is something that would be valuable more generally. This information is very well understood in the HTTP community, but I concede that it's a little distressing that we don't have a single document that captures all of this. I note that the HTTP working group is revising its core specs. Maybe this represents an opportunity to improve the security considerations of those documents. On Wed, Jul 18, 2018 at 4:23 PM Ben Schwartz wrote: > > I think this draft could use review from readers familiar with HTTP. I h= ope that people with knowledge of HTTP will help us to understand whether t= his draft's recommendations would result in a significant increase in user = privacy. > > For the draft's authors, I have a question: does this draft's "privacy th= reat model" include a DOH server that uses active measures to differentiate= clients? Or is it scoped only to passive discrimination between different= client implementations? > > As for other issues, I think the draft might need to consider header orde= r. I also couldn't find an easy list of mandatory headers in RFC 7540, so = that list might be worth repeating. > > On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson wrote: >> >> Hi All, >> >> We=E2=80=99ve just submitted a very short draft outlining a privacy prof= ile for DoH called DoHPE. >> >> It is very basic at the moment but it would be great to get some feedbac= k on the idea here and to see if the WG sees this as something that should = go through this group or head somewhere else. Since the guidelines are pure= ly HTTP related, this does feel like the right audience to review the docum= ent at least in the first instance. >> >> Sara. >> >> >> Begin forwarded message: >> >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-dickinson-doh-dohpe-00.txt >> Date: 18 July 2018 at 09:58:48 GMT-4 >> To: "Sara Dickinson" , "Willem Toorop" >> >> >> A new version of I-D, draft-dickinson-doh-dohpe-00.txt >> has been successfully submitted by Sara Dickinson and posted to the >> IETF repository. >> >> Name: draft-dickinson-doh-dohpe >> Revision: 00 >> Title: DoHPE: DoH with Privacy Enhancements >> Document date: 2018-07-18 >> Group: Individual Submission >> Pages: 8 >> URL: https://www.ietf.org/internet-drafts/draft-dickinson-doh= -dohpe-00.txt >> Status: https://datatracker.ietf.org/doc/draft-dickinson-doh-doh= pe/ >> Htmlized: https://tools..ietf.org/html/draft-dickinson-doh-dohpe-0= 0 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-dickinson-do= h-dohpe >> >> >> Abstract: >> This document describes DoHPE (DoH with Privacy Enhancements) - a >> privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] >> clients. The profile provides guidelines on the composition of DoH >> messages, designed to minimize disclosure of identifying information. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submis= sion >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> 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 From nobody Thu Jul 19 08:39: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 908B8130ED9 for ; Thu, 19 Jul 2018 08:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 eqRPGuPdKToN for ; Thu, 19 Jul 2018 08:39:17 -0700 (PDT) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 C56C5130EAB for ; Thu, 19 Jul 2018 08:39:16 -0700 (PDT) Received: by mail-io0-x244.google.com with SMTP id o22-v6so6370565ioh.6 for ; Thu, 19 Jul 2018 08:39:16 -0700 (PDT) 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=CYXSHeFnOZLUX/xbDTSR7N5iFtmyb1rODLGeJXquVRE=; b=q5JeZ3uWSeslyWxou9/VxxcuqPuWyTpPb0ZeOM+WnhtCvyMmJn7MPBCcdZXXq0wo5M e3kp9a6Cl9oMpoDZz60GQOzZP7d+JIzjp5TV4xhRLVd79yQIkgpxxCpa21pXBSggZS+t 1r9IGSy7kCbgP0jCTkKUdNjeOBYb7CnMl+3XukTyCnHvo4BuLWhFOaB1B7Vi02CAPd5m 3adtvdWpCRZauPe2p1IFrW0puXVBYwYPQMh/SUsyTj1EZM2fy9MPd0FcEW2XEVlqktc8 y5Vox2QY+10ehvAMMPKWqxBJeT1HOf64hXWwfxuk350vjhdsRgs6PJjTvtj/Z5fGFyGZ 9dew== 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=CYXSHeFnOZLUX/xbDTSR7N5iFtmyb1rODLGeJXquVRE=; b=WscpHEJls6X7i6ZmxkMwnyyDURndQQVNMG9yYcQOLK1Bo/Zex2mMH3RssWttSySgnS 69h5edd74Q32/idJqiK7McLn88RvwT0dlNLoM1+PZe/Dl+6p0oWR82i1fn0Ev5YZgR/j PjRiZd8s2TbAS8shVuAE/c18qe03jG+KK5kR2nkdM5pFOrHgOgdaJM4JV7Xlja8HFfMv 7sALbjxOhFrLmEzdHZNo3cPrPbwMsEPN8flgaWXFRfuDQ1CTEbl6m5hjM6TVPDmze23p aehTI5OIIPmdcRI8Z5YPujXwcYiSD4O+oMmjyrwmPIk64B/iH8bB2ONZC0oSsw9UcjgR SGDQ== X-Gm-Message-State: AOUpUlHSjpouSUqMkOt6yE4nYa3qlldfmNRHasBsTbLKlamci/ynIsxo xteJUS9favOsAZBPer+HCWP04iKP7qFR2AwssExhPTwUsdo= X-Google-Smtp-Source: AA+uWPxvtntwI5Spcb1YMDJG5CHq9IWSnYHoeaXQmmzk//+41amJkOotH1GadgcvkDP29fbFjhBCKjvc+bgh3+6syQ0= X-Received: by 2002:a5e:8b4c:: with SMTP id z12-v6mr8508601iom.230.1532014755504; Thu, 19 Jul 2018 08:39:15 -0700 (PDT) MIME-Version: 1.0 References: <153192232867.2882.433616342941784102.idtracker@ietfa.amsl.com> <81486098-95E9-49BE-9C04-F0EBEC2A2085@sinodun.com> In-Reply-To: <81486098-95E9-49BE-9C04-F0EBEC2A2085@sinodun.com> From: Ben Schwartz Date: Thu, 19 Jul 2018 11:39:03 -0400 Message-ID: To: Sara Dickinson Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000571ab605715bfbff" Archived-At: Subject: Re: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 15:39:33 -0000 --000000000000571ab605715bfbff Content-Type: multipart/alternative; boundary="0000000000004ba97905715bfbf8" --0000000000004ba97905715bfbf8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 19, 2018 at 10:52 AM Sara Dickinson wrote: > > > On 18 Jul 2018, at 16:22, Ben Schwartz wrote: > > I think this draft could use review from readers familiar with HTTP. I > hope that people with knowledge of HTTP will help us to understand whethe= r > this draft's recommendations would result in a significant increase in us= er > privacy. > > > Completely agree. > > > For the draft's authors, I have a question: does this draft's "privacy > threat model" include a DOH server that uses active measures to > differentiate clients? Or is it scoped only to passive discrimination > between different client implementations? > > > Both of these. > OK. In that case, I think the draft would need to cover all the client's error handling, redirect following, and retry logic, i.e. any behavior the server could observe by generating targeted or malformed responses. This sounds challenging. This is also true for the underlying DNS implementation. Even without HTTP or TLS, I suspect that by similar methods (using malformed responses or exercising various unusual features), a recursive resolver could identify the stub resolver software with high precision. As Martin points out, the HTTP aspect of this is fairly widely applicable, outside of DOH. I think the same is probably true of the DNS side. Thus, one possibility would be to address those aspects separately. > As for other issues, I think the draft might need to consider header orde= r. > > > Yes - a couple of other folks have mentioned that too. > > I also couldn't find an easy list of mandatory headers in RFC 7540, so > that list might be worth repeating. > > > There doesn=E2=80=99t seem to be a simple example in any draft I found so= the > current text is a bit of a cop-out. I was wondering if it would make more > sense to have the list in draft-ietf-httpbis-bcp56bis-06 as a general > clarification and then this document could reference that? > > Or Stephane suggested pointing to RFC 7230 (plus a bit of RFC 7231) > instead. But actually I now think example messages would be the most > explicit way to show what DoHPE messages should look like. > > Sara. > > > > On Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson wrote: > >> Hi All, >> >> We=E2=80=99ve just submitted a very short draft outlining a privacy prof= ile for >> DoH called DoHPE. >> >> It is very basic at the moment but it would be great to get some feedbac= k >> on the idea here and to see if the WG sees this as something that should= go >> through this group or head somewhere else. Since the guidelines are pure= ly >> HTTP related, this does feel like the right audience to review the docum= ent >> at least in the first instance. >> >> Sara. >> >> >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-dickinson-doh-dohpe-00.txt* >> *Date: *18 July 2018 at 09:58:48 GMT-4 >> *To: *"Sara Dickinson" , "Willem Toorop" < >> willem@nlnetlabs.nl> >> >> >> A new version of I-D, draft-dickinson-doh-dohpe-00.txt >> has been successfully submitted by Sara Dickinson and posted to the >> IETF repository. >> >> Name: draft-dickinson-doh-dohpe >> Revision: 00 >> Title: DoHPE: DoH with Privacy Enhancements >> Document date: 2018-07-18 >> Group: Individual Submission >> Pages: 8 >> URL: >> https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/ >> Htmlized: https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-dickinson-doh-dohpe >> >> >> Abstract: >> This document describes DoHPE (DoH with Privacy Enhancements) - a >> privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] >> clients. The profile provides guidelines on the composition of DoH >> messages, designed to minimize disclosure of identifying information. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> > > --0000000000004ba97905715bfbf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu= , Jul 19, 2018 at 10:52 AM Sara Dickinson <sara@sinodun.com> wrote:


On 18 Jul 2018, at 16:22, Ben Schwart= z <bemasc@google.= com> wrote:

I think this draft could use review from r= eaders familiar with HTTP.=C2=A0 I hope that people with knowledge of HTTP = will help us to understand whether this draft's recommendations would r= esult in a significant increase in user privacy.

Completely agree.=C2=A0


For the draft's authors= , I have a question: does this draft's "privacy threat model"= include a DOH server that uses active measures to differentiate clients?= =C2=A0 Or is it scoped only to passive discrimination between different cli= ent implementations?

Both= of these.=C2=A0

OK.=C2= =A0 In that case, I think the draft would need to cover all the client'= s error handling, redirect following, and retry logic, i.e. any behavior th= e server could observe by generating targeted or malformed responses.=C2=A0= This sounds challenging.

This is also true for th= e underlying DNS implementation.=C2=A0 Even without HTTP or TLS, I suspect = that by similar methods (using malformed responses or exercising various un= usual features), a recursive resolver could identify the stub resolver soft= ware with high precision.

As Martin points out, th= e HTTP aspect of this is fairly widely applicable, outside of DOH.=C2=A0 I = think the same is probably true of the DNS side.=C2=A0 Thus, one possibilit= y would be to address those aspects separately.
<= div>
As for other issue= s, I think the draft might need to consider header order.
=

Yes - a couple of other folks have mention= ed that too.

= =C2=A0 I also couldn't find an easy list of mandatory headers in RFC 75= 40, so that list might be worth repeating.

There doesn=E2=80=99t seem to be a simple example in any = draft I found so the current text is a bit of a cop-out. I was wondering if= it would make more sense to have the list in=C2=A0draft-ietf-httpbis-bcp56= bis-06 as a general clarification and then this document could reference th= at?

Or Stephane suggested pointing to RFC 7230 (pl= us a bit of RFC 7231) instead. But actually I now think example messages wo= uld be the most explicit way to show what DoHPE messages should look like.= =C2=A0

Sara.=C2=A0



On = Wed, Jul 18, 2018 at 10:03 AM Sara Dickinson <sara@sinodun.com> wrote:
Hi All,=C2=A0

We=E2=80=99ve just submitte= d a very short draft outlining a privacy profile for DoH called DoHPE.

It is very basic at the moment but it would be great t= o get some feedback on the idea here and to see if the WG sees this as some= thing that should go through this group or head somewhere else. Since the g= uidelines are purely HTTP related, this does feel like the right audience t= o review the document at least in the first instance.=C2=A0

<= /div>
Sara.=C2=A0


Begin forwarded message:

Subject: New Version Notification for = draft-dickinson-doh-dohpe-00.txt
Date: 18 July 2018 at 09:58:48 GMT-4
=
To: "Sara Dick= inson" <sara@= sinodun.com>, "Willem Toorop" <willem@nlnetlabs.nl>


A new version of I-D, draft-dickinson-doh-dohpe-00.txt<= br>has been successfully submitted by Sara Dickinson and posted to the
I= ETF repository.

Name: draft-dickinson-doh-dohpe
Revision: 00
Title: DoHPE: DoH with Privacy En= hancements
Document date: 2018-07-= 18
Group: Individual Submission
Pages: 8
URL: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-dickinson-doh-dohpe-00.txt<= br>Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0h= ttps://datatracker.ietf.org/doc/draft-dickinson-doh-dohpe/
Htmlized:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.org/htm= l/draft-dickinson-doh-dohpe-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0https://datatracker.ietf.org/doc/html/draft-dic= kinson-doh-dohpe


Abstract:
=C2=A0=C2=A0This document des= cribes DoHPE (DoH with Privacy Enhancements) - a
=C2=A0=C2=A0privacy an= d anonymity profile for DoH [I-D.ietf-doh-dns-over-https]
=C2=A0=C2=A0c= lients.=C2=A0 The profile provides guidelines on the composition of DoH
= =C2=A0=C2=A0messages, designed to minimize disclosure of identifying infor= mation.




Please note that it may take a couple of minutes= from the time of submission
until the htmlized version and diff are ava= ilable at tools.ietf.o= rg.

The IETF Secretariat

<= br>
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--0000000000004ba97905715bfbf8-- --000000000000571ab605715bfbff 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCtexY2r8g/rz/Czp7BahbV X6UPs7J36D+H9AUSPGqCBDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA3MTkxNTM5MTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAJ71jtwOFNzTL2mFc6j2olJwnMGowqhR5Q/fvZ5M2 6MChIdhpVHFP3bvGvXaMAAXzY4kiP9xMWYA592lpfmwNmuVfTVDCc2vrJQcMM90ErqWiEtWTuUji ZrekCZ30W/HAWT+LSlMZT+gojeiIjC8j91fao9RTbxOnYu9kb1TYKXWPSTB5eWYA+SxHBYAOkm5+ OJwBoBzennUSvIrT0wnsPyTU8HdPMexM4ep2TWhI2hN0yywAqBhzlbCndkpW4XkJvq2YRnpt7v4M CiAXQdZG7KLm0uwfCzFwaSapcUVXzd2xpOuT7IWcVslgykQ7LaC2mXl4b4Oj1K6GU6T7rvtoew== --000000000000571ab605715bfbff-- From nobody Thu Jul 19 15:58:55 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 EA030130ED1 for ; Thu, 19 Jul 2018 15:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham 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 Do9JRUwRy0fe for ; Thu, 19 Jul 2018 15:58:38 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 4A33F130FF8 for ; Thu, 19 Jul 2018 15:58:36 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id w16-v6so12210759ita.0 for ; Thu, 19 Jul 2018 15:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=UHlKAw3vOi+5FJthJevhrY9F+P2ko+EOvZaJLAE46Wc=; b=QgKuFQ1OMo79oiU1dWoRAiTWBC4MLWxCgYEGJ8G9kY1EV1JeH58V8JEAs6dSHMeGtJ CwYd9WBRv/Uc3ynsO700DKduYMNonfO78klYTC9SeXYq5hOz/iwTtN5TRDlUoKtz6aua 009KnR221x+J6QP3leQXVMO0EQY/76m+2gO2NS54bALo+9rF3Ag7r5oZ2g4f8xsS/T2f LclWWKSNKniIfa/yTVt5WsiZ0fe/FJTBebFmL1Nd87q0tuoLaUm6MRk2E1Y4RaRoVunS 6L/yKF2kU3lXmyXvo8dwbqLXlr0nvSf71Q3nNImTO3TXMlku38Vd5hg1bsXf0etDxbov xLZg== 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=UHlKAw3vOi+5FJthJevhrY9F+P2ko+EOvZaJLAE46Wc=; b=c5fmyJAOMXUKGdliQ/RUS+gozqjS9dr+AjNU9YvDMcwae5Urkz6qVyHSmm1IaYG5yR wlBH08PaGmxBZZCK5KDbZWyunOwXgY/eXiprmjqiHhAzfu5cdK7IMqbu3zMe+1GvjfU5 u98nsB3MryoQ0CgqpoNLXyWCH2RgdhdRzFURwiCjcuasirWmRFKuBL89PuXZ5yz6DlIh SV7qP3YT4ceHTaSuEaGhXXTrz/AWsXSSVtgc3tG/OdTn7i0B0rjGv7igABimFdqFsaS6 gl7N07gccWrARgfIoJ4i8k2ZOIWXeLm1PRqJYqt1dgz3KfdVKg6PxpI01i6CjqQZXEuU xUqw== X-Gm-Message-State: AOUpUlEynHdP9pEgTbMQETD9vfVtpcsn3mIEenuECwlPP/JKQTZB9ABX NReAx6/1SjkrUX8TWDF258yjiWWJ6jYI2jeE6jv/TOjikcM= X-Google-Smtp-Source: AAOMgpeqcfJEJKPn1Nad26z9SyOK1WfNwOc+M6zwLgh6QMIRju1DGfMD/Gjhdo5Neeyv8hI85ce+fejOMgdHyMAXyVM= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr10941820jad.38.1532041115303; Thu, 19 Jul 2018 15:58:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 15:57:54 -0700 (PDT) From: Ted Lemon Date: Thu, 19 Jul 2018 18:57:54 -0400 Message-ID: To: DoH WG Content-Type: multipart/alternative; boundary="000000000000759b600571621ec4" Archived-At: Subject: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:58:53 -0000 --000000000000759b600571621ec4 Content-Type: text/plain; charset="UTF-8" I think that the document needs to speak more explicitly about locally-served zones. Right now it mentions that there can be issues, but doesn't make any clear or unequivocal recommendation. I think that by default you can't use DoH for locally served zones, but if you wanted to offer that service, there would have to be a way to tell that you were on the network where a particular DoH server served a particular set of locally served zones. I think that's not something for the base spec, but I mention it because I think this issue needs to be seriously considered and the base spec needs to call it out specifically. --000000000000759b600571621ec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think that the document needs to speak more explicitly a= bout locally-served zones.=C2=A0 =C2=A0Right now it mentions that there can= be issues, but doesn't make any clear or unequivocal recommendation.= =C2=A0 =C2=A0I think that by default you can't use DoH for locally serv= ed zones, but if you wanted to offer that service, there would have to be a= way to tell that you were on the network where a particular DoH server ser= ved a particular set of locally served zones.=C2=A0 =C2=A0I think that'= s not something for the base spec, but I mention it because I think this is= sue needs to be seriously considered and the base spec needs to call it out= specifically.
--000000000000759b600571621ec4-- From nobody Thu Jul 19 16:03:45 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 378A5130E03 for ; Thu, 19 Jul 2018 16:03:44 -0700 (PDT) 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=jO7KqDDn; dkim=pass (1024-bit key) header.d=yitter.info header.b=fufRXMD1 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 g84Edrs3_wgD for ; Thu, 19 Jul 2018 16:03:42 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58493130DD2 for ; Thu, 19 Jul 2018 16:03:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 77674BEBEB for ; Thu, 19 Jul 2018 23:03:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1532041421; bh=EZuC19gvQ/x7+KGAc6ZQ6qhj9GxpAjjBqyiST76MB94=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jO7KqDDnphYae6GdcofvlMGH8qVrgdHrK/GhCC/9t+dArw/JSxexIHsbzKCz6W6SW 3zsov/7CiBWIDGxxgh9daE3vcnBN4/j6JCGbSh3krb7BjmHZYFMH9FLlQ9imWcTdES 2yNVAO2R6VQbMzFTIyglQdi/EHptHkShucpAqlZM= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y85UApytQ7uF for ; Thu, 19 Jul 2018 23:03:40 +0000 (UTC) Date: Thu, 19 Jul 2018 19:03:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1532041420; bh=EZuC19gvQ/x7+KGAc6ZQ6qhj9GxpAjjBqyiST76MB94=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fufRXMD1oSL9A1ZUv3KOWicxWcr208AdkSB1STTTH1Fkkcf90L7DMVUqSvUUWQ7ge 4QvdPiGSzm4O+N2P7OPcr1Ph5dSI16qkpFhw44DUocsU8DE3qofkzKzxN63Onoecvl 7eLQmxcWl8kkKh6Vu1oNiU3Xlx4BRoyz/7Q7LS08= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180719230338.GF21643@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:03:44 -0000 On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: > clear or unequivocal recommendation.   I think that by default you can't use > DoH for locally served zones Could you say why? Thanks, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Jul 19 16:08: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 599FD130DD2 for ; Thu, 19 Jul 2018 16:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham 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 pJf-1W_Y315g for ; Thu, 19 Jul 2018 16:08:17 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 D3EB6130E03 for ; Thu, 19 Jul 2018 16:08:16 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id w11-v6so2959873iob.2 for ; Thu, 19 Jul 2018 16:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3ZvcedpXxg2u2gTK4sjIYZfqba6JUTrSUA7hTZ0GlgQ=; b=rTfRTlnHj0Tr6eDaZnUSalpNgGAWg/mxRF/NgsUfl9+XZbHqtWczBcM6RZDE7RnZN7 cMBDZt7XznghOFZq8MEogRmuvy2jxdvhotxbI+bcB84zhuYqv9YWtJx3iK77t9mD0VaL cr2y2eYzQjq268xUnH5XWBn5Mp8QsJ9p422kHlUuyQJzXX9qJF5Iq8yQuvY9GhVSWgtR dWCTapwrk2OZ/Dilgmw4PUbIIButBMubxZ2C4kpeTUYagtCfWQs6PgQXgJQoQBH7tcL8 e3EDJvcxLs+lh+lV+yIe1aiXAV01k/FZR3UP/MLnra/FmHCR02yB80vgjm5mT8dp4o9e Sglw== 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=3ZvcedpXxg2u2gTK4sjIYZfqba6JUTrSUA7hTZ0GlgQ=; b=qnr7Z5wSYMLlpqMYIR7JRfMVPkSqe3Sy8tauKVurDIjK0sXD6aWHtkrzoZ+L8pyG/7 2lZ1DnvjEUTyRQPfSVqL2val12aSsluPfTewcA9MtsFJWjtmkfWFxCxKcSWbDeBxjXD0 PVcPXltbUbdjLIsh6aKibWFkZ7DCS/jenSsoRCNn/RTanfv80iuAQjB6+99yZAttTrF3 3A/a4xyPoZAtwFOZS8MqtYrc/bhLz4hxMsBZPIvE0lsIrOl5+UY8WnSy8bwJNKb47Gly N4P/JPrXionyDELWSgJE16ns5GoIOkWWQRz8xys/wUlDMnVsHQqhyL7ceMiNMie5dzNx N1YQ== X-Gm-Message-State: AOUpUlH370JVPt4YwZZRiPM5HxW+SCXxbpV52qDjvoUfyPFLZxcTsa8+ A2vh5VZbKknehDdhp+gIwzwPBkQDP/udZz9ZUafMBYRxVMY= X-Google-Smtp-Source: AAOMgpf3zOuPCD9jLeewqV2P8C3WxYUj94hY7Re7X4rXmpMo3rad9Fyl+hYdiRaeIgjve0sLMcwBKiQmrIFwfVYIRwQ= X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr10730439ioe.32.1532041696069; Thu, 19 Jul 2018 16:08:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 16:07:35 -0700 (PDT) In-Reply-To: <20180719230338.GF21643@mx4.yitter.info> References: <20180719230338.GF21643@mx4.yitter.info> From: Ted Lemon Date: Thu, 19 Jul 2018 19:07:35 -0400 Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000013620c0571624152" Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:08:20 -0000 --00000000000013620c0571624152 Content-Type: text/plain; charset="UTF-8" Sure. If you point your resolver at a DoH server that is not served by the local provisioning domain, then any queries for zones like home.arpa, services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answered with NXDOMAIN, because that's what the delegation from the root says. On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan wrote: > On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: > > clear or unequivocal recommendation. I think that by default you can't > use > > DoH for locally served zones > > Could you say why? > > Thanks, > > A > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000013620c0571624152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure.=C2=A0 =C2=A0If you point your resolver at a DoH serv= er that is not served by the local provisioning domain, then any queries fo= r zones like home.arpa, services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc= , will be answered with NXDOMAIN, because that's what the delegation fr= om the root says.

= On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan <ajs@anvilwalrusden.= com> wrote:
On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote:
> clear or unequivocal recommendation.=C2=A0 =C2=A0I think that by defau= lt you can't use
> DoH for locally served zones

Could you say why?

Thanks,

A
--
Andrew Sullivan
ajs@anvilwalrusden.com

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

--00000000000013620c0571624152-- From nobody Thu Jul 19 16:13:44 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 18981130E34 for ; Thu, 19 Jul 2018 16:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 csc2VZVr9Eoj for ; Thu, 19 Jul 2018 16:13:41 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2795A130E03 for ; Thu, 19 Jul 2018 16:13:41 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 3FCDF175CE9 for ; Thu, 19 Jul 2018 16:13:39 -0700 (PDT) Received: (qmail 27760 invoked from network); 19 Jul 2018 23:13:38 -0000 Received: from 149.sub-174-206-2.myvzw.com (HELO ?100.87.207.96?) (ask@mail.dev@174.206.2.149) by smtp.develooper.com with ESMTPA; 19 Jul 2018 23:13:38 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= X-Mailer: iPhone Mail (16A5327f) In-Reply-To: Date: Thu, 19 Jul 2018 19:13:16 -0400 Cc: Andrew Sullivan , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <31691164-28C6-442E-A39B-F7A1BC7F59BB@develooper.com> References: <20180719230338.GF21643@mx4.yitter.info> To: Ted Lemon Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:13:43 -0000 > On Jul 19, 2018, at 19:07, Ted Lemon wrote: >=20 > Sure. If you point your resolver at a DoH server that is not served by t= he local provisioning domain, then any queries for zones like home.arpa, ser= vices.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answered with NXDO= MAIN, because that's what the delegation from the root says. How is that different from other variations of =E2=80=9Cdifferences when usi= ng a differently configured resolver=E2=80=9D? Ask --=20 http://askask.com/= From nobody Thu Jul 19 16:14: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 1DB40130E4B for ; Thu, 19 Jul 2018 16:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 omT8VX_yQUnb for ; Thu, 19 Jul 2018 16:14:14 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 63E72130E34 for ; Thu, 19 Jul 2018 16:14:14 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by linode64.ducksong.com (Postfix) with ESMTPSA id CC1403A028 for ; Thu, 19 Jul 2018 19:14:13 -0400 (EDT) Received: by mail-oi0-f54.google.com with SMTP id l10-v6so18095083oii.0 for ; Thu, 19 Jul 2018 16:14:13 -0700 (PDT) X-Gm-Message-State: AOUpUlG7xYLjY4deE1O5bKRg/X1vXQacfM7Xs38bWz7x5xKvspe778Sj k142KuWjaeYG6qACY5EwEGk6/MEq5DD1I18hgpk= X-Google-Smtp-Source: AAOMgpeflR6HYsLN95DiXRo2RxyF815YlppeZ58OwkVDn0R1fmAHOHoqcZoB5ssE5W401HGK4Kyz8z7Ub6aaaJdkw2Y= X-Received: by 2002:aca:5f0a:: with SMTP id t10-v6mr906oib.337.1532042053531; Thu, 19 Jul 2018 16:14:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 16:14:13 -0700 (PDT) In-Reply-To: References: <20180719230338.GF21643@mx4.yitter.info> From: Patrick McManus Date: Thu, 19 Jul 2018 19:14:13 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ted Lemon Cc: Andrew Sullivan , DoH WG Content-Type: multipart/alternative; boundary="00000000000061c0a40571625648" Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 23:14:17 -0000 --00000000000061c0a40571625648 Content-Type: text/plain; charset="UTF-8" That's true - but its a property of an open cloud resolver, not DoH (which could be local or cloud). open cloud resolvers are already ~10% of the internet and ~0% of that is DoH. (no cite on that number - its ok if you choose not to believe me :)) DoH does mention it but imo I think it does so with the appropriate amount of emphasis. It might be helpful to have such a statement talking about cloud based dns services independent of protocol. -P On Thu, Jul 19, 2018 at 7:07 PM, Ted Lemon wrote: > Sure. If you point your resolver at a DoH server that is not served by > the local provisioning domain, then any queries for zones like home.arpa, > services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answered with > NXDOMAIN, because that's what the delegation from the root says. > > On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan > wrote: > >> On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: >> > clear or unequivocal recommendation. I think that by default you >> can't use >> > DoH for locally served zones >> >> Could you say why? >> >> Thanks, >> >> A >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> 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 > > --00000000000061c0a40571625648 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's true - but its a property of an open cloud= resolver, not DoH (which could be local or cloud). open cloud resolvers ar= e already ~10% of the internet and ~0% of that is DoH.

<= /div>
(no cite on that number - its ok if you choose not to believe me = :))

DoH does mention it but imo I think it does so= with the appropriate amount of emphasis. It might be helpful to have such = a statement talking about cloud based dns services independent of protocol.=

-P



On Thu, Jul 19, 2018 at 7:07 PM, Ted= Lemon <mellon@fugue.com> wrote:
Sure.=C2=A0 =C2=A0If you point your resolver at a Do= H server that is not served by the local provisioning domain, then any quer= ies for zones like home.arpa, services.arpa, 168.192.in-addr.arpa, ipv4.arp= a, etc, will be answered with NXDOMAIN, because that's what the delegat= ion from the root says.
On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sulliv= an <ajs@anvilwalrusden.com> wrote:
On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon w= rote:
> clear or unequivocal recommendation.=C2=A0 =C2=A0I think that by defau= lt you can't use
> DoH for locally served zones

Could you say why?

Thanks,

A
-- Andrew Sullivan
ajs@anvilwalrus= den.com

_______________________________________________
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


--00000000000061c0a40571625648-- From nobody Thu Jul 19 17:49:30 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 310B0130E2A for ; Thu, 19 Jul 2018 17:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-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=algebras-org.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 SEl-QAFChXRK for ; Thu, 19 Jul 2018 17:49:26 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 BDDAD130DF2 for ; Thu, 19 Jul 2018 17:49:25 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id j5-v6so9690051wrr.8 for ; Thu, 19 Jul 2018 17:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gAbP6CzKeiHlGIQfySENMEr6PEUkkGaefu4RHKOvFfI=; b=X2MPAPg8Q7rKYzVPAr1eOHarscaXAdY68nZJmalKn7Du3EHobHve4KmL8oYEou1z9Q U4KArgi6nQ6WHDQ2IK48C9+7qnBjoO726HQV7uGO7INMvtxBERNZDWcdtC3MQrJ1dqIT zOc49JbNXwyoBmdjB4+R8EqXgAmwTeOFySQvugRNYoG+5iw1TBtxDN/DAVMdJsxa+5gr 8OyLYYvYT3HHDeOW54Yh8BBOHHEHZSYm0gcpzU1LLnJrL1BVxCoqmX8az74peZNW1w7Q UorZ/3nHQrOwLVArWBWBTfv4qE3SGONJSt3d3EkcQ945X5Ws6R/SVpZlq7fsMXuu7aNE vvCA== 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=gAbP6CzKeiHlGIQfySENMEr6PEUkkGaefu4RHKOvFfI=; b=jrfp+xM/oXha7RCQ/SArSdbVt5swEm7vLesZZqqpffDszD5TnishmC0NWwhjDkioCJ Ml7D6klcKZxsIb8RWkGIzpFbHHj+jak3bgEQgKvtJAawY4ssg8LHVytrv000ULFP7mi8 JxIb6laBAA9NgF/7QLnUhARnc5SoFWBIPUNyZLjJKfoGuL/UJckOugj/il3oabY1+hV0 EcM8xrRwq70OrecXSbHxgn9GeY/jkv6eiQ/9+o7DPAuR0FNrT39IbCR08gV4F39JzHSm DoJfFXGHSQ92UHxVGoxj4ewb4K6ZPuPeUWk/a0/Y9TcZ24oaXeZkDpibdW14GBq7KTVH 6eJg== X-Gm-Message-State: AOUpUlHaMYyiXbdFBeCDjPpiXkpkyJ5rSGPcelBeYYQHWmHaD+lpSXKS nokZix3uTgSWCzTmX5QGJewDopHAi9hVGotBlbBiuA== X-Google-Smtp-Source: AAOMgpccdisUaZ+sydbPPu2BXpAm8Rq4GPvUPADhsmrHiMxVti1hwJ7JJBPFpzZ2fifcJDBuhmftLV1nS3MU7zw+Q/E= X-Received: by 2002:adf:f5c3:: with SMTP id k3-v6mr8557081wrp.219.1532047764187; Thu, 19 Jul 2018 17:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:12cb:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 17:49:23 -0700 (PDT) X-Originating-IP: [2001:67c:1232:144:1fd:a40f:46a9:59f1] In-Reply-To: References: <20180719230338.GF21643@mx4.yitter.info> From: George Michaelson Date: Thu, 19 Jul 2018 20:49:23 -0400 Message-ID: To: Patrick McManus Cc: Ted Lemon , DoH WG , Andrew Sullivan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 00:49:29 -0000 If (for instane) I'm bound to a VPN of some kind with split horizon back to home net, and I have DOH served DNS, what would I want .home and .local to do? I'd want them to be "inside" which in a split horizon DNS, I can "see" so to me, this is contextual: if you are inside the home serve context. DOH should serve local not NXDOMAIN. If you use a public resolver service over DOH then no. its NXDOMAIN On Thu, Jul 19, 2018 at 7:14 PM, Patrick McManus wrote: > That's true - but its a property of an open cloud resolver, not DoH (which > could be local or cloud). open cloud resolvers are already ~10% of the > internet and ~0% of that is DoH. > > (no cite on that number - its ok if you choose not to believe me :)) > > DoH does mention it but imo I think it does so with the appropriate amount > of emphasis. It might be helpful to have such a statement talking about > cloud based dns services independent of protocol. > > -P > > > > On Thu, Jul 19, 2018 at 7:07 PM, Ted Lemon wrote: >> >> Sure. If you point your resolver at a DoH server that is not served by >> the local provisioning domain, then any queries for zones like home.arpa, >> services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answered with >> NXDOMAIN, because that's what the delegation from the root says. >> >> On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan >> wrote: >>> >>> On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: >>> > clear or unequivocal recommendation. I think that by default you >>> > can't use >>> > DoH for locally served zones >>> >>> Could you say why? >>> >>> Thanks, >>> >>> A >>> -- >>> Andrew Sullivan >>> ajs@anvilwalrusden.com >>> >>> _______________________________________________ >>> 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 > From nobody Thu Jul 19 17:51: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 0B43F130E2A for ; Thu, 19 Jul 2018 17:51:37 -0700 (PDT) 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, 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=yitter.info header.b=T2DQ6OM7; dkim=pass (1024-bit key) header.d=yitter.info header.b=V7VIxXfK 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 5lKUwyTUDThN for ; Thu, 19 Jul 2018 17:51:33 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B329D130E83 for ; Thu, 19 Jul 2018 17:51:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id BFC55BEBEB; Fri, 20 Jul 2018 00:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1532047862; bh=xwfGdqg9Bf7gx7sAl2/z81Zv1zlS39khegTd8FeAtus=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=T2DQ6OM7qXReQATvpwZLLbZMLRLUzXFWX/GuqOQRPbVTPXr7Y3Ohy01OychHbj0qr e7M1JK/sPYW3S7/fz6O7USPogsUI3dScPKHH/5Zc+oWaB5C54l5xVjOqqktfkuVdg4 uIVsv80y1AFK2b+tq1ocSWPITS3Ap9bAMUQe3BYc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKubPJ82jO9F; Fri, 20 Jul 2018 00:51:01 +0000 (UTC) From: Andrew Sullivan DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1532047861; bh=xwfGdqg9Bf7gx7sAl2/z81Zv1zlS39khegTd8FeAtus=; h=From:To:CC:Date:In-Reply-To:References:Subject:From; b=V7VIxXfKvWwTAN/qZd8/nmf7iA3/eWvNkPK9EtHhIHpPpZkuvsZGjq/Wp52Bvj9UE 15ql16wSut5z2m4W66sgwnEQoy5Ke1SZanb4nDMkyaYbjIxLPp7tDn7MsKrpUKdeCD Wa/7q91lb/1QIRHrvTsk8LUjjrKJVNRd0Er/xjpc= To: George Michaelson , Patrick McManus CC: DoH WG , Ted Lemon Date: Thu, 19 Jul 2018 20:50:59 -0400 Message-ID: <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: References: <20180719230338.GF21643@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 00:51:37 -0000 Sure. But none of this is unique to DoH, is it? A -- Please excuse my clumbsy thums ---------- On July 19, 2018 20:49:36 George Michaelson wrote: > If (for instane) I'm bound to a VPN of some kind with split horizon > back to home net, and I have DOH served DNS, what would I want .home > and .local to do? I'd want them to be "inside" which in a split > horizon DNS, I can "see" > > so to me, this is contextual: if you are inside the home serve > context. DOH should serve local not NXDOMAIN. > > If you use a public resolver service over DOH then no. its NXDOMAIN > > On Thu, Jul 19, 2018 at 7:14 PM, Patrick McManus wrote: >> That's true - but its a property of an open cloud resolver, not DoH (which >> could be local or cloud). open cloud resolvers are already ~10% of the >> internet and ~0% of that is DoH. >> >> (no cite on that number - its ok if you choose not to believe me :)) >> >> DoH does mention it but imo I think it does so with the appropriate amount >> of emphasis. It might be helpful to have such a statement talking about >> cloud based dns services independent of protocol. >> >> -P >> >> >> >> On Thu, Jul 19, 2018 at 7:07 PM, Ted Lemon wrote: >>> >>> Sure. If you point your resolver at a DoH server that is not served by >>> the local provisioning domain, then any queries for zones like home.arpa, >>> services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answered with >>> NXDOMAIN, because that's what the delegation from the root says. >>> >>> On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan >>> wrote: >>>> >>>> On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: >>>> > clear or unequivocal recommendation. I think that by default you >>>> > can't use >>>> > DoH for locally served zones >>>> >>>> Could you say why? >>>> >>>> Thanks, >>>> >>>> A >>>> -- >>>> Andrew Sullivan >>>> ajs@anvilwalrusden.com >>>> >>>> _______________________________________________ >>>> 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 >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Thu Jul 19 18:28: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 C7DCA130F76 for ; Thu, 19 Jul 2018 18:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-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=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 3d7-9lKHrt4w for ; Thu, 19 Jul 2018 18:28:11 -0700 (PDT) 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 2018E130E55 for ; Thu, 19 Jul 2018 18:28:11 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id h2-v6so12587866itj.1 for ; Thu, 19 Jul 2018 18:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7tAJl30FQc6E+VS5254XRkKiZzM8b2ZXEPEm8ZJx2CQ=; b=MqPfydrbMkc1cLaXaUHunLUQE6eo1VWClkSIHYz6OkbfqkJWBfbgji86q9FcUEt7iP SmdhNKieCs2sjfprlqq+XqDeRyAKMqFLxdMd5UMx0yO9SV2+eezWFbdFsauKC+f3428T DKoVnIy26/eb6N/0o0PALe7ucP9Fn3h6NBL0IRn50YhYXYXoe0fpO0BIZaw/gnaF6L3k ckbf61aV0jtygpSehTisvz2F59/jWp3UVgQ5zonost46Ph8GjLbuNZWp+x7z5yEVzCsL n7LuubhoAy3Gss7vIlPEvyil4il1dKObE5asvK9U1GpTZl0EWkEnZ/VPhDav4GwsPeeT EGog== 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=7tAJl30FQc6E+VS5254XRkKiZzM8b2ZXEPEm8ZJx2CQ=; b=oXzilXuM1oIwUEYga2jyDrAzGOMj0SQnMI2tMP72yMdifz22JE9TNyhO/k++R+VOdM VaX6eSP9kaiITChF+uurgBHxvOqV/EOt8pAx3NUt/k7AqwNxKjgkdeDfAixesRd4UUVQ abrGS2G9H0Fddno1ze2kpbFuc4dbXBFOHtYtGAYyeLBydt+i8JYmmw3t0QBzm9cdWFwR u5M1moNs9xhr0cxewBpCQhkYgvSiD57Y0KKrJGN4KxqJJDf+Nvt39yjFoOfvH2d0NZNt 18o5Kw4BC9yn5GpRdZnlP2O84ulNuBaup+DDlq4Hjp27N0W+UpwGlti+WAGVYOBzoTMh hypg== X-Gm-Message-State: AOUpUlGoVGoLs6E8VjMpI9jB3gUX9vCvjD6W1ErvSdxlVZn9OEW993Ur ppTeY5dT7u5PtpOe+HszseeaLCIHjID5piWztG4/Zg== X-Google-Smtp-Source: AAOMgpfByh7KHHZNbYI/vD6EaoElgJLZVGqJSbaEFL/LeAz1B43I4gJjmCadVevpx+DUUITDo25DAG9PG1timwkEYrI= X-Received: by 2002:a24:4dd3:: with SMTP id l202-v6mr315806itb.144.1532050090295; Thu, 19 Jul 2018 18:28:10 -0700 (PDT) MIME-Version: 1.0 References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> In-Reply-To: <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> From: Ted Lemon Date: Thu, 19 Jul 2018 21:27:59 -0400 Message-ID: To: Andrew Sullivan Cc: DoH WG , George Michaelson , Patrick McManus Content-Type: multipart/alternative; boundary="00000000000069253205716435e3" Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 01:28:15 -0000 --00000000000069253205716435e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To be clear, I am not saying doh can=E2=80=99t serve locally-served zones. = I am saying that we need to talk about the problem explicitly to make sure resolver implementers are aware of the issue. On Thu, Jul 19, 2018 at 8:51 PM Andrew Sullivan wrote: > Sure. But none of this is unique to DoH, is it? > > A > > -- > Please excuse my clumbsy thums > ---------- > On July 19, 2018 20:49:36 George Michaelson wrote: > > > If (for instane) I'm bound to a VPN of some kind with split horizon > > back to home net, and I have DOH served DNS, what would I want .home > > and .local to do? I'd want them to be "inside" which in a split > > horizon DNS, I can "see" > > > > so to me, this is contextual: if you are inside the home serve > > context. DOH should serve local not NXDOMAIN. > > > > If you use a public resolver service over DOH then no. its NXDOMAIN > > > > On Thu, Jul 19, 2018 at 7:14 PM, Patrick McManus > wrote: > >> That's true - but its a property of an open cloud resolver, not DoH > (which > >> could be local or cloud). open cloud resolvers are already ~10% of the > >> internet and ~0% of that is DoH. > >> > >> (no cite on that number - its ok if you choose not to believe me :)) > >> > >> DoH does mention it but imo I think it does so with the appropriate > amount > >> of emphasis. It might be helpful to have such a statement talking abou= t > >> cloud based dns services independent of protocol. > >> > >> -P > >> > >> > >> > >> On Thu, Jul 19, 2018 at 7:07 PM, Ted Lemon wrote: > >>> > >>> Sure. If you point your resolver at a DoH server that is not served > by > >>> the local provisioning domain, then any queries for zones like > home.arpa, > >>> services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answered > with > >>> NXDOMAIN, because that's what the delegation from the root says. > >>> > >>> On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan < > ajs@anvilwalrusden.com> > >>> wrote: > >>>> > >>>> On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: > >>>> > clear or unequivocal recommendation. I think that by default you > >>>> > can't use > >>>> > DoH for locally served zones > >>>> > >>>> Could you say why? > >>>> > >>>> Thanks, > >>>> > >>>> A > >>>> -- > >>>> Andrew Sullivan > >>>> ajs@anvilwalrusden.com > >>>> > >>>> _______________________________________________ > >>>> 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 > >> > > > > _______________________________________________ > > Doh mailing list > > Doh@ietf.org > > https://www.ietf.org/mailman/listinfo/doh > > > > --00000000000069253205716435e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To be clear, I am not saying doh can=E2=80=99t serve= locally-served zones. I am saying that we need to talk about the problem e= xplicitly to make sure resolver implementers are aware of the issue. =C2=A0=

On Thu, Ju= l 19, 2018 at 8:51 PM Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Sure. But none of this is unique to DoH, is it?

A

--
Please excuse my clumbsy thums
----------
On July 19, 2018 20:49:36 George Michaelson <ggm@algebras.org> wrote:

> If (for instane) I'm bound to a VPN of some kind with split horizo= n
> back to home net, and I have DOH served DNS, what would I want .home > and .local to do? I'd want them to be "inside" which in = a split
> horizon DNS, I can "see"
>
> so to me, this is contextual: if you are inside the home serve
> context. DOH should serve local not NXDOMAIN.
>
> If you use a public resolver service over DOH then no. its NXDOMAIN >
> On Thu, Jul 19, 2018 at 7:14 PM, Patrick McManus <pmcmanus@mozilla.com> wrote= :
>> That's true - but its a property of an open cloud resolver, no= t DoH (which
>> could be local or cloud). open cloud resolvers are already ~10% of= the
>> internet and ~0% of that is DoH.
>>
>> (no cite on that number - its ok if you choose not to believe me := ))
>>
>> DoH does mention it but imo I think it does so with the appropriat= e amount
>> of emphasis. It might be helpful to have such a statement talking = about
>> cloud based dns services independent of protocol.
>>
>> -P
>>
>>
>>
>> On Thu, Jul 19, 2018 at 7:07 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>
>>> Sure.=C2=A0 =C2=A0If you point your resolver at a DoH server t= hat is not served by
>>> the local provisioning domain, then any queries for zones like= home.arpa,
>>> services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be a= nswered with
>>> NXDOMAIN, because that's what the delegation from the root= says.
>>>
>>> On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan <ajs@anvilwalrusden.com= >
>>> wrote:
>>>>
>>>> On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote:=
>>>> > clear or unequivocal recommendation.=C2=A0 =C2=A0I th= ink that by default you
>>>> > can't use
>>>> > DoH for locally served zones
>>>>
>>>> Could you say why?
>>>>
>>>> Thanks,
>>>>
>>>> A
>>>> --
>>>> Andrew Sullivan
>>>> ajs@anvilwalrusden.com
>>>>
>>>> _______________________________________________
>>>> 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<= br> >>>
>>
>>
>> _______________________________________________
>> 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



--00000000000069253205716435e3-- From nobody Thu Jul 19 19:49:53 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 2458F13103F for ; Thu, 19 Jul 2018 19:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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=hotmail.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 AkvyPcLXSUFi for ; Thu, 19 Jul 2018 19:49:47 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03olkn0808.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::808]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552FE130E12 for ; Thu, 19 Jul 2018 19:49:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zKrYr7Tp75Wp9asOiYKUILw+7F3rAGz1e2s6oiZpQ/Q=; b=PtKSOet3Nu4XJJGOIrm2mH4AuTA0H6vMzJxUJlPDOQNXiKKTos/wlrXUo0cgNkLFgHvjtqFSBs8f9+6GNZRLtQdkF+LohbhNF+FmyNDnBOJJ/aUWVk5ARCyBux6/B9BepNLvq0ZnmcSxyQLgSn0cRQqdvs7lA4oswbLIH48Ny/fN5OduWVcEyes5kbP1ZFVHdlASzkI16CG9iZKUftNoEXCu2V20b1mwcW8+Jp2pBMYqENkGpwwqNCOlsSgAdJstZ1Moj0/rvk91oaP7xO8AaDmN9lkSqzznpxW3ZVhc5Ha/4nLJwnbj4qvcahPy45m7vGk7qwf/aNoeRzbu5A6hlQ== Received: from BY2NAM03FT042.eop-NAM03.prod.protection.outlook.com (10.152.84.56) by BY2NAM03HT082.eop-NAM03.prod.protection.outlook.com (10.152.85.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.952.17; Fri, 20 Jul 2018 02:49:46 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.84.51) by BY2NAM03FT042.mail.protection.outlook.com (10.152.85.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.952.17 via Frontend Transport; Fri, 20 Jul 2018 02:49:46 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::8514:9a20:4e1c:783d]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::8514:9a20:4e1c:783d%2]) with mapi id 15.20.0973.018; Fri, 20 Jul 2018 02:49:46 +0000 From: Star Brilliant To: DoH WG Thread-Topic: [Doh] Locally served zones in DoH Thread-Index: AQHUH7QURycu6eRNmU6dYC8V7oF736SXKgwAgAABGoCAAAHbgIAAGpeAgAAAcoCAAApXgIAAFqvW Date: Fri, 20 Jul 2018 02:49:45 +0000 Message-ID: References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:87E836FBB5CA4B43AB09DBBA964875D8960C348B27F204566F1FE3050F1F3667; UpperCasedChecksum:654C137A10585C1B52D8D0DF72575EFE38883403371A3758DE042316F1DDD7E0; SizeAsReceived:7438; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [THuYHLtQ2FGXR1sb4LunI4/7YBGKrG3E] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2NAM03HT082; 7:9GVpFnbrGbXjBPgjnT0Iy68QmApUOEqJAOLRoD0MHJD0piKZFkKQ7ZH1hhQAyWIHWgWJa9rSx8PpRDWAZb1HOwlrk+T6Wke3xbRsm+xAjOTKLku7GrFO1QgG1Qizu8jyY5FjWjg4RNaBcz49JmsKiqJmpxZHLC812CfJqdFMRrLHWe5LJe8l6AP2X5ImMq2EkmL1S1oqsfGpn/RyAgJqUJc3GCw3ekN47kiMM0tAGosidViW5I3n7DpzkpEfjaSO x-incomingheadercount: 46 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125500)(1701031045); SRVR:BY2NAM03HT082; x-ms-traffictypediagnostic: BY2NAM03HT082: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(82015058); SRVR:BY2NAM03HT082; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM03HT082; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(51444003)(14454004)(2900100001)(55016002)(97736004)(6306002)(9686003)(6436002)(229853002)(82202002)(87572001)(20460500001)(6246003)(5250100002)(33656002)(966005)(83332001)(68736007)(25786009)(73972006)(105586002)(106356001)(476003)(99286004)(86362001)(53546011)(102836004)(6916009)(486006)(446003)(6506007)(26005)(8676002)(11346002)(93886005)(5660300001)(8936002)(6346003)(56003)(81156014)(256004)(14444005)(104016004)(7696005)(74316002)(76176011)(305945005)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BY2NAM03HT082; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: pctO66KTHiaY7fG7RFSF7t0tCxBsYGn3BDo24p24gLzIACWamGyHleoIrHSjGGhBEp/8HkD7FibfMQkbnnafFiT3kheUPXUQ2DUbCQdqIBMcYjDs8K/eKfV145irQdvNAWRsMm3pKfi4Y3gIWdFkLL05eOSI5UCgpd9It96YwZr6Us4Vn4KNJS7ms/JSEkWGxbqpD8fn3g9uuZYqTTx7c2P11HXn6j/9lnqMn/TZyAE= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: f16c8810-8cd0-4fd3-0450-08d5edeb73e8 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 02:49:45.9850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT082 Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 02:49:50 -0000 Actually the resolver cannot control the behavior of local zone resolution.= It is controlled by the operating system. >From my experience from a DoH setup on a Mac, mDNSResponder issues a "local= . IN SOA" query to DoH to detect local-zone availability, and switch to mDN= S (multicast DNS) when it founds DoH server not responsible for local zone. Also, AFAIK Linux uses a combination glibc, avahi, and sytemd-resolvd to au= tomatically do this. So in most situation, the OS uses unicast DNS for local zone if available, = and falls back to multicast DNS when unavailable. You don't need to do anyt= hing to make it work. But your situation is different: You use a split-tunnel VPN. Depending on y= our OS and network manager (NetworkManager, systemd-networkd, SystemConfigu= ration.framework, NetConnection), when you connected to a VPN, your previou= s DNS configuration may be lost. If this happens, I suggest you to install a local DNS server to do split DN= S resolving. My recommendation is Unbound, although dnsmasq and knot-resolver are also p= opular. You may refer to "forward-zone" in the Unbound documentation to build your = resolver configuration. In conclusion, this is neither a problem of DNS or a problem of DoH. It's j= ust your OS and network manager should be aware that you need two or more r= esolvers for a mixed network environment. On Fri, Jul 20, 2018 at 11:28 AM Ted Lemon wrote: > > To be clear, I am not saying doh can=92t serve locally-served zones. I am= saying that we need to talk about the problem explicitly to make sure reso= lver implementers are aware of the issue. =20 > > On Thu, Jul 19, 2018 at 8:51 PM Andrew Sullivan = wrote: >> >> Sure. But none of this is unique to DoH, is it? >> >> A >> >> -- >> Please excuse my clumbsy thums >> ---------- >> On July 19, 2018 20:49:36 George Michaelson wrote: >> >> > If (for instane) I'm bound to a VPN of some kind with split horizon >> > back to home net, and I have DOH served DNS, what would I want .home >> > and .local to do? I'd want them to be "inside" which in a split >> > horizon DNS, I can "see" >> > >> > so to me, this is contextual: if you are inside the home serve >> > context. DOH should serve local not NXDOMAIN. >> > >> > If you use a public resolver service over DOH then no. its NXDOMAIN >> > >> > On Thu, Jul 19, 2018 at 7:14 PM, Patrick McManus wrote: >> >> That's true - but its a property of an open cloud resolver, not DoH (= which >> >> could be local or cloud). open cloud resolvers are already ~10% of th= e >> >> internet and ~0% of that is DoH. >> >> >> >> (no cite on that number - its ok if you choose not to believe me :)) >> >> >> >> DoH does mention it but imo I think it does so with the appropriate a= mount >> >> of emphasis. It might be helpful to have such a statement talking abo= ut >> >> cloud based dns services independent of protocol. >> >> >> >> -P >> >> >> >> >> >> >> >> On Thu, Jul 19, 2018 at 7:07 PM, Ted Lemon wrote: >> >>> >> >>> Sure. If you point your resolver at a DoH server that is not serve= d by >> >>> the local provisioning domain, then any queries for zones like home.= arpa, >> >>> services.arpa, 168.192.in-addr.arpa, ipv4.arpa, etc, will be answere= d with >> >>> NXDOMAIN, because that's what the delegation from the root says. >> >>> >> >>> On Thu, Jul 19, 2018 at 7:03 PM, Andrew Sullivan >> >>> wrote: >> >>>> >> >>>> On Thu, Jul 19, 2018 at 06:57:54PM -0400, Ted Lemon wrote: >> >>>> > clear or unequivocal recommendation. I think that by default yo= u >> >>>> > can't use >> >>>> > DoH for locally served zones >> >>>> >> >>>> Could you say why? >> >>>> >> >>>> Thanks, >> >>>> >> >>>> A >> >>>> -- >> >>>> Andrew Sullivan >> >>>> ajs@anvilwalrusden.com >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >> >> > >> > _______________________________________________ >> > 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= From nobody Thu Jul 19 22:25:17 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 78816130E46 for ; Thu, 19 Jul 2018 22:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 Zl4Trl3UXS40 for ; Thu, 19 Jul 2018 22:25:11 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1814212872C for ; Thu, 19 Jul 2018 22:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7406; q=dns/txt; s=iport; t=1532064311; x=1533273911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QS87vOPBEjVfWrSalI7Q7RK+BH8G7s/g77zAN5gIb2s=; b=F4sRBUsKbMWwtzwS6vSxhMPAq0KX5WI8dQUUrmQG7+k1bN34i2GNvtfE LYuxDNdKq0AoKTKfvONq+fiuIZYb2sSgqZ4xrH5DBsFZiU1IpPbSIzIBb ljkuvAC8LNQ5JtKYXIJt7ZDjAirh50VMIvOiVmnrbpSdb/lqopcq/TZog 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAQDBcVFb/5hdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNNY38og36IBIwwggyCVGSFAY0DgXoLGAuESQIXgm8hNBg?= =?us-ascii?q?BAgEBAgEBAm0cDIU2AQEBAwEBASEROgsFCwIBCA4KAgImAgICJQsVEAIEDgW?= =?us-ascii?q?DIAGBZwMNCA+qDoEuhF2FbgWBC4d3gVc/gTiCPC6CVkMBAYFKLYJqMYIkAod?= =?us-ascii?q?qkVMrCQKMIoMLgUSEEogXixCGZgIRFIEkHTiBUnAVOyoBgj6CKhKIWYU+b4w?= =?us-ascii?q?SAQE?= X-IronPort-AV: E=Sophos;i="5.51,377,1526342400"; d="scan'208";a="208377966" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2018 05:25:09 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w6K5P9ue002621 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jul 2018 05:25:09 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Jul 2018 00:25:09 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Fri, 20 Jul 2018 00:25:09 -0500 From: "Eliot Lear (elear)" To: Star Brilliant CC: DoH WG Thread-Topic: [Doh] Locally served zones in DoH Thread-Index: AQHUH7QWiTIEabhpMkqkRCkDDDHCjKSXfd4AgAABGoCAAAHagIAAGpeAgAAAc4CAAApWgIAAFtmA///XmWI= Date: Fri, 20 Jul 2018 05:25:09 +0000 Message-ID: References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 05:25:15 -0000 VGhhdCBpdOKAmXMgbm90IHVuaXF1ZSB0byBkb2ggZG9lc27igJl0IG1lYW4gaXQgaXNu4oCZdCBh IHByb2JsZW0uICBCdXQgSeKAmW0gc3VyZSB0aGF0IGFic2VudCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIGl0IHdpbGwgbWVhbiBwZW9wbGUgaGF2aW5nIHRvIHR1cm4gZG9oIG9mZiBpbiBzcGxpdCBo b3Jpem9uIGVudmlyb25tZW50cy4gSGF2aW5nIHNvbWUgbm90aW9uIG9mIGxvY2FsaXR5IGlzIGlt cG9ydGFudCBhbmQgbm90IGFsd2F5cyBlYXNpbHkgYXZhaWxhYmxlIG9uIGZpcnN0IHVzZS4gIEFz IHdlIGRpc2N1c3NlZCBlYXJseSBvbiBzb21lIG9mIHRoaXMgY2FuIGJlIHJlbWVkaWF0ZWQgd2l0 aCBhZGRpdGlvbmFsIHF1ZXJpZXMgYnV0IG9ubHkgd2hlbiBOWERPTUFJTiBpcyByZXR1cm5lZC4g DQoNCkVsaW90DQoNCj4gT24gSnVsIDIwLCAyMDE4LCBhdCAwNDo0OSwgU3RhciBCcmlsbGlhbnQg PG0xMzI1M0Bob3RtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBBY3R1YWxseSB0aGUgcmVzb2x2ZXIg Y2Fubm90IGNvbnRyb2wgdGhlIGJlaGF2aW9yIG9mIGxvY2FsIHpvbmUgcmVzb2x1dGlvbi4gSXQg aXMgY29udHJvbGxlZCBieSB0aGUgb3BlcmF0aW5nIHN5c3RlbS4NCj4gDQo+PiBGcm9tIG15IGV4 cGVyaWVuY2UgZnJvbSBhIERvSCBzZXR1cCBvbiBhIE1hYywgbUROU1Jlc3BvbmRlciBpc3N1ZXMg YSAibG9jYWwuIElOIFNPQSIgcXVlcnkgdG8gRG9IIHRvIGRldGVjdCBsb2NhbC16b25lIGF2YWls YWJpbGl0eSwgYW5kIHN3aXRjaCB0byBtRE5TIChtdWx0aWNhc3QgRE5TKSB3aGVuIGl0IGZvdW5k cyBEb0ggc2VydmVyIG5vdCByZXNwb25zaWJsZSBmb3IgbG9jYWwgem9uZS4NCj4gQWxzbywgQUZB SUsgTGludXggdXNlcyBhIGNvbWJpbmF0aW9uIGdsaWJjLCBhdmFoaSwgYW5kIHN5dGVtZC1yZXNv bHZkIHRvIGF1dG9tYXRpY2FsbHkgZG8gdGhpcy4NCj4gDQo+IFNvIGluIG1vc3Qgc2l0dWF0aW9u LCB0aGUgT1MgdXNlcyB1bmljYXN0IEROUyBmb3IgbG9jYWwgem9uZSBpZiBhdmFpbGFibGUsIGFu ZCBmYWxscyBiYWNrIHRvIG11bHRpY2FzdCBETlMgd2hlbiB1bmF2YWlsYWJsZS4gWW91IGRvbid0 IG5lZWQgdG8gZG8gYW55dGhpbmcgdG8gbWFrZSBpdCB3b3JrLg0KPiANCj4gQnV0IHlvdXIgc2l0 dWF0aW9uIGlzIGRpZmZlcmVudDogWW91IHVzZSBhIHNwbGl0LXR1bm5lbCBWUE4uIERlcGVuZGlu ZyBvbiB5b3VyIE9TIGFuZCBuZXR3b3JrIG1hbmFnZXIgKE5ldHdvcmtNYW5hZ2VyLCBzeXN0ZW1k LW5ldHdvcmtkLCBTeXN0ZW1Db25maWd1cmF0aW9uLmZyYW1ld29yaywgTmV0Q29ubmVjdGlvbiks IHdoZW4geW91IGNvbm5lY3RlZCB0byBhIFZQTiwgeW91ciBwcmV2aW91cyBETlMgY29uZmlndXJh dGlvbiBtYXkgYmUgbG9zdC4NCj4gSWYgdGhpcyBoYXBwZW5zLCBJIHN1Z2dlc3QgeW91IHRvIGlu c3RhbGwgYSBsb2NhbCBETlMgc2VydmVyIHRvIGRvIHNwbGl0IEROUyByZXNvbHZpbmcuDQo+IA0K PiBNeSByZWNvbW1lbmRhdGlvbiBpcyBVbmJvdW5kLCBhbHRob3VnaCBkbnNtYXNxIGFuZCBrbm90 LXJlc29sdmVyIGFyZSBhbHNvIHBvcHVsYXIuDQo+IFlvdSBtYXkgcmVmZXIgdG8gImZvcndhcmQt em9uZSIgaW4gdGhlIFVuYm91bmQgZG9jdW1lbnRhdGlvbiB0byBidWlsZCB5b3VyIHJlc29sdmVy IGNvbmZpZ3VyYXRpb24uDQo+IA0KPiBJbiBjb25jbHVzaW9uLCB0aGlzIGlzIG5laXRoZXIgYSBw cm9ibGVtIG9mIEROUyBvciBhIHByb2JsZW0gb2YgRG9ILiBJdCdzIGp1c3QgeW91ciBPUyBhbmQg bmV0d29yayBtYW5hZ2VyIHNob3VsZCBiZSBhd2FyZSB0aGF0IHlvdSBuZWVkIHR3byBvciBtb3Jl IHJlc29sdmVycyBmb3IgYSBtaXhlZCBuZXR3b3JrIGVudmlyb25tZW50Lg0KPiANCj4gDQo+PiBP biBGcmksIEp1bCAyMCwgMjAxOCBhdCAxMToyOCBBTSBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5j b20+IHdyb3RlOg0KPj4gDQo+PiBUbyBiZSBjbGVhciwgSSBhbSBub3Qgc2F5aW5nIGRvaCBjYW7i gJl0IHNlcnZlIGxvY2FsbHktc2VydmVkIHpvbmVzLiBJIGFtIHNheWluZyB0aGF0IHdlIG5lZWQg dG8gdGFsayBhYm91dCB0aGUgcHJvYmxlbSBleHBsaWNpdGx5IHRvIG1ha2Ugc3VyZSByZXNvbHZl ciBpbXBsZW1lbnRlcnMgYXJlIGF3YXJlIG9mIHRoZSBpc3N1ZS4gIA0KPj4gDQo+Pj4gT24gVGh1 LCBKdWwgMTksIDIwMTggYXQgODo1MSBQTSBBbmRyZXcgU3VsbGl2YW4gPGFqc0BhbnZpbHdhbHJ1 c2Rlbi5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IFN1cmUuIEJ1dCBub25lIG9mIHRoaXMgaXMgdW5p cXVlIHRvIERvSCwgaXMgaXQ/DQo+Pj4gDQo+Pj4gQQ0KPj4+IA0KPj4+IC0tDQo+Pj4gUGxlYXNl IGV4Y3VzZSBteSBjbHVtYnN5IHRodW1zDQo+Pj4gLS0tLS0tLS0tLQ0KPj4+PiBPbiBKdWx5IDE5 LCAyMDE4IDIwOjQ5OjM2IEdlb3JnZSBNaWNoYWVsc29uIDxnZ21AYWxnZWJyYXMub3JnPiB3cm90 ZToNCj4+Pj4gDQo+Pj4+IElmIChmb3IgaW5zdGFuZSkgSSdtIGJvdW5kIHRvIGEgVlBOIG9mIHNv bWUga2luZCB3aXRoIHNwbGl0IGhvcml6b24NCj4+Pj4gYmFjayB0byBob21lIG5ldCwgYW5kIEkg aGF2ZSBET0ggc2VydmVkIEROUywgd2hhdCB3b3VsZCBJIHdhbnQgLmhvbWUNCj4+Pj4gYW5kIC5s b2NhbCB0byBkbz8gSSdkIHdhbnQgdGhlbSB0byBiZSAiaW5zaWRlIiB3aGljaCBpbiBhIHNwbGl0 DQo+Pj4+IGhvcml6b24gRE5TLCBJIGNhbiAic2VlIg0KPj4+PiANCj4+Pj4gc28gdG8gbWUsIHRo aXMgaXMgY29udGV4dHVhbDogaWYgeW91IGFyZSBpbnNpZGUgdGhlIGhvbWUgc2VydmUNCj4+Pj4g Y29udGV4dC4gRE9IIHNob3VsZCBzZXJ2ZSBsb2NhbCBub3QgTlhET01BSU4uDQo+Pj4+IA0KPj4+ PiBJZiB5b3UgdXNlIGEgcHVibGljIHJlc29sdmVyIHNlcnZpY2Ugb3ZlciBET0ggdGhlbiBuby4g aXRzIE5YRE9NQUlODQo+Pj4+IA0KPj4+Pj4gT24gVGh1LCBKdWwgMTksIDIwMTggYXQgNzoxNCBQ TSwgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT4gd3JvdGU6DQo+Pj4+PiBU aGF0J3MgdHJ1ZSAtIGJ1dCBpdHMgYSBwcm9wZXJ0eSBvZiBhbiBvcGVuIGNsb3VkIHJlc29sdmVy LCBub3QgRG9IICh3aGljaA0KPj4+Pj4gY291bGQgYmUgbG9jYWwgb3IgY2xvdWQpLiBvcGVuIGNs b3VkIHJlc29sdmVycyBhcmUgYWxyZWFkeSB+MTAlIG9mIHRoZQ0KPj4+Pj4gaW50ZXJuZXQgYW5k IH4wJSBvZiB0aGF0IGlzIERvSC4NCj4+Pj4+IA0KPj4+Pj4gKG5vIGNpdGUgb24gdGhhdCBudW1i ZXIgLSBpdHMgb2sgaWYgeW91IGNob29zZSBub3QgdG8gYmVsaWV2ZSBtZSA6KSkNCj4+Pj4+IA0K Pj4+Pj4gRG9IIGRvZXMgbWVudGlvbiBpdCBidXQgaW1vIEkgdGhpbmsgaXQgZG9lcyBzbyB3aXRo IHRoZSBhcHByb3ByaWF0ZSBhbW91bnQNCj4+Pj4+IG9mIGVtcGhhc2lzLiBJdCBtaWdodCBiZSBo ZWxwZnVsIHRvIGhhdmUgc3VjaCBhIHN0YXRlbWVudCB0YWxraW5nIGFib3V0DQo+Pj4+PiBjbG91 ZCBiYXNlZCBkbnMgc2VydmljZXMgaW5kZXBlbmRlbnQgb2YgcHJvdG9jb2wuDQo+Pj4+PiANCj4+ Pj4+IC1QDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+Pj4gT24gVGh1LCBKdWwgMTksIDIw MTggYXQgNzowNyBQTSwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiB3cm90ZToNCj4+Pj4+ PiANCj4+Pj4+PiBTdXJlLiAgIElmIHlvdSBwb2ludCB5b3VyIHJlc29sdmVyIGF0IGEgRG9IIHNl cnZlciB0aGF0IGlzIG5vdCBzZXJ2ZWQgYnkNCj4+Pj4+PiB0aGUgbG9jYWwgcHJvdmlzaW9uaW5n IGRvbWFpbiwgdGhlbiBhbnkgcXVlcmllcyBmb3Igem9uZXMgbGlrZSBob21lLmFycGEsDQo+Pj4+ Pj4gc2VydmljZXMuYXJwYSwgMTY4LjE5Mi5pbi1hZGRyLmFycGEsIGlwdjQuYXJwYSwgZXRjLCB3 aWxsIGJlIGFuc3dlcmVkIHdpdGgNCj4+Pj4+PiBOWERPTUFJTiwgYmVjYXVzZSB0aGF0J3Mgd2hh dCB0aGUgZGVsZWdhdGlvbiBmcm9tIHRoZSByb290IHNheXMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24g VGh1LCBKdWwgMTksIDIwMTggYXQgNzowMyBQTSwgQW5kcmV3IFN1bGxpdmFuIDxhanNAYW52aWx3 YWxydXNkZW4uLmNvbT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBPbiBUaHUs IEp1bCAxOSwgMjAxOCBhdCAwNjo1Nzo1NFBNIC0wNDAwLCBUZWQgTGVtb24gd3JvdGU6DQo+Pj4+ Pj4+PiBjbGVhciBvciB1bmVxdWl2b2NhbCByZWNvbW1lbmRhdGlvbi4gICBJIHRoaW5rIHRoYXQg YnkgZGVmYXVsdCB5b3UNCj4+Pj4+Pj4+IGNhbid0IHVzZQ0KPj4+Pj4+Pj4gRG9IIGZvciBsb2Nh bGx5IHNlcnZlZCB6b25lcw0KPj4+Pj4+PiANCj4+Pj4+Pj4gQ291bGQgeW91IHNheSB3aHk/DQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBBDQo+Pj4+Pj4+IC0t DQo+Pj4+Pj4+IEFuZHJldyBTdWxsaXZhbg0KPj4+Pj4+PiBhanNAYW52aWx3YWxydXNkZW4uY29t DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+PiBEb2ggbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IERvaEBpZXRmLi5v cmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb2gNCj4+ Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IERvaCBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBE b2hAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvaA0KPj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBEb2ggbWFpbGluZyBsaXN0DQo+Pj4+ PiBEb2hAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG9oDQo+Pj4+PiANCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IERvaCBtYWlsaW5nIGxpc3QNCj4+Pj4gRG9oQGlldGYu b3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG9oDQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gRG9oIG1haWxpbmcgbGlzdA0KPj4gRG9oQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvaA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb2ggbWFpbGluZyBsaXN0DQo+IERvaEBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvaA0K From nobody Fri Jul 20 05:46:40 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 3E6C1127332 for ; Fri, 20 Jul 2018 05:46:38 -0700 (PDT) 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, 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=yitter.info header.b=KlVTAsAp; dkim=pass (1024-bit key) header.d=yitter.info header.b=en96oDcQ 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 F1COXmFGgNT4 for ; Fri, 20 Jul 2018 05:46:35 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45EA612426A for ; Fri, 20 Jul 2018 05:46:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 6A4DDBEBEB for ; Fri, 20 Jul 2018 12:46:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1532090764; bh=/7AqDKA1nPmcMp93FzpsH2lbC56SPNfpLnYFC7WGo6o=; h=Date:From:To:Subject:References:In-Reply-To:From; b=KlVTAsAp6icJb8u0xrPzSZpyQtqvasnMaKsPVDXTn+Lh2BWzm+Kc0r0GjExxqAXHG yskpWxk8DqxjwpMAmBbGCvvmWUz822qgH4o7gUDxe//bWWTNPZeki8z5qMmzXpw774 rSQ/NF3x2xw86zT3zy2ZNEMSAOYWWPImubQGbjco= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19FY484hWtjZ for ; Fri, 20 Jul 2018 12:46:03 +0000 (UTC) Date: Fri, 20 Jul 2018 08:45:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1532090763; bh=/7AqDKA1nPmcMp93FzpsH2lbC56SPNfpLnYFC7WGo6o=; h=Date:From:To:Subject:References:In-Reply-To:From; b=en96oDcQPaslydhIiPJ0w8ohNQumonwDmKVD5uXeNGsSVgZ0YizfovTlfiwx0XBdl otQJrWdhLEr0ox9M9LUIkoOhe+V+P0t5rI5dxr6jAm2MMQfLn1THu39gzujGPkXJUg XFgdJOvQpnw4/zomXINhLRr2dk+53VwkGByOaGSg= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180720124559.GA1029@mx4.yitter.info> References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 12:46:39 -0000 On Fri, Jul 20, 2018 at 05:25:09AM +0000, Eliot Lear (elear) wrote: > That it’s not unique to doh doesn’t mean it isn’t a problem. Well, yes, obviously, but I don't understand how RFC 6303 isn't a consideration here. DoH servers serve DNS data, and considerations about the data servers are supposed to serve apply equally to them as to any other DNS-serving server, I think. Isn't that enough to say? >But I’m sure that absent additional information it will mean people >having to turn doh off in split horizon environments. Having some >notion of locality is important and not always easily available on >first use. Why not? The way this works in DNS is usually on the base of source port. A DoH server knows that, too, no? Or is the worry that I have a DoH server configured and it doesn't know about my network? How is that different from today, if I configure "my own" resolver? If you configure 8.8.8.8 on your laptop and take it into your example.com corporate network, then "floor1printer.example.com" is also unlikely to work, right? I think it is useful to note this, but unless the idea is that every resolver has knowledge of every possible context (plainly, an impossible goal), then this is going to be a constant problem I think. I think Olafur was making this point in the driu BoF: this was a big part of a problem in MIF, and that WG's approach didn't fully solve it. I suspect that the non-solution had to do with the basic impossiblity of solving this completely generally in an internet-compatible way. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jul 20 06:55:12 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 A2326131179 for ; Fri, 20 Jul 2018 06:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 kfpGLzt0pChw for ; Fri, 20 Jul 2018 06:55:05 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id A2000130F49 for ; Fri, 20 Jul 2018 06:55:05 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id BFBD13A03D for ; Fri, 20 Jul 2018 09:55:02 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id l10-v6so21496576oii.0 for ; Fri, 20 Jul 2018 06:55:02 -0700 (PDT) X-Gm-Message-State: AOUpUlEzbYMtT1YFVkpHDfWNsqD17E+PjLHlBVRX+4f6iuehEYhDfKPV xKYrmLX6FsZAL9s7SXRm201ET3K9JwlRfHl2zp4= X-Google-Smtp-Source: AAOMgpf8/16klbcY+IdNJvry3sfY/qIk6XoIVi49v6yIMToNMjutCcSqGoNQnA9FKwCBwnvzOKbpg7R2YKLhQ/tQdeQ= X-Received: by 2002:aca:e80c:: with SMTP id f12-v6mr2357606oih.38.1532094902454; Fri, 20 Jul 2018 06:55:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 06:55:01 -0700 (PDT) In-Reply-To: References: <153192232867.2882.433616342941784102.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Fri, 20 Jul 2018 09:55:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000006c5bd305716ea42b" Archived-At: Subject: Re: [Doh] New Version Notification for draft-dickinson-doh-dohpe-00.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 13:55:10 -0000 --0000000000006c5bd305716ea42b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sara, Willem, interesting draft. I have two, perhaps slightly inconsistent, high level thoughts and then a bunch of routine technical comments. 1] The draft is pretty honest that what it really wants in its heart is an HTTP tunnel to carry 7858 in. Implementations that desire that should probably just do that via CONNECT - the procedure is well specified already. Even the reason offered up for not doing so (Content-Negotiation) cannot be done in a way consistent with the rest of the document (it requires incremental deployment of Accept request headers as new formats are deployed). 2] I think HTTPbis should consider this work right now. We added some text to BCP56bis based on our previous discussions, but something directly in the http-core work (which is a bis effort for 723x) could be much more detailed and helpful. http-core is an adopted work item of HTTPbis that is already a suite of documents, so whether it was a new document as part of that or text within an existing one is pretty much just editorial. Obviously the content of that output is determined by the WG (and eventually the whole IETF), but I think it would be well received. The content of your draft (perhaps modulo the padding issue) is equally relevant to any use of web services as it is to doh, so relevant review by the HTTP community seems paramount. I would be happy to work with you on it in that forum. OK - the smaller stuff: 3.1. this requirement doesn't really consider the possibility that resolver choices are not equal - even from a privacy standpoint 3.2 this requirement may, as martin noted, result in weaker defense against traffic analysis, and it might also result in more connections (for either doh or for regular web) which probably have secondary leaks in the form of sni or ocsp. this may not actually be a good idea if you are trading off endpoint privacy against network privacy when the endpoiint can already do correlation at the transport layer. 3.3 bcp56bis says don't enforce a minimum version so you run afoul of that (core-doh makes this a should and lays out the reasons).. but if a doc says >=3D h2, rather than =3D=3D h2 it won't succeed in normalizing things for v= ery long anyhow as new versions come along. 3.5.1 normalizing user-agent to anything other than null is probably a bad idea. The use of that field is for debugging and working around implementation bugs - so if different implementations claim to be the same thing it won't be effective. Empty is ok from that pov though you obviously lose that feature of the ecosystem (which is widely used). but there is so much else to think about in fingerprinting an h2 implementation. I'm not optimistic its solvable. * priority schemes * flow control crediting behavior * settings values: max streams, windows, push, extensions * stream id selection * header encoding (hpack) choices -- I 'm sure there are many more. I know I can easily play a game of "name that implementation" when looking at most traces. Focusing on the user fingerprinting problem instead of the implementation may be a more tractable thing. I suppose the doc could just declare things below the semantic layer out of scope, as it seems to have done for tls, tcp, and ip, but it runs the risk of defining something that can't be deployed to gain its intended benefit. I actually think that line has already been crossed by not addressing layers below http. In any event, even this scope is 95% http rather than doh imo. Cheerfully, -P On Wed, Jul 18, 2018 at 10:02 AM, Sara Dickinson wrote: > Hi All, > > We=E2=80=99ve just submitted a very short draft outlining a privacy profi= le for > DoH called DoHPE. > > It is very basic at the moment but it would be great to get some feedback > on the idea here and to see if the WG sees this as something that should = go > through this group or head somewhere else. Since the guidelines are purel= y > HTTP related, this does feel like the right audience to review the docume= nt > at least in the first instance. > > Sara. > > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for draft-dickinson-doh-dohpe-00.txt= * > *Date: *18 July 2018 at 09:58:48 GMT-4 > *To: *"Sara Dickinson" , "Willem Toorop" < > willem@nlnetlabs.nl> > > > A new version of I-D, draft-dickinson-doh-dohpe-00.txt > has been successfully submitted by Sara Dickinson and posted to the > IETF repository. > > Name: draft-dickinson-doh-dohpe > Revision: 00 > Title: DoHPE: DoH with Privacy Enhancements > Document date: 2018-07-18 > Group: Individual Submission > Pages: 8 > URL: https://www.ietf.org/internet-drafts/draft- > dickinson-doh-dohpe-00.txt > Status: https://datatracker.ietf.org/doc/draft-dickinson- > doh-dohpe/ > Htmlized: https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft- > dickinson-doh-dohpe > > > Abstract: > This document describes DoHPE (DoH with Privacy Enhancements) - a > privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] > clients. The profile provides guidelines on the composition of DoH > messages, designed to minimize disclosure of identifying information. > > > > > 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. > > The IETF Secretariat > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --0000000000006c5bd305716ea42b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sara, Willem, interesting draft. I have two, perha= ps slightly inconsistent, high level thoughts and then a bunch of routine t= echnical comments.

1] The draft is pretty honest t= hat what it really wants in its heart is an HTTP tunnel to carry 7858 in. I= mplementations that desire that should probably just do that via CONNECT - = the procedure is well specified already. Even the reason offered up for not= doing so (Content-Negotiation) cannot be done in a way consistent with the= rest of the document (it requires incremental deployment of Accept request= headers as new formats are deployed).

2] I think = HTTPbis should consider this work right now. We added some text to BCP56bis= based on our previous discussions, but something directly in the http-core= work (which is a bis effort for 723x) could be much more detailed and help= ful. http-core is an adopted work item of HTTPbis that is already a suite o= f documents, so whether it was a new document as part of that or text withi= n an existing one is pretty much just editorial. Obviously the content of t= hat output is determined by the WG (and eventually the whole IETF), but I t= hink it would be well received.

The content of you= r draft (perhaps modulo the padding issue) is equally relevant to any use o= f web services as it is to doh, so relevant review by the HTTP community se= ems paramount. I would be happy to work with you on it in that forum.
=

OK - the smaller stuff:

3.1. t= his requirement doesn't really consider the possibility that resolver c= hoices are not equal - even from a privacy standpoint

3.2 this requirement may, as martin noted, result in weaker defense= against traffic analysis, and it might also result in more connections (fo= r either doh or for regular web) which probably have secondary leaks in the= form of sni or ocsp. this may not actually be a good idea if you are tradi= ng off endpoint privacy against network privacy when the endpoiint can alre= ady do correlation at the transport layer.

3.3 bcp= 56bis says don't enforce a minimum version so you run afoul of that (co= re-doh makes this a should and lays out the reasons).. but if a doc says &g= t;=3D h2, rather than =3D=3D h2 it won't succeed in normalizing things = for very long anyhow as new versions come along.

3.5.1 normalizing user-agent to anything other than null is probably a b= ad idea. The use of that field is for debugging and working around implemen= tation bugs - so if different implementations claim to be the same thing it= won't be effective. Empty is ok from that pov though you obviously los= e that feature of the ecosystem (which is widely used).

but there is so much else to think about in fingerprinting an h2 impl= ementation. I'm not optimistic its solvable.

*= priority schemes
* flow control crediting behavior
* s= ettings values: max streams, windows, push, extensions
* stream i= d selection
* header encoding (hpack) choices

<= /div>
-- I 'm sure there are many more. I know I can easily play a = game of "name that implementation" when looking at most traces. F= ocusing on the user fingerprinting problem instead of the implementation ma= y be a more tractable thing. I suppose the doc could just declare things be= low the semantic layer out of scope, as it seems to have done for tls, tcp,= and ip, but=C2=A0 it runs the risk of defining something that can't be= deployed to gain its intended benefit. I actually think that line has alre= ady been crossed by not addressing layers below http.

In any event, even this scope is 95% http rather than doh imo.

Cheerfully,
-P

=




=





On Wed, Jul 18, 2018 at 10:= 02 AM, Sara Dickinson <sara@sinodun.com> wrote:
Hi All,=C2=A0

We=E2=80=99ve just submitted a = very short draft outlining a privacy profile for DoH called DoHPE.

It is very basic at the moment but it would be great to ge= t some feedback on the idea here and to see if the WG sees this as somethin= g that should go through this group or head somewhere else. Since the guide= lines are purely HTTP related, this does feel like the right audience to re= view the document at least in the first instance.=C2=A0

Sara.=C2=A0


Begin forwarded message:

Subject: New Version Notification for draft-= dickinson-doh-dohpe-00.txt
Date: 18 July 2018 at 09:58:48 GMT-4
To: "Sara Dickinson" <sara@sinodun.com>, "Willem Toorop" <willem@nlnetlabs.nl= >


A new version of I-D, draft-dickinso= n-doh-dohpe-00.txt
has been successfully submitted by Sara Dickinso= n and posted to the
IETF repository.

Name: draft-dickinson-doh-dohpe
Revision: 00
Tit= le: DoHPE: DoH with Privacy EnhancementsDocument date: 2018-07-18
Group: Individual Submission
Pages: 8
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0https://www.ietf.org/internet-drafts/dr= aft-dickinson-doh-dohpe-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/do= c/draft-dickinson-doh-dohpe/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0https://tools.ietf.org/html/draft-dickinson-do= h-dohpe-00
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/html/draft-dickinso= n-doh-dohpe


Abstract:
=C2=A0=C2=A0This document describe= s DoHPE (DoH with Privacy Enhancements) - a
=C2=A0=C2=A0privacy and ano= nymity profile for DoH [I-D.ietf-doh-dns-over-https]
=C2=A0=C2=A0client= s.=C2=A0 The profile provides guidelines on the composition of DoH
=C2= =A0=C2=A0messages, designed to minimize disclosure of identifying informati= on.




Please note that it may take a couple of minutes fro= m the time of submission
until the htmlized version and diff are availab= le at tools.ietf.org.

The IETF Secretariat



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


--0000000000006c5bd305716ea42b-- From nobody Fri Jul 20 08:08:59 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 ABA24130DCC for ; Fri, 20 Jul 2018 08:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Kfm44ZQ9nLGU for ; Fri, 20 Jul 2018 08:08:55 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 46D5E130F3A for ; Fri, 20 Jul 2018 08:08:54 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id 54DB952AB72; Fri, 20 Jul 2018 15:08:54 +0000 (UTC) Date: Fri, 20 Jul 2018 15:08:54 +0000 From: dagon To: Andrew Sullivan Cc: George Michaelson , Patrick McManus , DoH WG , Ted Lemon Message-ID: <20180720150854.GB22247@sudo.sh> References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:08:58 -0000 On Thu, Jul 19, 2018 at 08:50:59PM -0400, Andrew Sullivan wrote: > Sure. But none of this is unique to DoH, is it? Locally served zones rely on what might be described as a small layering violation. That is, knowledge of the stub's IP differentiates the zone used in reply. L3 informs the L7 answer. So-called "Eenterprise DOH" servers inherits this layering issue. But it also hands the DOH resolver a second problem, inherent in the DOH client. There appears to be no way to differentiate organic DOH queries (generated by a DOH client such as a browser) from induced queries generated by a soup of js document.write() calls and similar strategies. For global DOH resolvers, this problem is easy, since they are unlikely to offer local zones. Global DOH operators can elect to filter *.in-addr.arpa queries, as perhaps categorically unlikely to be created by any known DOH client, Or they can answer, to ensure DOH clouds are full DNS speakers, and provide a faithful duplicate of traditional DNS resolution, all without revealing internal network information. Enterprise DOH, particularly those offering local zones, have to come up with a strategy that does not allow induced crawls of internal hosts. One might think ECS could be helpful, but consider that in most cases, the DOH client rendering a spiteful HTML/js page will be inside the local network. If anything, ECS merely increases the harm, as the scope and mask information will inevitably be leaked back to the site generating the DOH query by javascript. Perhaps instead HTTP header properites can help, since they could indicate what remote site prompted the DOH queries. For example, enterprise DOH servers and cloud DOH resolvers might use this, to manage scrapes and crawls from botnets, ad farms, and the like. (In an older post to this list, I raised this issue, perhaps too forcefully to be appreciated.) Back to the HTTP header filtration solution: assume malicious-ad.example.com would be tagged in the DOH header, as the true origin of a query for *.168.192.in-addr.arpa. The enterprise DOH server could intervene with policy for such queries (RCODE=5, or an analog in HTTP), and allow queries for *.168.192.in-addr.arpa if the DOH http headers indicate the upstream query came from, say, ceo.example.net. A similar approach could rely on a user-agent encoding used by the DOH client sub, but the Dickinson & Toorop draft currently states: 3.5.1. User agent DoHPE clients SHOULD omit the user-agent header. DoHPE clients MAY set this header to 'DoHPE client' The more mature Hoffman and McManus draft says this: Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale. This facilitates content negotiation and operational work- arounds for implementation bugs. Request header fields that control caching can expose state information about a subset of the client's history. Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. I don't know what the phrase "richer data corrleation" means, but perhaps it has some security properties as well. In any event, assume some header information (an origin, or user agent) is used by the enterprise DOH server to filter organic DOH queries versus induced crawls. This might be useful, but now the historically small "layering violation" (perhaps that's too harsh a description) used to handle local zones in DNS, now must become much larger, and include information about the L7 application that prompted the DOH query. (I.e., L3/L7 mixing, long tolerated in DNS for local zone management, now becomes L3+L7/L7.) One drawback to a header-fix is that it requires strict whitelist-only discipline. In an enterprise, the DOH deployment likely now involves a separate web team, on top of the network and security groups responsible for safe deployment. A second drawback is that this assumes no further manipulations of the HTML, beyond naive javascript document.write() calls. There's a healthy industry of extraordinarly talented penatration testers who will ensure that all probes of the local zone appear to originate from ceo.example.net, or some other whitelisted source, and that the user agent matches, if required. The problems I've identified so far assume an ideal enterprise DOH deployment. Yes, local zones are a problem, and perhaps there are some solutions. But let's also not ignore self-inflicted wounds. The long tail of low-end HTTP proxy vendors will no doubt soon see a spike in their traffic, investigate to discover the volume is attributable to DOH, and motivated by a basic desire to sell a new module or be feature-competitive, include a poorly architected DOH handler. "DJB DOH" will be offered, somehwere, by a vendor who understands marketing, but neither DNS or HTTP well. Others will see DOH destined for Cloudflare, redirect the query to a local DOH resolver created by the intern, and point to the reduced latency. These and other bad choices seem not only probable, but inevitable. I am preparing a set of test cases, using a hypothetical NGO, to be scanned by hypothetical hackers from the Freednian government, to fully illustrate the malicious uses of DOH. It seems like local zones will become public via local DOH, unless someone has a clever fix. It seems prudent to discuss this in some form in a protocol, if only to caution against obviously bad DOH enterprise models. Then again, this list is public, and "someone told you so", might be an adequate response to a proxy-turned-DOH vendor who hands over local zone details to an anonymous adversary. I caution the concerns I've raised have only been briefly tested. I may have even more concerns to raise, and also apologize if my whiteboard-quality comments are not sufficiently clear. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Fri Jul 20 08:10: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 8B8711310AC for ; Fri, 20 Jul 2018 08:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-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=algebras-org.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 2r0WjHoUDGht for ; Fri, 20 Jul 2018 08:10:06 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::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 8F66C130DCC for ; Fri, 20 Jul 2018 08:10:06 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f21-v6so9826154wmc.5 for ; Fri, 20 Jul 2018 08:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fjIEkkE/G7XDvTzGC9QwTJggrY0qVn1DGG8M9nVisLo=; b=kESWkSpr979ibluaPGUwrA7PxIi9cSEkClPOjiB2+PFCaKD5Cs2zZv4ZjsXyT0auXH JA0vgyX/8WSOU8/rqPXmkLs0JBXzotSfuZe6bQpO0Ha+T6Oq6sfaQIlLFjDqabI7Cv0o 3SdQyCICUjrsmjIcECholQ92D6zZkffKLQjMlL3cIP/XhwVVHiVmgpEu2Rmfo82oyvSB W0hR2OzJROfnarf5VPFV41DrKDnC4i7/TCwx/T7YSwhsx/ZS7uCPNS18KD2R2tgY/yL6 FLljXN0b+0asR3KpkBoZtB7iENzbNg2CsQcxUDhWPlfmVseJfaeII/A+wrSUfMmozIwX LzYQ== 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=fjIEkkE/G7XDvTzGC9QwTJggrY0qVn1DGG8M9nVisLo=; b=N4B5O+95Ci+p8WNwg9j+2UxlrERs/E4HJ69eClYZTiiW6ZmjrQxMtEZ2Vwu50oy+fi 930KFvAb9PE2nLwoJvykKK23FY2sv3p8zxt71NrCFrXmpn6Qtb9K3ZcI7M43BtQ5PJRY MKJd1lhAg0DNaaoZLm2AcSf5hNQWa+kPjKKXi0AVcTFTQoUxoYuVUzWa0GK96/UMeoNV T9KpMFb4xeFNu7aOOtgA2IWzhgV6hADWgRKPmFlF8N96FdxDANa5CKYuSKcXeSLJajep cwRKu6BK5HilyUu6617J31fk30ZP9JDCyrlNXuAsklnCYj88J4dJSaC6wl4OIkjWqKgk tXqg== X-Gm-Message-State: AOUpUlHTvCwjXyw3UNqbYKey38UvlIMxAPNbYC+zn+yKnXyk6y2WqyCK G4Ekuy4tc3YRwoB4GOxpQRlBTpmcZR1OrPVccDukhg== X-Google-Smtp-Source: AAOMgpd2mS+O+AotX4i3pQa3xbXpH/ZOfbnaYlyg5JySBORIcGY55MbVOtTQyElSCMpJ8bX0q1kwGyvzd5RplVSUL0c= X-Received: by 2002:a1c:b6d6:: with SMTP id g205-v6mr1942197wmf.17.1532099404986; Fri, 20 Jul 2018 08:10:04 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:12cb:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 08:10:04 -0700 (PDT) X-Originating-IP: [2001:67c:370:128:5004:4f08:137d:c835] In-Reply-To: <20180720150854.GB22247@sudo.sh> References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <20180720150854.GB22247@sudo.sh> From: George Michaelson Date: Fri, 20 Jul 2018 11:10:04 -0400 Message-ID: To: dagon Cc: Andrew Sullivan , Patrick McManus , DoH WG , Ted Lemon Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 15:10:10 -0000 putting "leak of secrets" to one side, if you have DoH you have client header proffer in HTTP(S) So, we can move beyond bits in DNS, to state we carry in HTTP to signal intent and desire. But, somebody is sure to cry "won't somebody think of the secrets" On Fri, Jul 20, 2018 at 11:08 AM, dagon wrote: > On Thu, Jul 19, 2018 at 08:50:59PM -0400, Andrew Sullivan wrote: >> Sure. But none of this is unique to DoH, is it? > > Locally served zones rely on what might be described as a small > layering violation. That is, knowledge of the stub's IP differentiates > the zone used in reply. L3 informs the L7 answer. > > So-called "Eenterprise DOH" servers inherits this layering issue. > > But it also hands the DOH resolver a second problem, inherent in the > DOH client. There appears to be no way to differentiate organic DOH > queries (generated by a DOH client such as a browser) from induced > queries generated by a soup of js document.write() calls and similar > strategies. > > For global DOH resolvers, this problem is easy, since they are > unlikely to offer local zones. Global DOH operators can elect to > filter *.in-addr.arpa queries, as perhaps categorically unlikely to be > created by any known DOH client, Or they can answer, to ensure DOH > clouds are full DNS speakers, and provide a faithful duplicate of > traditional DNS resolution, all without revealing internal network > information. > > Enterprise DOH, particularly those offering local zones, have to come > up with a strategy that does not allow induced crawls of internal > hosts. One might think ECS could be helpful, but consider that in > most cases, the DOH client rendering a spiteful HTML/js page will be > inside the local network. If anything, ECS merely increases the harm, > as the scope and mask information will inevitably be leaked back to > the site generating the DOH query by javascript. > > Perhaps instead HTTP header properites can help, since they could > indicate what remote site prompted the DOH queries. For example, > enterprise DOH servers and cloud DOH resolvers might use this, to > manage scrapes and crawls from botnets, ad farms, and the like. (In > an older post to this list, I raised this issue, perhaps too > forcefully to be appreciated.) > > Back to the HTTP header filtration solution: assume > malicious-ad.example.com would be tagged in the DOH header, as the > true origin of a query for *.168.192.in-addr.arpa. The enterprise DOH > server could intervene with policy for such queries (RCODE=5, or an > analog in HTTP), and allow queries for *.168.192.in-addr.arpa if the > DOH http headers indicate the upstream query came from, say, > ceo.example.net. A similar approach could rely on a user-agent > encoding used by the DOH client sub, but the Dickinson & Toorop > draft currently states: > > 3.5.1. User agent > DoHPE clients SHOULD omit the user-agent header. DoHPE clients MAY > set this header to 'DoHPE client' > > The more mature Hoffman and McManus draft says this: > > Additionally, the User-Agent and Accept-Language request header > fields often convey specific information about the client version > or locale. This facilitates content negotiation and operational > work- arounds for implementation bugs. Request header fields that > control caching can expose state information about a subset of the > client's history. Mixing DoH requests with other HTTP requests on > the same connection also provides an opportunity for richer data > correlation. > > I don't know what the phrase "richer data corrleation" means, but > perhaps it has some security properties as well. In any event, assume > some header information (an origin, or user agent) is used by the > enterprise DOH server to filter organic DOH queries versus induced > crawls. This might be useful, but now the historically small > "layering violation" (perhaps that's too harsh a description) used to > handle local zones in DNS, now must become much larger, and include > information about the L7 application that prompted the DOH query. > (I.e., L3/L7 mixing, long tolerated in DNS for local zone management, > now becomes L3+L7/L7.) > > One drawback to a header-fix is that it requires strict whitelist-only > discipline. In an enterprise, the DOH deployment likely now involves > a separate web team, on top of the network and security groups > responsible for safe deployment. > > A second drawback is that this assumes no further manipulations of the > HTML, beyond naive javascript document.write() calls. There's a > healthy industry of extraordinarly talented penatration testers who > will ensure that all probes of the local zone appear to originate from > ceo.example.net, or some other whitelisted source, and that the user > agent matches, if required. > > The problems I've identified so far assume an ideal enterprise DOH > deployment. Yes, local zones are a problem, and perhaps there are > some solutions. But let's also not ignore self-inflicted wounds. > > The long tail of low-end HTTP proxy vendors will no doubt soon see a > spike in their traffic, investigate to discover the volume is > attributable to DOH, and motivated by a basic desire to sell a new > module or be feature-competitive, include a poorly architected DOH > handler. "DJB DOH" will be offered, somehwere, by a vendor who > understands marketing, but neither DNS or HTTP well. Others will see > DOH destined for Cloudflare, redirect the query to a local DOH > resolver created by the intern, and point to the reduced latency. > > These and other bad choices seem not only probable, but inevitable. I > am preparing a set of test cases, using a hypothetical NGO, to be > scanned by hypothetical hackers from the Freednian government, to > fully illustrate the malicious uses of DOH. It seems like local zones > will become public via local DOH, unless someone has a clever fix. > > It seems prudent to discuss this in some form in a protocol, if only > to caution against obviously bad DOH enterprise models. Then again, > this list is public, and "someone told you so", might be an adequate > response to a proxy-turned-DOH vendor who hands over local zone > details to an anonymous adversary. > > I caution the concerns I've raised have only been briefly tested. I > may have even more concerns to raise, and also apologize if my > whiteboard-quality comments are not sufficiently clear. > > -- > David Dagon > dagon@sudo.sh > D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Fri Jul 20 11:06: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 5619C130E16 for ; Fri, 20 Jul 2018 11:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Bve0OaLbpEoT for ; Fri, 20 Jul 2018 11:06:25 -0700 (PDT) Received: from sudo.sh (hexakaideca.sudo.sh [198.177.251.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD78130DE7 for ; Fri, 20 Jul 2018 11:06:20 -0700 (PDT) Received: by sudo.sh (Postfix, from userid 1000) id B0B5257CB4B; Fri, 20 Jul 2018 18:06:19 +0000 (UTC) Date: Fri, 20 Jul 2018 18:06:19 +0000 From: dagon To: George Michaelson Cc: DoH WG , Ted Lemon , Patrick McManus , Andrew Sullivan Message-ID: <20180720180619.GA3446@sudo.sh> References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <20180720150854.GB22247@sudo.sh> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:06:28 -0000 On Fri, Jul 20, 2018 at 11:10:04AM -0400, George Michaelson wrote: > putting "leak of secrets" to one side, if you have DoH you have client > header proffer in HTTP(S) > > So, we can move beyond bits in DNS, to state we carry in HTTP to > signal intent and desire. > > But, somebody is sure to cry "won't somebody think of the secrets" I'm not arguing against engineering a new lawn dart. I'm merely suggesting some safety instructions. DOH was designed to be a substitute for traditional DNS. But there are circumstances, such as local zones, that present operator hazards. Considerations: -- Should cloud DOH answer reverse queries? Or only answer a handful of common forward types? The harm here seems annoyance of the cloud DNS operator, as well as the use of advertising tools to conduct global DNS scanning from unwitting third parties. -- Should or must DOH client implementations somehow identify their organic queries via header proprities, or the site inducing the DNS message over http? The harm here is the enumeration of local networks, by malicious remote site owners. -- Should edge/enterprise DOH also serve local zones? Same. -- Should ECS be turned off or dropped (or default zero scope) in edge/enterpise networks, or operate under the scope and mask properties set by the local network? The harm here is the enrichment of the data set to remote site operators, detailing internal network allocations. -- Should http proxies redirect DOH queries, away from cloud DNS? The use of cloud DNS is an audit criticism in enterprise network evaluation. Some might think redirecting the DOH volume to an internal server solves this problem. It instead would expose the local network information to remote sites, as noted. We of course don't have to consider these. There is an argument, as you seem to suggest, for a strictly utilitarian model of a protocol description: coder beware. Still others view lawn darts as profitable, as well as their injuries. Prudent advice, in the form of considerations in the draft, might help those implementing DOH to appreciate the design choices they'll encounter. -- David Dagon dagon@sudo.sh D970 6D9E E500 E877 B1E3 D3F8 5937 48DC 0FDC E717 From nobody Fri Jul 20 11:29: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 E84BA13121D for ; Fri, 20 Jul 2018 11:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 vGvv48I2u-Ey for ; Fri, 20 Jul 2018 11:29:20 -0700 (PDT) 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 39C061311A2 for ; Fri, 20 Jul 2018 11:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1532111359; x=1533320959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cF0BzkB+m5D4AstYY/Hj0sKT+8Z2w61DvEC9Gj0jNyA=; b=BFOqI7g8v5NunIwqBhdTvQZoS7in3/1wHFjOGaV2iyufd5CI0Godbn9/ S2EBH/QmVzV11hXtR0edhihMm9Ggd16skTeJbF9cHJqt0ck0T1Nam4RnP Txu/ObKs+Y5/h6eDCpf4kz44+kj38PwZSlqCC+PmKxqA1DvLa6RonPp2k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAQBZKVJb/51dJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMjKmN/KIN+iASMMoFoJIM4kgSBegsYC4RJAheCdSE0GAE?= =?us-ascii?q?CAQECAQECbRwMhTYBAQEBAgEBASEROgsFCwIBCA4KAgImAgICJQsVEAIEDgU?= =?us-ascii?q?bgwUBgXcID6tjgS6KVIELh3eBVz+BOAyCMC6DGQEBgUqDFzGCJAKZbAkChg+?= =?us-ascii?q?JHwKBQ0OGPYUtkXoCERSBJB04gVJwFTsqAYI+CYMtAQ6CPIUUhT5vjSMBAQ?= X-IronPort-AV: E=Sophos;i="5.51,380,1526342400"; d="scan'208";a="416311615" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Jul 2018 18:29:18 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id w6KITIbR015808 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jul 2018 18:29:18 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 20 Jul 2018 13:29:17 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Fri, 20 Jul 2018 13:29:17 -0500 From: "Eliot Lear (elear)" To: Andrew Sullivan CC: "doh@ietf.org" Thread-Topic: [Doh] Locally served zones in DoH Thread-Index: AQHUH7QWiTIEabhpMkqkRCkDDDHCjKSXfd4AgAABGoCAAAHagIAAGpeAgAAAc4CAAApWgIAAFtmA///XmWKAAM79gIAADBm5 Date: Fri, 20 Jul 2018 18:29:17 +0000 Message-ID: <81999366-2009-4F74-B9B7-6BEA1930296B@cisco.com> References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> , <20180720124559.GA1029@mx4.yitter.info> In-Reply-To: <20180720124559.GA1029@mx4.yitter.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:29:34 -0000 Rm9yZ2l2ZSB0aGUgY2VsbCBwaG9uZSB0b3AgcG9zdGluZywgYnV0IEkgdGhpbmsgdGhlIHN1Z2dl c3Rpb24gaXMgdG8gbm90ZSB0aGUgaXNzdWUuICBJIGRvbuKAmXQgdGhpbmsgSSByZWFkIGFueW9u ZSBzdWdnZXN0aW5nIGRlbHZpbmcgaW50byBzb2x1dGlvbnMuIFRoZSByZWFzb24gaXQgY2FuIGJl IHRyaWNreSBpcyB0aGF0IGxvY2FsaXR5IGNhbiBpbnZvbHZlIG11bHRpcGxlIGdyb3VwcyBvZiBu ZXR3b3JrcyBhbmQgbXVsdGlwbGUgZG9tYWlucy4gVGhpcyBpcyBxdWl0ZSB0eXBpY2FsIGluIGxh cmdlIG9yZ2FuaXphdGlvbnMuIA0KDQpFbGlvdA0KDQo+IE9uIEp1bCAyMCwgMjAxOCwgYXQgMDg6 NDYsIEFuZHJldyBTdWxsaXZhbiA8YWpzQGFudmlsd2FscnVzZGVuLmNvbT4gd3JvdGU6DQo+IA0K Pj4gT24gRnJpLCBKdWwgMjAsIDIwMTggYXQgMDU6MjU6MDlBTSArMDAwMCwgRWxpb3QgTGVhciAo ZWxlYXIpIHdyb3RlOg0KPj4gVGhhdCBpdOKAmXMgbm90IHVuaXF1ZSB0byBkb2ggZG9lc27igJl0 IG1lYW4gaXQgaXNu4oCZdCBhIHByb2JsZW0uDQo+IA0KPiBXZWxsLCB5ZXMsIG9idmlvdXNseSwg YnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgUkZDIDYzMDMgaXNuJ3QgYQ0KPiBjb25zaWRlcmF0 aW9uIGhlcmUuDQo+IA0KPiBEb0ggc2VydmVycyBzZXJ2ZSBETlMgZGF0YSwgYW5kIGNvbnNpZGVy YXRpb25zIGFib3V0IHRoZSBkYXRhIHNlcnZlcnMNCj4gYXJlIHN1cHBvc2VkIHRvIHNlcnZlIGFw cGx5IGVxdWFsbHkgdG8gdGhlbSBhcyB0byBhbnkgb3RoZXINCj4gRE5TLXNlcnZpbmcgc2VydmVy LCBJIHRoaW5rLiAgSXNuJ3QgdGhhdCBlbm91Z2ggdG8gc2F5Pw0KPiANCj4+IEJ1dCBJ4oCZbSBz dXJlIHRoYXQgYWJzZW50IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gaXQgd2lsbCBtZWFuIHBlb3Bs ZQ0KPj4gaGF2aW5nIHRvIHR1cm4gZG9oIG9mZiBpbiBzcGxpdCBob3Jpem9uIGVudmlyb25tZW50 cy4gSGF2aW5nIHNvbWUNCj4+IG5vdGlvbiBvZiBsb2NhbGl0eSBpcyBpbXBvcnRhbnQgYW5kIG5v dCBhbHdheXMgZWFzaWx5IGF2YWlsYWJsZSBvbg0KPj4gZmlyc3QgdXNlLg0KPiANCj4gV2h5IG5v dD8gIFRoZSB3YXkgdGhpcyB3b3JrcyBpbiBETlMgaXMgdXN1YWxseSBvbiB0aGUgYmFzZSBvZiBz b3VyY2UNCj4gcG9ydC4gIEEgRG9IIHNlcnZlciBrbm93cyB0aGF0LCB0b28sIG5vPw0KPiANCj4g T3IgaXMgdGhlIHdvcnJ5IHRoYXQgSSBoYXZlIGEgRG9IIHNlcnZlciBjb25maWd1cmVkIGFuZCBp dCBkb2Vzbid0DQo+IGtub3cgYWJvdXQgbXkgbmV0d29yaz8gIEhvdyBpcyB0aGF0IGRpZmZlcmVu dCBmcm9tIHRvZGF5LCBpZiBJDQo+IGNvbmZpZ3VyZSAibXkgb3duIiByZXNvbHZlcj8gIElmIHlv dSBjb25maWd1cmUgOC44LjguOCBvbiB5b3VyIGxhcHRvcA0KPiBhbmQgdGFrZSBpdCBpbnRvIHlv dXIgZXhhbXBsZS5jb20gY29ycG9yYXRlIG5ldHdvcmssIHRoZW4NCj4gImZsb29yMXByaW50ZXIu ZXhhbXBsZS5jb20iIGlzIGFsc28gdW5saWtlbHkgdG8gd29yaywgcmlnaHQ/DQo+IA0KPiBJIHRo aW5rIGl0IGlzIHVzZWZ1bCB0byBub3RlIHRoaXMsIGJ1dCB1bmxlc3MgdGhlIGlkZWEgaXMgdGhh dCBldmVyeQ0KPiByZXNvbHZlciBoYXMga25vd2xlZGdlIG9mIGV2ZXJ5IHBvc3NpYmxlIGNvbnRl eHQgKHBsYWlubHksIGFuDQo+IGltcG9zc2libGUgZ29hbCksIHRoZW4gdGhpcyBpcyBnb2luZyB0 byBiZSBhIGNvbnN0YW50IHByb2JsZW0gSQ0KPiB0aGluay4NCj4gDQo+IEkgdGhpbmsgT2xhZnVy IHdhcyBtYWtpbmcgdGhpcyBwb2ludCBpbiB0aGUgZHJpdSBCb0Y6IHRoaXMgd2FzIGEgYmlnDQo+ IHBhcnQgb2YgYSBwcm9ibGVtIGluIE1JRiwgYW5kIHRoYXQgV0cncyBhcHByb2FjaCBkaWRuJ3Qg ZnVsbHkgc29sdmUNCj4gaXQuICBJIHN1c3BlY3QgdGhhdCB0aGUgbm9uLXNvbHV0aW9uIGhhZCB0 byBkbyB3aXRoIHRoZSBiYXNpYw0KPiBpbXBvc3NpYmxpdHkgb2Ygc29sdmluZyB0aGlzIGNvbXBs ZXRlbHkgZ2VuZXJhbGx5IGluIGFuDQo+IGludGVybmV0LWNvbXBhdGlibGUgd2F5Lg0KPiANCj4g QQ0KPiANCj4gLS0gDQo+IEFuZHJldyBTdWxsaXZhbg0KPiBhanNAYW52aWx3YWxydXNkZW4uY29t DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBEb2ggbWFpbGluZyBsaXN0DQo+IERvaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RvaA0K From nobody Mon Jul 23 05:39:35 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 DE700130DED for ; Mon, 23 Jul 2018 05:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham 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 pqA_j2aInJNh for ; Mon, 23 Jul 2018 05:39:30 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 4DE36130DE1 for ; Mon, 23 Jul 2018 05:39:30 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id h23-v6so1066891ita.5 for ; Mon, 23 Jul 2018 05:39:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgbHJj1UUR+L/B3+8jFJxqCFlmwlWTEU6ZKSKT0vAeY=; b=KmcAchRzEKwU4B9TuQ/wGHsmobAGSpHsyClnzacEPcIdB53oyjI4GC/i4MYxqVafno G2n8k6Zsw78faLCrQHyjzS24S8CxVipM0gBQa2SYcJ2jQJlBOc7fTVEWgp9zDa/2ln+z x98HXTkyfCmehcJQXql/3dTqG26itpQYco5CU58M5J5bQ5/9MDSdakYUF9MW65RoFhiX jesnPgnVc+IoOn4sWC8ZBajpPPYNm02sUAf/CQK1H8sEW+d2tPL9jwq9eivlIjcpH2Sp GXNL8fbFKySDfDm6rPgr7NqENFkYDOSqPy6OupNwE5+RyWijjFZWjIOlKjAiPKs4Zcfj Nb6A== 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=zgbHJj1UUR+L/B3+8jFJxqCFlmwlWTEU6ZKSKT0vAeY=; b=g2sqVzS0YXdRYhikR8661G5YtZZvkDjwTkBDujf3aqtrqTumnwNTqdQ4w4rtCLMYMP eEvCtlhnD2As+i79oV76MgO12RrcqH9seehQ04V0wmiHhZ9yvTZG1ASJWCbClUOHd194 TmlK+uHKQP2cuH7P1eKT1ptb7u+eLoBA5wlCtKynzRrIWnnskfvuybkkhHxMJsn8ooI+ zK7jE9Ctb4T+jCmpsEmbJgVGk8Xu3dpnAl/pSmdVqPOZdnxK9O8DDwTherEC09CKkjQD kncvlBqLfbeflrSg5BWXuEZkHoyJ416ady2ATSbLUCHFSkhsD+kmvQ2vcOs/SDig1UPw 0liA== X-Gm-Message-State: AOUpUlEKJiPFDQe+qn01LN46tTznfFtb0ehesKnX1yZwZb6pqS6LG0tR iMkpaUMKtuR9Zd0wBfC/vR5H8YNug/1BEa7RBTZqmgY+ X-Google-Smtp-Source: AAOMgpfSQ4wlLK04hEzM0VZC47YxBxkqmmNRKkdmtrUs6Lt5y4uV0JDGm1+qDx0ZZge36EQ+SyP7wgGEl5awKLGxHWs= X-Received: by 2002:a24:8a85:: with SMTP id v127-v6mr10341935itd.98.1532349568707; Mon, 23 Jul 2018 05:39:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 05:38:48 -0700 (PDT) In-Reply-To: <81999366-2009-4F74-B9B7-6BEA1930296B@cisco.com> References: <20180719230338.GF21643@mx4.yitter.info> <164b52b1d38.2772.55b9c0b96417b0a70c4dcaded0d2e1c6@anvilwalrusden.com> <20180720124559.GA1029@mx4.yitter.info> <81999366-2009-4F74-B9B7-6BEA1930296B@cisco.com> From: Ted Lemon Date: Mon, 23 Jul 2018 08:38:48 -0400 Message-ID: To: "Eliot Lear (elear)" Cc: Andrew Sullivan , "doh@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b705e70571a9ef9a" Archived-At: Subject: Re: [Doh] Locally served zones in DoH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 12:39:34 -0000 --000000000000b705e70571a9ef9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Correct, Eliot. What I would like to see is it clearly stated that if a DoH resolver doesn't have some kind of bypass for locally-served zones, the end user will not have access to those zones, and this will likely cause operational problems which the user will be unprepared to diagnose. As someone pointed out, existing resolvers configured to use 8.8.8.8 have this same problem, so it is not unique to DoH. This is just an opportunity to raise awareness of the issue, and I think it's worth doing. I think something along the lines of treating the local network as a separate PvD (RFC 7556) might work, but is out of scope for this document. BTW, separately, I think sending information to a generic DoH server about which web page triggered a DNS query is a bad idea. On Fri, Jul 20, 2018 at 2:29 PM, Eliot Lear (elear) < elear=3D40cisco.com@dmarc.ietf.org> wrote: > Forgive the cell phone top posting, but I think the suggestion is to note > the issue. I don=E2=80=99t think I read anyone suggesting delving into s= olutions. > The reason it can be tricky is that locality can involve multiple groups = of > networks and multiple domains. This is quite typical in large > organizations. > > Eliot > > > On Jul 20, 2018, at 08:46, Andrew Sullivan > wrote: > > > >> On Fri, Jul 20, 2018 at 05:25:09AM +0000, Eliot Lear (elear) wrote: > >> That it=E2=80=99s not unique to doh doesn=E2=80=99t mean it isn=E2=80= =99t a problem. > > > > Well, yes, obviously, but I don't understand how RFC 6303 isn't a > > consideration here. > > > > DoH servers serve DNS data, and considerations about the data servers > > are supposed to serve apply equally to them as to any other > > DNS-serving server, I think. Isn't that enough to say? > > > >> But I=E2=80=99m sure that absent additional information it will mean p= eople > >> having to turn doh off in split horizon environments. Having some > >> notion of locality is important and not always easily available on > >> first use. > > > > Why not? The way this works in DNS is usually on the base of source > > port. A DoH server knows that, too, no? > > > > Or is the worry that I have a DoH server configured and it doesn't > > know about my network? How is that different from today, if I > > configure "my own" resolver? If you configure 8.8.8.8 on your laptop > > and take it into your example.com corporate network, then > > "floor1printer.example.com" is also unlikely to work, right? > > > > I think it is useful to note this, but unless the idea is that every > > resolver has knowledge of every possible context (plainly, an > > impossible goal), then this is going to be a constant problem I > > think. > > > > I think Olafur was making this point in the driu BoF: this was a big > > part of a problem in MIF, and that WG's approach didn't fully solve > > it. I suspect that the non-solution had to do with the basic > > impossiblity of solving this completely generally in an > > internet-compatible way. > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > > > _______________________________________________ > > 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 > --000000000000b705e70571a9ef9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Correct, Eliot.=C2=A0 =C2=A0What I would like to see is it= clearly stated that if a DoH resolver doesn't have some kind of bypass= for locally-served zones, the end user will not have access to those zones= , and this will likely cause operational problems which the user will be un= prepared to diagnose.=C2=A0 =C2=A0As someone pointed out, existing resolver= s configured to use 8.8.8.8 have this same problem, so it is not unique to = DoH.=C2=A0 =C2=A0This is just an opportunity to raise awareness of the issu= e, and I think it's worth doing.=C2=A0 =C2=A0I think something along th= e lines of treating the local network as a separate PvD (RFC 7556) might wo= rk, but is out of scope for this document.

BTW, separate= ly, I think sending information to a generic DoH server about which web pag= e triggered a DNS query is a bad idea.

On Fri, Jul 20, 2018 at 2:29 PM, Eliot Lea= r (elear) <elear=3D40cisco.com@dmarc.ietf.org> wrote:
Forgive the cell phone top pos= ting, but I think the suggestion is to note the issue.=C2=A0 I don=E2=80=99= t think I read anyone suggesting delving into solutions. The reason it can = be tricky is that locality can involve multiple groups of networks and mult= iple domains. This is quite typical in large organizations.

Eliot

> On Jul 20, 2018, at 08:46, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>
>> On Fri, Jul 20, 2018 at 05:25:09AM +0000, Eliot Lear (elear) wrote= :
>> That it=E2=80=99s not unique to doh doesn=E2=80=99t mean it isn=E2= =80=99t a problem.
>
> Well, yes, obviously, but I don't understand how RFC 6303 isn'= t a
> consideration here.
>
> DoH servers serve DNS data, and considerations about the data servers<= br> > are supposed to serve apply equally to them as to any other
> DNS-serving server, I think.=C2=A0 Isn't that enough to say?
>
>> But I=E2=80=99m sure that absent additional information it will me= an people
>> having to turn doh off in split horizon environments. Having some<= br> >> notion of locality is important and not always easily available on=
>> first use.
>
> Why not?=C2=A0 The way this works in DNS is usually on the base of sou= rce
> port.=C2=A0 A DoH server knows that, too, no?
>
> Or is the worry that I have a DoH server configured and it doesn't=
> know about my network?=C2=A0 How is that different from today, if I > configure "my own" resolver?=C2=A0 If you configure 8.8.8.8 = on your laptop
> and take it into your example.com corporate network, then
> "floor1printer.example.com" is also unlikely to w= ork, right?
>
> I think it is useful to note this, but unless the idea is that every > resolver has knowledge of every possible context (plainly, an
> impossible goal), then this is going to be a constant problem I
> think.
>
> I think Olafur was making this point in the driu BoF: this was a big > part of a problem in MIF, and that WG's approach didn't fully = solve
> it.=C2=A0 I suspect that the non-solution had to do with the basic
> impossiblity of solving this completely generally in an
> internet-compatible way.
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com >
> _______________________________________________
> 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

--000000000000b705e70571a9ef9a-- From nobody Tue Jul 24 16:24: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 A246413121C for ; Tue, 24 Jul 2018 16:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 Gx-G9R6hvaTK for ; Tue, 24 Jul 2018 16:24:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B8845130F6C for ; Tue, 24 Jul 2018 16:24:26 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6ONOOo2034507 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jul 2018 18:24:25 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: draft-ietf-doh-dns-over-https@tools.ietf.org, "doh@ietf.org" From: Adam Roach Message-ID: Date: Tue, 24 Jul 2018 18:24:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 23:24:30 -0000 This is my AD review for draft-ietf-doh-dns-over-https-12.  I have a handful of comments below that I'd like to see addressed prior to asking the IESG to consider the document, but they do not preclude it from entering IETF last call. Please treat them as you would any other last-call comments. Thanks to everyone who worked on this document, and to the early implementors whose work informed its development. --------------------------------------------------------------------------- Abstract: >  This document describes how to make DNS queries over HTTPS. This seems overly minimal for an abstract. I would propose a condensed version of the first paragraph of the Introduction; e.g.:    This document defines a specific protocol for sending DNS queries and    getting DNS responses over TLS-secured HTTP. Each DNS query-response pair is    mapped into an HTTP exchange. --------------------------------------------------------------------------- §5.1.1 and 5.2.2: Please consider adding or replacing the existing examples with a request for a AAAA record. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for guidance on the use of IPv6 examples in IETF specifications. =========================================================================== All of my remaining comments are minor editorial issues. §1: >  Each DNS query-response pair is mapped into a HTTP >  exchange. Nit: "...an HTTP..." --------------------------------------------------------------------------- §4: >  DoH >  Servers MAY support more than one URI. Nit: "...URI Template." --------------------------------------------------------------------------- §5.1: >  The DoH client SHOULD include an HTTP "Accept" request header to Nit: "...request header field..." >  Irrespective of the value of the Accept request header, the client Nit: "...request header field..." --------------------------------------------------------------------------- §6.1: >  A DoH exchange can pass through a hierarchy of caches that include >  both HTTP and DNS specific caches. Nit: "...both HTTP- and DNS-specific caches." --------------------------------------------------------------------------- §6.1: >  The stale-while-revalidate and stale-if-error Cache-Control >  directives ([RFC5861]) could be well suited to a DoH implementation Nit: "...well-suited..." --------------------------------------------------------------------------- §6.1: >  DoH clients MUST account for the Age response header's value Nit: "...header field's value..." >   if a RRset is received with a DNS TTL of 600, but the Age header Nit: "...header field..." --------------------------------------------------------------------------- §6.2: >  The messages in classic UDP based DNS [RFC1035] are inherently Nit: "...UDP-based..." --------------------------------------------------------------------------- §6.3: >  For HTTP requests initiated by the DoH client this is implicit in the Nit: "...DoH client, this is..." --------------------------------------------------------------------------- §9.2: >  The DNS wire format [RFC1035] contains no client identifiers, however >  various transports of DNS queries and responses do provide data that Nit: "...client identifiers; however, various..." >  for correlation such as explicit HTTP cookies and implicit Nit: "...for correlation, such as..." --------------------------------------------------------------------------- §9.2: >  requests directly group those requests.  Long lived connections have >  better performance behaviors than short lived connections, but group Nit: "...long-lived..." Nit: "...short-lived..." --------------------------------------------------------------------------- §9.2: >  TLS based implementations often achieve better handshake performance Nit: "TLS-based..." --------------------------------------------------------------------------- §9.2: >  are designed as an explicit state tracking mechanism between the Nit: "...state-tracking..." --------------------------------------------------------------------------- §10: >  Session level encryption has well known weaknesses with respect to Nit: "Session-level..." Nit: "...well-known..." --------------------------------------------------------------------------- §11: >  It logically follows that the >  server which is queried can influence the end result. Nit: "...server that is queried..." --------------------------------------------------------------------------- §11: >  The HTTPS channel used by this specification establishes secure two >  party communication between the DoH client and the DoH server. Nit: "...two-party..." --------------------------------------------------------------------------- §11: >  Some HTTPS client implementations perform real time third party >  checks of the revocation status of the certificates being used by Nit: "...third-party..." >  possibility of deadlock, DoH servers SHOULD NOT rely on DNS based >  references to external resources in the TLS handshake.  For OCSP the Nit: "...DNS-based..." --------------------------------------------------------------------------- §11: >  Alternative strategies a client might employ include making the >  initial resolution part of the configuration, IP based URIs and >  corresponding IP based certificates for HTTPS, or resolving the DNS Nit: "...IP-based..." (twice) --------------------------------------------------------------------------- §11: >  HTTP [RFC7230] is a stateless application level protocol and Nit: "...application-level..." /a From nobody Tue Jul 24 17:24:00 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 E27A11277CC for ; Tue, 24 Jul 2018 17:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7B1T2Y6GkcJ2 for ; Tue, 24 Jul 2018 17:23:56 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 11C17130DFA for ; Tue, 24 Jul 2018 17:23:56 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 2433E3A038 for ; Tue, 24 Jul 2018 20:23:54 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id b15-v6so10802451oib.10 for ; Tue, 24 Jul 2018 17:23:54 -0700 (PDT) X-Gm-Message-State: AOUpUlHfdzFbz/5AhC+K/UsAlKpkMU51/D6KBdyfz1jcppiM3os53BUF Mp1PEXRQi8ceKzqjwGgnoExgPdq0vUl08xa09ew= X-Google-Smtp-Source: AAOMgpcwO0/aK5VUeTD916mSas7v7cMVHByJgjoyEwl/QljceN3h0xI7NuXOkw/fk5L56lZNfqAPFYqAiyMS2jXDJwg= X-Received: by 2002:aca:5f0a:: with SMTP id t10-v6mr1039426oib.337.1532478233883; Tue, 24 Jul 2018 17:23:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 17:23:53 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 24 Jul 2018 20:23:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: draft-ietf-doh-dns-over-https@tools.ietf.org, "doh@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c1b9e40571c7e403" Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 00:23:58 -0000 --000000000000c1b9e40571c7e403 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Adam! On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach wrote: > > Abstract: > > > This document describes how to make DNS queries over HTTPS. > > This seems overly minimal for an abstract. I would propose a condensed > version > of the first paragraph of the Introduction; e.g.: > > This document defines a specific protocol for sending DNS queries and > getting DNS responses over TLS-secured HTTP. Each DNS query-response > pair is > mapped into an HTTP exchange. > can I convince you of (the subtly different) "This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange." > > =C2=A75.1: > > > The DoH client SHOULD include an HTTP "Accept" request header to > > Nit: "...request header field..." > > I understand header field is traditional; but honestly I'd like to stop doing it as I don't think it clarifies anything in this context and just sounds stilted. I'll accept pushback, but I want to try :) --000000000000c1b9e40571c7e403 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Adam!

On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach <adam@nos= trum.com> wrote:

Abstract:

>=C2=A0 This document describes how to make DNS queries over HTTPS.

This seems overly minimal for an abstract. I would propose a condensed vers= ion
of the first paragraph of the Introduction; e.g.:

=C2=A0=C2=A0 This document defines a specific protocol for sending DNS quer= ies and
=C2=A0=C2=A0 getting DNS responses over TLS-secured HTTP. Each DNS query-re= sponse pair is
=C2=A0=C2=A0 mapped into an HTTP exchange.

<= div>can I convince you of (the subtly different) "This document define= s a protocol for sending DNS queries and getting DNS responses over HTTPS. = Each DNS query-response pair is mapped into an HTTP exchange."

=C2=A0

=C2=A75.1:

>=C2=A0 The DoH client SHOULD include an HTTP "Accept" request= header to

Nit: "...request header field..."


I understand header field is tradition= al; but honestly I'd like to stop doing it as I don't think it clar= ifies anything in this context and just sounds stilted. I'll accept pus= hback, but I want to try :)



<= /div> --000000000000c1b9e40571c7e403-- From nobody Tue Jul 24 18:14: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 532E0130E3C for ; Tue, 24 Jul 2018 18:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 zV7dGwijDrQJ for ; Tue, 24 Jul 2018 18:14:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 88F8712785F for ; Tue, 24 Jul 2018 18:14:14 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6P1EBpg051909 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jul 2018 20:14:12 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Patrick McManus Cc: draft-ietf-doh-dns-over-https@tools.ietf.org, "doh@ietf.org" References: From: Adam Roach Message-ID: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> Date: Tue, 24 Jul 2018 20:14:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E0C680B3B971B3143CB49DAD" Content-Language: en-US Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 01:14:17 -0000 This is a multi-part message in MIME format. --------------E0C680B3B971B3143CB49DAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/24/18 7:23 PM, Patrick McManus wrote: > Thanks Adam! > > On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach > wrote: > > > Abstract: > > >  This document describes how to make DNS queries over HTTPS. > > This seems overly minimal for an abstract. I would propose a > condensed version > of the first paragraph of the Introduction; e.g.: > >    This document defines a specific protocol for sending DNS > queries and >    getting DNS responses over TLS-secured HTTP. Each DNS > query-response pair is >    mapped into an HTTP exchange. > > > can I convince you of (the subtly different) "This document defines a > protocol for sending DNS queries and getting DNS responses over HTTPS. > Each DNS query-response pair is mapped into an HTTP exchange." That's fine as well. > > > > §5.1: > > >  The DoH client SHOULD include an HTTP "Accept" request header to > > Nit: "...request header field..." > > > I understand header field is traditional; but honestly I'd like to > stop doing it as I don't think it clarifies anything in this context > and just sounds stilted. I'll accept pushback, but I want to try :) > You're getting pushback. "Header" means something, and this ain't it. The issue is that we use "header" *colloquially* to mean "header field," but in a formal context, that's not just sloppy -- it's inside baseball. An implementor who is not part of the existing HTTP culture -- especially one who is just coming up to speed by reading the base HTTP documents, and who has the distinction between "header" and "header field" fresh in his mind -- may rightly be confused by this short-hand. Our documents are for a broader audience than ourselves, and we need to remain mindful of the level of experience some of that audience might have. /a --------------E0C680B3B971B3143CB49DAD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/24/18 7:23 PM, Patrick McManus wrote:
Thanks Adam!

On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach <adam@nostrum.com> wrote:

Abstract:

>  This document describes how to make DNS queries over HTTPS.

This seems overly minimal for an abstract. I would propose a condensed version
of the first paragraph of the Introduction; e.g.:

   This document defines a specific protocol for sending DNS queries and
   getting DNS responses over TLS-secured HTTP. Each DNS query-response pair is
   mapped into an HTTP exchange.

can I convince you of (the subtly different) "This document defines a protocol for sending DNS queries and getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP exchange."

That's fine as well.


 

§5.1:

>  The DoH client SHOULD include an HTTP "Accept" request header to

Nit: "...request header field..."


I understand header field is traditional; but honestly I'd like to stop doing it as I don't think it clarifies anything in this context and just sounds stilted. I'll accept pushback, but I want to try :)


You're getting pushback. "Header" means something, and this ain't it.

The issue is that we use "header" *colloquially* to mean "header field," but in a formal context, that's not just sloppy -- it's inside baseball. An implementor who is not part of the existing HTTP culture -- especially one who is just coming up to speed by reading the base HTTP documents, and who has the distinction between "header" and "header field" fresh in his mind -- may rightly be confused by this short-hand. Our documents are for a broader audience than ourselves, and we need to remain mindful of the level of experience some of that audience might have.

/a
--------------E0C680B3B971B3143CB49DAD-- From nobody Wed Jul 25 00:17:04 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 1CD3B130ECC for ; Wed, 25 Jul 2018 00:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 F52MM54Cw1B0 for ; Wed, 25 Jul 2018 00:17:00 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 C0CEF130EC1 for ; Wed, 25 Jul 2018 00:17:00 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id 13-v6so12120371ois.1 for ; Wed, 25 Jul 2018 00:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kQigNiiWOM+1m2IG95LRAKLZrrt1tmNGpi7uhykB49g=; b=O0VOXKFKaGFKL+eqswGTKynP82hkppZ8yBZ74Ao9rnD89xuo0BYDFbl8hZh9qtCnez JzM0CxECDECzayoFRuXR31Cwb6unP8BFRovipV+ag0xUCdG8DeQ5EmZ1Mjj1v8bHpTk1 /6qt1SdJdFuoWyMYjphvkD3dfMvafi+jEsvz9vca+6eC2X+5+SkB/thYzxTz0Qqfimr2 d7bw9i7Kl+CfaqbNp59lKsdOxZrnWg3YsvVjhQdwka67C6GAAW/YCD37O0TexXUQerrZ iH0plZoqgKEV5U3P2KAe4y0zosDoHstfB/MtPToI+TV3mgACis4e/kAo7X8qrDvXb5L1 LvQQ== 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:content-transfer-encoding; bh=kQigNiiWOM+1m2IG95LRAKLZrrt1tmNGpi7uhykB49g=; b=hMu+C1mWE5TBo4ZWUHp3WKWWAwOSgKTVQxGwdE3DOaT7NXGcdMKDDMoTaNloXudivY sDpSEjt5HlWCPxq1BvY0fNZ0+Er8XDZym5buVatrP3plEgDSvZiDj9jlslDVRquWzP8z 91har2nl39hnxHDDPxrS3dXMz4oQF/m4iRODlyZ6caKmPXHvZEldAa23f7H8mD09UlSg S7kHvuet+pKI6Uc2B37wYBFXnfnH7KXUvIzP4Qm1SUqsirY48u54w0OZ4oXu7ou2bO/Q 9IMuPJYThmhfCI39tEQyjzfMDF7dUuHmthunsRfCGeBlp0DP3hrpoETqOrA+Qe8ZVLiV eNrw== X-Gm-Message-State: AOUpUlECLlkXVHxBwsCZY9p5RQPAXS3dZKejNpopDGr7LO5W8DCRoOhM RlISjb4vUEonp6lzlqT/+ajwdb0Rxa7VssnfU8T3iu2B X-Google-Smtp-Source: AAOMgpfPqeU6KOkyGI7njg8ez4+XtFWdL3YGYlqf67Qs10VDI81vBWxXa7iJqRCXhOFE+idcIeIn+7j8vEMWcd3IrbA= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr2367557oiq.110.1532503020093; Wed, 25 Jul 2018 00:17:00 -0700 (PDT) MIME-Version: 1.0 References: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> In-Reply-To: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> From: Martin Thomson Date: Wed, 25 Jul 2018 17:16:49 +1000 Message-ID: To: Adam Roach Cc: patrick mcmanus , draft-ietf-doh-dns-over-https@tools.ietf.org, DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 07:17:03 -0000 On Wed, Jul 25, 2018 at 11:14 AM Adam Roach wrote: > The issue is that we use "header" *colloquially* to mean "header field," = but in a formal context, that's not just sloppy -- it's inside baseball. An= implementor who is not part of the existing HTTP culture -- especially one= who is just coming up to speed by reading the base HTTP documents, and who= has the distinction between "header" and "header field" fresh in his mind = -- may rightly be confused by this short-hand. Our documents are for a broa= der audience than ourselves, and we need to remain mindful of the level of = experience some of that audience might have. For the benefit of those watching, the distinction is fairly rigorously maintained in HTTP documents, but it's unclear if it is valuable. That distinction is: the header is the thing at the front of a message, before the body. The header contains a status line and a number of header fields. We often see people refer to (for example) header fields as "headers" without any risk of confusion, but it's a just a recognized and widespread shorthand. This is not a closed subject (see https://github.com/httpwg/http-core/issues/111#issuecomment-403666777), and I don't believe that there is much risk of confusion, but using the correct form doesn't cost us a lot. (I am reminded of the big "I" internet question that we had decided for us by the AP...) From nobody Wed Jul 25 08:22:00 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 E491212F1AC; Wed, 25 Jul 2018 08:21:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk CC: doh@ietf.org, adam@nostrum.com, Benjamin Schwartz , bemasc@google.com, doh-chairs@ietf.org, draft-ietf-doh-dns-over-https@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Message-ID: <153253211692.15442.16271588500088159620.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2018 08:21:56 -0700 Archived-At: Subject: [Doh] Last Call: (DNS Queries over HTTPS (DoH)) to Proposed Standard X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:21:57 -0000 The IESG has received a request from the DNS Over HTTPS WG (doh) to consider the following document: - 'DNS Queries over HTTPS (DoH)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-08-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how to make DNS queries over HTTPS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc7626: DNS Privacy Considerations (Informational - IETF stream) From nobody Wed Jul 25 08:24: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 1D85112D7F8 for ; Wed, 25 Jul 2018 08:24:31 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 sOuRJFo53V0O for ; Wed, 25 Jul 2018 08:24:28 -0700 (PDT) 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 0940D1271FF for ; Wed, 25 Jul 2018 08:24:28 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6PFMlA6027679; Wed, 25 Jul 2018 16:24:27 +0100 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=t+kpPOt93hJFgu7DQ5BeHfyMBBco7GBhVOkXhxoM3AI=; b=a670Wv8HYMSArjUKTpegreAc71aWlL5W9sieNA0xXNJuU1U1U25drPp0qTFAcX5nFTDC kuJdCUaeF+hxxebFvupt2c07eFv1USrWPPNNpLPKByu0zmk9VY3KOnvfcDhvrGAMQI0K ZRJsgnVeOF09rsh9n3fUimxDu0zqSKKqrKJbK3BscyHpDOThZwQRJPm25okMDuVrg2U+ m08y6rlQM4BEGvvhA9WNx88mjkIhapswKTRD8Qk4TMo07wntHndJdMzdCOUmry7EvJfi vI3S8nL/6ahMTqYbD9IFcLBgyYGN6ohIHuMyduhuRQ/gBTgAptAGm9Msa45wQdY84Hbk fg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2kesqt8pvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 16:24:27 +0100 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 w6PFJZQG018152; Wed, 25 Jul 2018 11:24:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 2kc05wejx9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 11:24:25 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com (172.27.123.104) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Jul 2018 11:24:23 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com ([172.27.123.104]) by usma1ex-dag1mb4.msg.corp.akamai.com ([172.27.123.104]) with mapi id 15.00.1365.000; Wed, 25 Jul 2018 11:24:23 -0400 From: "Hewitt, Rory" To: Adam Roach , Patrick McManus CC: "draft-ietf-doh-dns-over-https@tools.ietf.org" , "doh@ietf.org" Thread-Topic: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 Thread-Index: AQHUI6V9pgi9PxJNZ0yWPXEV3ZyCgaSfV0uAgAAOCACAAKkPEA== Date: Wed, 25 Jul 2018 15:24:23 +0000 Message-ID: <89b61935592b41e3987a06f74770d290@usma1ex-dag1mb4.msg.corp.akamai.com> References: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> In-Reply-To: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> 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.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A5_01D423F0.E38674F0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , 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-1806210000 definitions=main-1807250164 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , 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-1806210000 definitions=main-1807250165 Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 15:24:31 -0000 ------=_NextPart_000_00A5_01D423F0.E38674F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A6_01D423F0.E38674F0" ------=_NextPart_001_00A6_01D423F0.E38674F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable All due respect to you, Adam, but I honestly cannot conceive of a = potential implementor of DoH who would get confused by the "header" / = "header field" distinction. I appreciate your point that a) we should = use standard terminology and b) we should be aware of the broader = audience (and I'm aware that it doesn't 'cost' anything to use one = rather than the other) but TBH, I've been writing code for almost 25 = years, most of that in the last 15 years being web-related, and I = honestly never even KNEW that the official term was "header field" - = I've only used "header", even when writing product documentation. I've = apparently been using it wrong all along =F0=9F=98=8A =20 To be blunt, if someone honestly gets confused about this sentence =20 The DoH client SHOULD include an HTTP "Accept" request header to =20 then they have bigger problems to worry about than implementing DoH... =20 But since it's no biggie to change it to "header field", I guess we = should use standard terminology. =20 From: Adam Roach =20 Sent: Tuesday, July 24, 2018 6:14 PM To: Patrick McManus Cc: draft-ietf-doh-dns-over-https@tools.ietf.org; doh@ietf.org Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 =20 On 7/24/18 7:23 PM, Patrick McManus wrote: Thanks Adam! =20 On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach > wrote: Abstract: > This document describes how to make DNS queries over HTTPS. This seems overly minimal for an abstract. I would propose a condensed = version of the first paragraph of the Introduction; e.g.: This document defines a specific protocol for sending DNS queries and getting DNS responses over TLS-secured HTTP. Each DNS query-response = pair is mapped into an HTTP exchange. =20 can I convince you of (the subtly different) "This document defines a = protocol for sending DNS queries and getting DNS responses over HTTPS. = Each DNS query-response pair is mapped into an HTTP exchange." That's fine as well. =20 =20 =C2=A75.1: > The DoH client SHOULD include an HTTP "Accept" request header to Nit: "...request header field..." =20 I understand header field is traditional; but honestly I'd like to stop = doing it as I don't think it clarifies anything in this context and just = sounds stilted. I'll accept pushback, but I want to try :) =20 You're getting pushback. "Header" means something, and this ain't it. The issue is that we use "header" *colloquially* to mean "header field," = but in a formal context, that's not just sloppy -- it's inside baseball. = An implementor who is not part of the existing HTTP culture -- = especially one who is just coming up to speed by reading the base HTTP = documents, and who has the distinction between "header" and "header = field" fresh in his mind -- may rightly be confused by this short-hand. = Our documents are for a broader audience than ourselves, and we need to = remain mindful of the level of experience some of that audience might = have. /a ------=_NextPart_001_00A6_01D423F0.E38674F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

All due respect to you, Adam, but I honestly cannot = conceive of a potential implementor of DoH who would get confused by the = "header" / "header field" distinction. I appreciate = your point that a) we should use standard terminology and b) we should = be aware of the broader audience (and I'm aware that it doesn't 'cost' = anything to use one rather than the other) but TBH, I've been writing = code for almost 25 years, most of that in the last 15 years being = web-related, and I honestly never even KNEW that the official term was = "header field" - I've only used "header", even when = writing product documentation. I've apparently been using it wrong all = along 😊

 

To be = blunt, if someone honestly gets confused about this = sentence

 

The DoH client SHOULD = include an HTTP "Accept" request header to

 

then = they have bigger problems to worry about than implementing = DoH...

 

But since it's no biggie to change it to = "header field", I guess we should use standard = terminology.=

=  

From: Adam Roach <adam@nostrum.com> =
Sent: Tuesday, July 24, 2018 6:14 PM
To: Patrick = McManus <pmcmanus@mozilla.com>
Cc: = draft-ietf-doh-dns-over-https@tools.ietf.org; = doh@ietf.org
Subject: Re: [Doh] AD Review: = draft-ietf-doh-dns-over-https-12

 

On = 7/24/18 7:23 PM, Patrick McManus wrote:

Thanks Adam!

 

On Tue, = Jul 24, 2018 at 7:24 PM, Adam Roach <adam@nostrum.com> = wrote:


Abstract:

>  This document = describes how to make DNS queries over HTTPS.

This seems overly = minimal for an abstract. I would propose a condensed version
of the = first paragraph of the Introduction; e.g.:

   This = document defines a specific protocol for sending DNS queries = and
   getting DNS responses over TLS-secured HTTP. Each = DNS query-response pair is
   mapped into an HTTP = exchange.

 

can I convince you of (the subtly different) = "This document defines a protocol for sending DNS queries and = getting DNS responses over HTTPS. Each DNS query-response pair is mapped = into an HTTP = exchange."

=


That's fine as = well.


<= p class=3DMsoNormal> 

 


=C2=A75.1:

>  The DoH = client SHOULD include an HTTP "Accept" request header = to

Nit: "...request header = field..."

 

I = understand header field is traditional; but honestly I'd like to stop = doing it as I don't think it clarifies anything in this context and just = sounds stilted. I'll accept pushback, but I want to try = :)

 


You're getting pushback. = "Header" means something, and this ain't it.

The issue = is that we use "header" *colloquially* to mean "header = field," but in a formal context, that's not just sloppy -- it's = inside baseball. An implementor who is not part of the existing HTTP = culture -- especially one who is just coming up to speed by reading the = base HTTP documents, and who has the distinction between = "header" and "header field" fresh in his mind -- may = rightly be confused by this short-hand. Our documents are for a broader = audience than ourselves, and we need to remain mindful of the level of = experience some of that audience might = have.

/a

------=_NextPart_001_00A6_01D423F0.E38674F0-- ------=_NextPart_000_00A5_01D423F0.E38674F0 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 MDcyNTE1MjQyMVowIwYJKoZIhvcNAQkEMRYEFF2YFFcYu9FEXyuOCMtRoTR4aOkaMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAOq4IkjfwY60dCn8P9jFtvWS5P/e3le30a/3wAYn6Umx4cGRpgUV/neAc7A8 QjyUJ6Bc4jsWCs+Kf2uQvjJM9hauRXmfEwBJq81y0i2BlFGh81bbkQomKCPLGZNcmOwbY5tpyH5O 0MTFgjmOgpvVkVieOp6+dNaO+bbsQCFmayx+3/rHh2j3I9IyGWsdyqz34iTiRoRrpvBGfOQtkV/t ZmdHwSSRqWk3RvB8lcpuKxQLuvaQAn8YicPdbRxIZNNO4+V/gCTsDC2arQnQBYJTr2aUjVFhcMVn rRZn4oPWLCPR84v5lBecAP+dXndJqZDInQhYerLSpfP9SeFTpcz+SDgAAAAAAAA= ------=_NextPart_000_00A5_01D423F0.E38674F0-- From nobody Wed Jul 25 09:02: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 F2B3A12F1AC for ; Wed, 25 Jul 2018 09:02:11 -0700 (PDT) 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, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham 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 mEyy-YpWsoHh for ; Wed, 25 Jul 2018 09:02:09 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 A3C0F130E20 for ; Wed, 25 Jul 2018 09:02:02 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id q19-v6so6742353ioh.11 for ; Wed, 25 Jul 2018 09:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZYQO5L74Sj4Mah3+nuwBwWiF6W1Wgd9JV7SoguhSFfA=; b=RtmL6TZndMyw4GouPZko3Y5ocu6JG0BkUitkrff8bZq81hsBPYI0EyJyRhnBpIQycW nhM13TEMDmi/h0VSIQkszpFGUSZB8uH5ncG2HFxjwq8oYVFin1Rf072CnP2N8o4QIOCo +5aqkmF7hbfvQywIBaALZ/QLKesVQ47M5Clydxm2UGDF2E1paKiZQp/22SC3U9869BUj ObOEh9oWNE4Qj3X+Emb6wN3tO+hwcO3Q2WX919aZBFaQ9hnzbpT7efDtSmM9CtJA5OMQ QKkShXsA5mtoac2hrMQ5JXBUIW+hETrtq1KHSbXWbDXDYa0Df6/ZeNRDFJTuIXDik8jH MmOA== 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=ZYQO5L74Sj4Mah3+nuwBwWiF6W1Wgd9JV7SoguhSFfA=; b=JyLF2/axmn+irbpmAIluzcgGhHNvdhgOIRJz9t6hH8sEsImuFMwDn0fWBn7t6bfVAW MiokHfPzX2Q+Oq89Do3rZNhQwnEUcPhTCV4Cvt1onq8zt0uLXkiDabD19r9BROhi6wD4 S5nsuumH1lH9+I48d5eEkOfyKr3mmwOPuFgcuPJSVQApBsQ7G5LzNvK1BzU8KZGMyrDy GcgjNvIKeB+8tavZO5ymLsXy7u/tisHoFqbYHzKkumWptvcy51NsGvAGJX67jkJkpG3r qsf8MpS5zPpR3Fw+mW13zr8ahPQG1sv5/HONrL8nkTe1cmhqWJT+XTThUkUbNfom4+9H s8JA== X-Gm-Message-State: AOUpUlHbyIVFqqZXcgkwaS/fye1WyQ/GSvPplVe8TWatHB4Fp/OVP4Sw d+KoHEg0OCi4jNNKfYgL7x9UxyhKrUpueaWLata/KQ== X-Google-Smtp-Source: AAOMgpcOGdquKT9C4cj7+uBnmUh0YJ1Lr/eT0FyW4ULJOGL74GJVyj5d/DRMw2e+QnV298ka1DFwndR92DVjM4SGtPo= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr18355024ioe.85.1532534521952; Wed, 25 Jul 2018 09:02:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:b442:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 09:01:21 -0700 (PDT) In-Reply-To: <89b61935592b41e3987a06f74770d290@usma1ex-dag1mb4.msg.corp.akamai.com> References: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> <89b61935592b41e3987a06f74770d290@usma1ex-dag1mb4.msg.corp.akamai.com> From: Ted Lemon Date: Wed, 25 Jul 2018 12:01:21 -0400 Message-ID: To: "Hewitt, Rory" Cc: Adam Roach , Patrick McManus , "draft-ietf-doh-dns-over-https@tools.ietf.org" , "doh@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9941e0571d4ff09" Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 16:02:12 -0000 --000000000000c9941e0571d4ff09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rory, the reason to say "Header Field" rather than "Header" is not that the particular text you quoted would be misunderstood=E2=80=94I agree that it w= ould not. It's that it keeps the terminology clear. When I was reviewing the (awesome!) HTTP 2 documents, it was really helpful to me as a new reader that the distinction was kept clear, not because I would have misunderstood, but simply because it reduced the intellectual workload of parsing the document. This is worth doing. :) On Wed, Jul 25, 2018 at 11:24 AM, Hewitt, Rory < rhewitt=3D40akamai.com@dmarc.ietf.org> wrote: > All due respect to you, Adam, but I honestly cannot conceive of a > potential implementor of DoH who would get confused by the "header" / > "header field" distinction. I appreciate your point that a) we should use > standard terminology and b) we should be aware of the broader audience (a= nd > I'm aware that it doesn't 'cost' anything to use one rather than the othe= r) > but TBH, I've been writing code for almost 25 years, most of that in the > last 15 years being web-related, and I honestly never even KNEW that the > official term was "header field" - I've only used "header", even when > writing product documentation. I've apparently been using it wrong all > along =F0=9F=98=8A > > > > To be blunt, if someone honestly gets confused about this sentence > > > > The DoH client SHOULD include an HTTP "Accept" request header to > > > > then they have bigger problems to worry about than implementing DoH... > > > > But since it's no biggie to change it to "header field", I guess we shoul= d > use standard terminology. > > > > *From:* Adam Roach > *Sent:* Tuesday, July 24, 2018 6:14 PM > *To:* Patrick McManus > *Cc:* draft-ietf-doh-dns-over-https@tools.ietf.org; doh@ietf.org > *Subject:* Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 > > > > On 7/24/18 7:23 PM, Patrick McManus wrote: > > Thanks Adam! > > > > On Tue, Jul 24, 2018 at 7:24 PM, Adam Roach wrote: > > > Abstract: > > > This document describes how to make DNS queries over HTTPS. > > This seems overly minimal for an abstract. I would propose a condensed > version > of the first paragraph of the Introduction; e.g.: > > This document defines a specific protocol for sending DNS queries and > getting DNS responses over TLS-secured HTTP. Each DNS query-response > pair is > mapped into an HTTP exchange. > > > > can I convince you of (the subtly different) "This document defines a > protocol for sending DNS queries and getting DNS responses over HTTPS. Ea= ch > DNS query-response pair is mapped into an HTTP exchange." > > > That's fine as well. > > > > > > > > =C2=A75.1: > > > The DoH client SHOULD include an HTTP "Accept" request header to > > Nit: "...request header field..." > > > > I understand header field is traditional; but honestly I'd like to stop > doing it as I don't think it clarifies anything in this context and just > sounds stilted. I'll accept pushback, but I want to try :) > > > > > You're getting pushback. "Header" means something, and this ain't it. > > The issue is that we use "header" *colloquially* to mean "header field," > but in a formal context, that's not just sloppy -- it's inside baseball. = An > implementor who is not part of the existing HTTP culture -- especially on= e > who is just coming up to speed by reading the base HTTP documents, and wh= o > has the distinction between "header" and "header field" fresh in his mind > -- may rightly be confused by this short-hand. Our documents are for a > broader audience than ourselves, and we need to remain mindful of the lev= el > of experience some of that audience might have. > > /a > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000c9941e0571d4ff09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rory, the reason to say "Header Field" rather th= an "Header" is not that the particular text you quoted would be m= isunderstood=E2=80=94I agree that it would not.=C2=A0 =C2=A0It's that i= t keeps the terminology clear.=C2=A0 =C2=A0When I was reviewing the (awesom= e!) HTTP 2 documents, it was really helpful to me as a new reader that the = distinction was kept clear, not because I would have misunderstood, but sim= ply because it reduced the intellectual workload of parsing the document.= =C2=A0 =C2=A0This is worth doing. :)

On Wed, Jul 25, 2018 at 11:24 AM, Hewitt, Rory <rhewitt=3D40akamai.com@dmarc.ietf.org> wro= te:

All due respect to y= ou, Adam, but I honestly cannot conceive of a potential implementor of DoH = who would get confused by the "header" / "header field"= distinction. I appreciate your point that a) we should use standard termin= ology and b) we should be aware of the broader audience (and I'm aware = that it doesn't 'cost' anything to use one rather than the othe= r) but TBH, I've been writing code for almost 25 years, most of that in= the last 15 years being web-related, and I honestly never even KNEW that t= he official term was "header field" - I've only used "he= ader", even when writing product documentation. I've apparently be= en using it wrong all along =F0=9F=98=8A

=C2=A0

To be blunt, if someone honestly gets confused ab= out this sentence

=C2=A0

The DoH client SHOULD incl= ude an HTTP "Accept" request header to

=C2=A0

then they have bigger problems = to worry about than implementing DoH...

=C2=A0

But since it's no biggie to change it to &qu= ot;header field", I guess we should use standard terminology.

= =C2=A0

From: Ada= m Roach <adam@nost= rum.com>
Sent: Tuesday, July 24, 2018 6:14 PM
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: draft-ietf-doh-dns-= over-https@tools.ietf.org; doh@ietf.org
Subject: Re: [Doh] AD Review: draft-= ietf-doh-dns-over-https-12

=C2=A0

On 7/24/18 7:23 PM, Patrick McManus wrote:

Thanks Adam!

=C2=A0

On Tue, Jul 24, = 2018 at 7:24 PM, Adam Roach <adam@nostrum.com> wrote:


Abstract:<= br>
>=C2=A0 This document describes how to make DNS queries over HTTP= S.

This seems overly minimal for an abstract. I would propose a cond= ensed version
of the first paragraph of the Introduction; e.g.:

= =C2=A0=C2=A0 This document defines a specific protocol for sending DNS quer= ies and
=C2=A0=C2=A0 getting DNS responses over TLS-secured HTTP. Each D= NS query-response pair is
=C2=A0=C2=A0 mapped into an HTTP exchange.<= /u>

=C2=A0=

can I convince you of (the subtly dif= ferent) "This document defines a protocol for sending DNS queries and = getting DNS responses over HTTPS. Each DNS query-response pair is mapped in= to an HTTP exchange."

<= /blockquote>


That's fine as well.


=

=C2=A0

<= /div>

=C2=A0


=C2=A75.1:

>=C2=A0 The DoH client SHOULD i= nclude an HTTP "Accept" request header to

Nit: "...re= quest header field..."

=C2=A0

I unde= rstand header field is traditional; but honestly I'd like to stop doing= it as I don't think it clarifies anything in this context and just sou= nds stilted. I'll accept pushback, but I want to try :)

=C2=A0


You're getting p= ushback. "Header" means something, and this ain't it.

= The issue is that we use "header" *colloquially* to mean "he= ader field," but in a formal context, that's not just sloppy -- it= 's inside baseball. An implementor who is not part of the existing HTTP= culture -- especially one who is just coming up to speed by reading the ba= se HTTP documents, and who has the distinction between "header" a= nd "header field" fresh in his mind -- may rightly be confused by= this short-hand. Our documents are for a broader audience than ourselves, = and we need to remain mindful of the level of experience some of that audie= nce might have.

/a


____= ___________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--000000000000c9941e0571d4ff09-- From nobody Wed Jul 25 09:30: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 517A5130DC0 for ; Wed, 25 Jul 2018 09:30:00 -0700 (PDT) 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, SPF_PASS=-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 0EAK4SRppOF7 for ; Wed, 25 Jul 2018 09:29:59 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085EF126BED for ; Wed, 25 Jul 2018 09:29:59 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 452A04678A; Wed, 25 Jul 2018 12:29:57 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23384.42373.258665.966@gro.dd.org> Date: Wed, 25 Jul 2018 12:29:57 -0400 From: Dave Lawrence To: DoH WG In-Reply-To: References: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 16:30:01 -0000 Martin Thomson writes: > (I am reminded of the big "I" internet question that we had decided > for us by the AP...) Piffle, the AP doesn't decide anything for us. Onward, Internet! From nobody Wed Jul 25 09:56: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 9F825130E29 for ; Wed, 25 Jul 2018 09:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 O8U0kSXk8TVl for ; Wed, 25 Jul 2018 09:56:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7AA130E1B for ; Wed, 25 Jul 2018 09:56:22 -0700 (PDT) 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 w6PGpf90011922; Wed, 25 Jul 2018 17:56:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ByMROGX2mMsYUi55SqFyMsjyNGJDhSOAVUA0WFI8hc8=; b=LKmvePT1yMvU5AdgB2CjOjLM/UiA+RziSG56dk9VaqH3cKU9AEe4ypwNy9CfUI3TpgW0 GnJsoa4L413AaJ99nLIQLN8kFRpdanhVRbeXRB7+ImlK+Thrm0hAI8qInWyuu6dU143z /mA34NCbGkhKh1lksc6l5dAbpvyLPhGpFvauPTYEgKO2Q9o1Fs74XqEpcWKdRSEpie4c Z38VSiY0FblOMYAwOn9oUX078i9g3hy6IeX0ZHcjqh27VtyDMnTszecPi4VhvCYzj8sw Y6QPJfLzpH9Ga/smdFftS1nR6oe3SwCm5Ia5jcG96RyMxMjhedA4g4c20v+ct6uU95Go /A== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2ke4994whv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 17:56:19 +0100 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 w6PGo2TK029398; Wed, 25 Jul 2018 12:56:19 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2kc05vevvu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 12:56:18 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com (172.27.123.104) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Jul 2018 12:56:17 -0400 Received: from USMA1EX-DAG1MB4.msg.corp.akamai.com ([172.27.123.104]) by usma1ex-dag1mb4.msg.corp.akamai.com ([172.27.123.104]) with mapi id 15.00.1365.000; Wed, 25 Jul 2018 12:56:17 -0400 From: "Hewitt, Rory" To: Dave Lawrence , DoH WG Thread-Topic: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 Thread-Index: AQHUI6V9pgi9PxJNZ0yWPXEV3ZyCgaSfV0uAgAAOCACAAGVYgIAAmouA///ELPA= Date: Wed, 25 Jul 2018 16:56:16 +0000 Message-ID: References: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> <23384.42373.258665.966@gro.dd.org> In-Reply-To: <23384.42373.258665.966@gro.dd.org> 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.119] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00B5_01D423FD.BA1A4990" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , 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-1806210000 definitions=main-1807250179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , 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-1806210000 definitions=main-1807250179 Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 16:56:26 -0000 ------=_NextPart_000_00B5_01D423FD.BA1A4990 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable "Onward, internet!" FTFY =F0=9F=98=8A Rory -----Original Message----- From: Dave Lawrence =20 Sent: Wednesday, July 25, 2018 9:30 AM To: DoH WG Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 Martin Thomson writes: > (I am reminded of the big "I" internet question that we had decided=20 > for us by the AP...) Piffle, the AP doesn't decide anything for us. Onward, Internet! _______________________________________________ Doh mailing list Doh@ietf.org https://www.ietf.org/mailman/listinfo/doh ------=_NextPart_000_00B5_01D423FD.BA1A4990 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 MDcyNTE2NTYxNVowIwYJKoZIhvcNAQkEMRYEFItMzw4aE2cQi87R6DGxmnmgkelcMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBADnCdWFf/f0JhzkVJStyGeDfi1yZWwqrpMWczpJj/GGRlDdmJyeAjes84IBd W+ffB5YTshFijer3Ln0hQO5LwHCLoQ97byQgbqj6pfA0zI0NgMQpk/wJclJFLfCRHIw9negLVNXl opUb/6w8G0i6Kh38z3pZF/27A30aLN94V7onxiEQm3be1K669q6znIt4Q0XhAlfWAAtkOBxu35+A xi/cN8jxYyESjuwPicNFCrrRDCRNg7bB84H3ce6+6tomH1lpPhPJsfa98eOvzfk9CUiR3tH7ugaM 2nQJX3ZwSBhHi66C1F/38QqtHImIY2j2z17s468/jD1sr3DDTwl5NjUAAAAAAAA= ------=_NextPart_000_00B5_01D423FD.BA1A4990-- From nobody Wed Jul 25 10:32:52 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 55C87124D68 for ; Wed, 25 Jul 2018 10:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 ZbZrjTgi24dH for ; Wed, 25 Jul 2018 10:32:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 92CC6130DCD for ; Wed, 25 Jul 2018 10:32:47 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6PHWgXU015236 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 25 Jul 2018 12:32:43 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: "Hewitt, Rory" , Patrick McManus Cc: "draft-ietf-doh-dns-over-https@tools.ietf.org" , "doh@ietf.org" References: <04947a82-6d30-0bfb-338c-afde9643cadf@nostrum.com> <89b61935592b41e3987a06f74770d290@usma1ex-dag1mb4.msg.corp.akamai.com> From: Adam Roach Message-ID: <40fea23c-6b30-44f0-3433-6554ed03210e@nostrum.com> Date: Wed, 25 Jul 2018 12:32:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <89b61935592b41e3987a06f74770d290@usma1ex-dag1mb4.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] AD Review: draft-ietf-doh-dns-over-https-12 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 17:32:50 -0000 On 7/25/18 10:24 AM, Hewitt, Rory wrote: > TBH, I've been writing code for almost 25 years, most of that in the > last 15 years being web-related, and I honestly never even KNEW that > the official term was "header field" I'm not as much worried about you and people with similar backgrounds as I am people with approximately zero HTTP background but lots of DNS experience. /a From nobody Sat Jul 28 01:57: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 D17E113110B for ; Sat, 28 Jul 2018 01:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 (4096-bit key) header.d=bartschnet.de 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 W3GKCfXzl5qI for ; Sat, 28 Jul 2018 01:57:43 -0700 (PDT) Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 9364A130DC2 for ; Sat, 28 Jul 2018 01:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bartschnet.de; s=2018030201; h=Content-Transfer-Encoding:MIME-Version:Date: Message-ID:Subject:From:To:content-disposition; bh=FQN7OyQpQVg2HXqu4rQKUUqx/nQZzPSs7ZR+kQuSpfA=; b=d5r0Ap8mt4t0+El7F3cALKPUp9 Yfn4OP/RtDfBlIVYrbZ9NQoWZ7zNJZtHCSWFXgM9jPf0VWwxyxjGTBsc2kPMKkiS+JKSHGzgisgFH 0M8r2YxqjOxzuVGRAKrjyWJnS8LMz0tfZV7NIhT5dZIdLeEIsfPqDLqWAtynk1wRNsFpvx/xloeNO mZRDVLtSokiX8Fs8FCrjDm06wuMPeSh1a1etA9thWC4WxHtx8+YQUgn0dwB6kFcnzdJfZ41Q5Mrkw 77xTKbFU5PM1rxX4Ht76vGTpVvNJ41dAA5W9oujVwqY4K0RfG2+f8BJgEUHdRq8rONgONYRXWAj3T oPbPOucVOum8wfnb+PvErDbsBHmkIxoG54vB0jK8Ed8riYYKC8hGASxymEVSZvMwhu07SKP1iLRJY 4JwAYJm5SswNR8qxsNjpCHJ1nrA2vhKTO/MsRUTwvXJ8qwMk7M0pq/CxGWI+t3/m341Fm3abifDVo 18arI80GUVEwqTuYv7QPBJt6h6PdZNso9ZWJSt5GE4Bgr0eNuwkjJPTaQrImbTjive3rXvBr/k1D9 vYIT8jP8I8pwc9TMxJBW5MTnOstpJveH6h7YIH4N73LiPRMqziNEKFG3lT0wa32B5ClBw71LdBNgY VYPH3KqHT7DtB/EDDlObH3vI0xpPq07RKETpIvsM8=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fjL2h-0002hx-Lb with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Sat, 28 Jul 2018 10:57:40 +0200 To: doh@ietf.org From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Sat, 28 Jul 2018 10:57:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: [Doh] P2P against centralization X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 08:57:46 -0000 Hi, how about using a WebRTC-based P2P-network with signed zones? WebRTC and random peers would provide privacy and signed zones/records would make sure the records have not been tampered with. DoS-attacks and censorship would be nearly impossible against an encrypted, signed and distributed DNS-system. Regards, Renne From nobody Sat Jul 28 09:27:30 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 EA634130E63 for ; Sat, 28 Jul 2018 09:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.875 X-Spam-Level: X-Spam-Status: No, score=-0.875 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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=hotmail.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 vORn8-y5IhGX for ; Sat, 28 Jul 2018 09:27:27 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001077.outbound.protection.outlook.com [40.92.1.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6312C128BAC for ; Sat, 28 Jul 2018 09:27:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mx+M2b1wpvMQD0I8rbw9UyNz/TJiJFxPZ1U20w4ypF0=; b=k5nIl4R/xTGQnx5wwcIKChzdXgRP6TBegLLgP0e8ouKkXOGdOXcDmdLq3ZM2LV3de/kGJdY/DpTQ+5UQ+KxkH6sZzmj8fvv1JOdrseSNPVBH7Y1+UWW0kkUG1VC/hj6J1TpfLqXi12obWKGAg7EnsehaoJbbF/a9uAG44cNkGxT0sk103o+VlHMHuxz9CimWovdwTmCEcwH5kyJz7x+bODA/Ga6Y7+rRzUmQiyjBcYNxWdBHPsRZ1SO6jHmpb3s4574O5Nf4Zk30moja+RG2ek3Tq6WlP+dYiTw36UOR139qYTBnh38wziS5jIrMIv4+GmEQpSzkBLxZ7Rk5st7Jhw== Received: from BN3NAM01FT012.eop-nam01.prod.protection.outlook.com (10.152.66.57) by BN3NAM01HT125.eop-nam01.prod.protection.outlook.com (10.152.67.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.995.12; Sat, 28 Jul 2018 16:27:26 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.66.60) by BN3NAM01FT012.mail.protection.outlook.com (10.152.67.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.995.12 via Frontend Transport; Sat, 28 Jul 2018 16:27:25 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::8514:9a20:4e1c:783d]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::8514:9a20:4e1c:783d%3]) with mapi id 15.20.0995.019; Sat, 28 Jul 2018 16:27:26 +0000 From: Star Brilliant To: "doh@ietf.org" Thread-Topic: [Doh] P2P against centralization Thread-Index: AQHUJlES2jRuWTNe5UW4bHxi9JOwvKSk0hSF Date: Sat, 28 Jul 2018 16:27:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A4E6C070E66438760287571E253F0046F1A73551DDBDD8BFEC0E6FB100095278; UpperCasedChecksum:A9F6ACCFB90772121A2704688275916C35BA406C272B47FAC1373860BBB548B9; SizeAsReceived:7172; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Fk5QTfByRRzd6t1meTLn1enImnWVqzGPT2Fzz2yxnFO13RQBs19D6EQ9xWCVytv0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT125; 6:2v7TExmuDpcM8Tp/iIBxOac2odPxX383FDsNiLAW3FX8gto9fej6FsMhVZpKRddZO/U0/PuLFi+AXEl1M05lx8lrGH68slFyvGDs5eUTuEE/0qHcuaPZ5auiymU92HagF4tuigPLozOs6PgP3kXxfMxDCtN6Pyq3o0YM74mEUnw/P+MhEEp0h46qx0MrDO0l9M8UHSEfSc4hPwFMpK6R9kEr8btkHc9PtYTuH0bfm4TcI0Rl1bCIMEyaBLCjsoehQa07vZAxL40QD+L/06mtuQi/USDZGUcv43ToXcLrprRd84MQyjsXH5/R+P2EXfxdqXEgFYKpmYMIWg+yiPjTlTeCWy/AZ3sMbK+RHpk/LOc9igz2qfyaO05G+4AK/1diNhOpcHZgmE3Ou1onlE/nNCs25dtFpghNAeo0tgG4TSwWLxUAuV8sVfhqY7eDAovs3ubpzXBuHBcWW5wjPYlBaA==; 5:fOq9oiwr9HlFRWnkejG4jDC7ep2YzmG8mOQBjoO02Mx/ltxlNBCAJysPeTxGitKYeqYFvD2BH7zjjiPqM2tY8p+AJ8zr5lY0kcOXf2SFKNWK0Qp4CDIGsst9q6FZhbBhhISZrUIq3O8+S1uqsSQ5hSbSzkt2os18Ps30QdOESR8=; 7:uu/iBMsBYmfmX6nCKqk9NXcPwxFRvLk2Jv3t1ShursW0/s6zummbaqQtogutM/j7wErjdii2QmtS28wnm7gkwbFFk7aUQNEYhnOufYai4mF/V4EgtUtvEiMOD4gb4UCprRhot2luX+3DtRINAfImaRqyjyG+rOw1Jjnj0vPISMpOi6Uaznw1fXdBPhnh7RTQ5x7DxNi3QBWoj/uf+ynohEdxIriDKlXwNx4K6lkG+BkJioVJDGEIBJ6q/Zm2HkVo x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1603101475)(1601125500)(1701031045); SRVR:BN3NAM01HT125; x-ms-traffictypediagnostic: BN3NAM01HT125: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(82015058); SRVR:BN3NAM01HT125; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT125; x-forefront-prvs: 07473990A5 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(33656002)(99286004)(104016004)(83332001)(5660300001)(102836004)(6506007)(6246003)(53546011)(8676002)(81156014)(1730700003)(5250100002)(68736007)(86362001)(6916009)(8936002)(4326008)(6346003)(6436002)(74316002)(2900100001)(2501003)(73972006)(305945005)(87572001)(76176011)(97736004)(56003)(46003)(25786009)(5640700003)(446003)(229853002)(55016002)(20460500001)(7696005)(486006)(2351001)(82202002)(11346002)(476003)(9686003)(106356001)(105586002)(256004)(14454004)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT125; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: hotmail.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=m13253@hotmail.com; x-microsoft-antispam-message-info: mhsFCLT/I1WT4hHu+nC940VzyNsFFBZ7CDowEOXjEodtOcBIXNMldSsz5OAWZK+9hLbdmuf89mzP6tVkVYvIb7r9lN/6xUx3oinwuMYJMgpU8QDT5t2hdmnPH8pUo+gB+jfxjFK2lpZrUgNmwBOuj2v4xdWv+aHEevKKcQh6OpOYPz4xsEHOnI2ZfGYJWqe9xG7dIJYjMlTo00XjeccmAgMzb9WOpNoyIAdVV/HdnnA= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-Network-Message-Id: dc3780da-2a4b-4d75-bb0c-08d5f4a7013a X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2018 16:27:25.8944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT125 Archived-At: Subject: Re: [Doh] P2P against centralization X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 16:27:29 -0000 On Saturday, July 28, 2018 16:57 B.Sc. Informatics wro= te: > Hi, >=20 > how about using a WebRTC-based P2P-network with signed zones? >=20 > WebRTC and random peers would provide privacy and signed zones/records wo= uld make sure the records have not been tampered with. > DoS-attacks and censorship would be nearly impossible against an encrypte= d, signed and distributed DNS-system. >=20 > Regards, >=20 > Renne Hi Renne, In simple answer: That's DoP2P, not DoH. Certainly you can start up your own project on DoP2P. But that is beyond th= e scope of *this* project.= From nobody Sat Jul 28 09:32: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 7A48313112F; Sat, 28 Jul 2018 09:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1LHR9oc1sEUa; Sat, 28 Jul 2018 09:32:06 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id C8006131058; Sat, 28 Jul 2018 09:32:05 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3E0353A01E; Sat, 28 Jul 2018 12:32:04 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id 13-v6so14401967ois.1; Sat, 28 Jul 2018 09:32:04 -0700 (PDT) X-Gm-Message-State: AOUpUlEgs9tLYUFMInrRu5Ed1/r6qRSyB9pQWcfS2V6E6xBmqwyb/Ddh h/hGbAcvoEI/gIA442lIIaxCH5f9LC0tBR7Wkhk= X-Google-Smtp-Source: AAOMgpe3GfMsU8IPLMBVMGcTYzO5YR2A132mu6+fScl/bN/My52Qoncd98FN47XywI0p+XDbx93EUAyTeO21dD3DrRA= X-Received: by 2002:aca:31c6:: with SMTP id x189-v6mr11878333oix.213.1532795523956; Sat, 28 Jul 2018 09:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 09:32:02 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sat, 28 Jul 2018 12:32:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus , DNS Privacy Working Group Cc: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , driu@ietf.org, HTTP Working Group , dnsop Content-Type: multipart/mixed; boundary="000000000000b82213057211c474" Archived-At: Subject: Re: [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 16:32:16 -0000 --000000000000b82213057211c474 Content-Type: multipart/alternative; boundary="000000000000b8220f057211c472" --000000000000b8220f057211c472 Content-Type: text/plain; charset="UTF-8" Hi All - This is a wrap-up email for the Resolverless DNS meeting held on July 16 in Montreal. We had, by my rough count, about 50 people and two sets of minutes are attached. If you attended, contributed, or took minutes (Thanks Shane and Ben!) thank you - it was, imo, a productive, professional, and even pretty focused discussion. We identified a next step: using an AD sponsored list (See Below!), identify one minimal context or use case that provides value for using DNS information without direct recursive resolver contact, and enumerate the concerns and potential mitigations for those concerns. If we can focus on that and make some progress then we might have a proposal for a future BoF - if we cannot make progress then that is also telling. Adam and Warren have setup a list for us to use. I apologize to the various working group's cc'd on this so far (and thank them for their indulgence) - future communications should move to the new list. New List Info ------------------- https://www.ietf.org/mailman/listinfo/resolverless-dns -Patrick On Mon, Jul 9, 2018 at 10:49 PM, Patrick McManus wrote: > Hi All, > > I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in > Montreal. > > We have often talked about the benefits and concerns of DNS information > obtained from sources that are, shall we say, less globally trusted than a > recursive a resolver. The central use case is DoH when pushed from an > endpoint that isn't a recursive resolver but there have been other > proposals. > > For example www.example.com pushes you a AAAA record for img1.example.com. > Should you use it? What if it is for img1.img-example.com ? Do the > relationship between these domains matter? What kind of relationship (i.e. > it could be a domain relationship, or in the context of a browser it might > be a first-party tab like relationship, etc..)? What are the implications > of poison? Trackers? Privacy of requests never made? Speed? Competitive > shenanigans or DoS attacks? > > This was out of scope for DoH. > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > > This is a meeting of interested folks looking to see if we can agree on > next steps - we're not going to work out the details (nor should a side > meeting try and do so). so we'll have a tight agenda that I suggest > organizaing as follows: > > 1] What forms of transport could be in scope? HTTP/2 push is one such > vector, but I've heard others. Spray paint for example. > > 2] What needs to be considered when using such data? (signatures? scope? > etc?) > > 3] Who are the stakeholders for 1 + 2? > > 4] Is there enough interest to explore further? Next steps as output > > I hope you can come! > > -Patrick > > --000000000000b8220f057211c472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All -

This is a wrap-up email for=20 the Resolverless DNS meeting held on July 16 in Montreal. We had, by my rou= gh count, about 50 people and two sets of minutes are attached. If you attended,=20 contributed, or took minutes (Thanks Shane and Ben!) thank you - it was, imo, a productive, professional, and even pretty focused discussion.
=

We identified a next step: using an AD sponsored list (See Below!),=20 identify one minimal context or use case that provides value for using=20 DNS information without direct recursive resolver contact, and enumerate the concerns and potential mitigations for those concerns. If we can=20 focus on that and make some progress then we might have a proposal for a future BoF - if we cannot make progress then that is also telling.

Adam and Warren have setup a list for us to use. I apologize to the various=20 working group's cc'd on this so far (and thank them for their=20 indulgence) - future communications should move to the new list.
=
New List Info
-------------------

<= br>
-Patrick



On Mon, Jul 9= , 2018 at 10:49 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
Hi All,

I am organizing an ad-hoc Side Meeting regar= ding 'Resolverless DNS' in Montreal.

We ha= ve often talked about the benefits and concerns of DNS information obtained= from sources that are, shall we say, less globally trusted than a recursiv= e a resolver. The central use case is DoH when pushed from an endpoint that= isn't a recursive resolver but there have been other proposals.
<= div>
For example www.example.com pushes you a AAAA record for img1.example.com. Should you use i= t? What if it is for img1.img-example.com ? Do the relationship between these domains ma= tter? What kind of relationship (i.e. it could be a domain relationship, or= in the context of a browser it might be a first-party tab like relationshi= p, etc..)? What are the implications of poison? Trackers? Privacy of reques= ts never made? Speed? Competitive shenanigans or DoS attacks?
This was out of scope for DoH.

We&#= 39;ll do the meeting over 1 hour in the Dorchester room from 16:30 to 17:30= on Monday July 16th.

This is a meeting of int= erested folks looking to see if we can agree on next steps - we're not = going to work out the details (nor should a side meeting try and do so). so= we'll have a tight agenda that I suggest organizaing as follows:
=

1] What forms of transport could be in scope? HTTP/2 pu= sh is one such vector, but I've heard others. Spray paint for example.<= br>

2] What needs to be considered when using such= data? (signatures? scope? etc?)

3] Who are the st= akeholders for 1 + 2?

4] Is there enough interest = to explore further? Next steps as output

I hop= e you can come!

-Patrick


--000000000000b8220f057211c472-- --000000000000b82213057211c474 Content-Type: text/plain; charset="US-ASCII"; name="side_meeting_notes.txt" Content-Disposition: attachment; filename="side_meeting_notes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jjpujtvq1 UGF0cmljazogTXkgZ29hbCBpcyB0byBmaW5kIHdoZXRoZXIgdGhlcmUgYXJlIGVub3VnaCBpbnRl cmVzdGVkIHBlb3BsZSB0byB0cnkgdG8gc29sdmUgc29tZXRoaW5nLgpNeSB1c2UgY2FzZSBpcyB2 ZXJ5IHNpbXBsZTogc2tpcHBpbmcgYW4gb24tdGhlLXdpcmUgRE5TIGV4Y2hhbmdlIGNhbiBwcm92 aWRlIGJldHRlciBzZWN1cml0eSwgcHJpdmFjeSwgYW5kIHBlcmZvcm1hbmNlLiAgQ2FuIHdlIGRv IGl0IHNhZmVseT8KClBhcnQgMTogV2hhdCBhcmUgdGhlIHBvc3NpYmxlIHVzZSBjYXNlcyBhbmQg dHJhbnNwb3J0cz8gIEhUVFAvMiBQVVNIPwpQYXJ0IDI6IFdoZW4gaXMgaXQgc2FmZSB0byB1c2Ug dGhlc2UgcmVjb3Jkcz8KCkRLRzogSSB0aGluayB0aGlzIGlzIHBvdGVudGlhbGx5IHVzZWZ1bCBp biBhIGxvdCBvZiBkaWZmZXJlbnQgcGxhY2VzLiAgV2UgbmVlZCB0byBiZSB2ZXJ5IGNsZWFyIGFi b3V0IHRoZSBjb250ZXh0IG9mIHRoZSBkYXRhLiAgTm90IG9ubHkgImlzIGl0IGFjY2VwdGFibGUg ZGF0YT8iLCBidXQgIndoZW4gbWlnaHQgdGhpcyBkYXRhIGJlIHVzYWJsZT8iLiAgSW4gVExTLCB3 ZSB3ZXJlIGp1c3QgdGFsa2luZyBhYm91dCBETlNTRUMtY2hhaW4gVExTIGV4dGVuc2lvbiwgYnV0 IHRoZXJlIHdpbGwgYmUgbWFueSBvdGhlciBvcHBvcnR1bml0aWVzLiAgV2UgaGF2ZSB0bwoKSm9o biBSaWNoYXJkc29uOgpJJ20gcmVhbGx5IGNvbmNlcm5lZCB0aGF0IGRvaW5nIEROUyBvdmVyIERP SCBpbnRyb2R1Y2VzIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgaW50ZXJuZXQgbG9va2luZyBkaWZm ZXJlbnQgZGVwZW5kaW5nIG9uIHdoaWNoIHdlYnBhZ2UgeW91J3JlIHVzaW5nIGF0IGEgZ2l2ZW4g dGltZS4gIFdlIG5lZWQgdG8gdGFsayBhYm91dCB3aGV0aGVyIHdlIHdpbGwgaG9ub3IgdGhlIHRy YWRpdGlvbmFsIHNpbmdsZSByb290IG9mIEROUy4KClBhdWwgSG9mZm1hbjoKSSB0aGluayB3ZSdy ZSBnb2luZyB0byBoYXZlIGFuIGlzc3VlIHRoYXQgdGhlIHN1YmplY3QgbGluZSBzYWlkICJSZXNv bHZlcmxlc3MiLCBhbmQgaW4gRE9IIHRoZXJlIGlzIGEgcmVzb2x2ZXIgKHRoZSBIVFRQIHNlcnZl cikuICBXZSBoYXZlIHR3byB1c2UgY2FzZXMgaGVyZTogdGhlIG9uZSB0aGF0J3MgYWN0dWFsbHkg InJlc29sdmVybGVzcyIgYW5kIERPSCB3aGVyZSB0aGVyZSBpcy4KCkRLRzogSSB0aGluayB3ZSdy ZSB0YWxraW5nIGFib3V0IGdldHRpbmcgRE5TIGZyb20gcGxhY2VzIHdoZXJlIHdlIGhhdmVuJ3Qg Z290dGVuIEROUyBpbiB0aGUgcGFzdCwgZS5nLiBIVFRQLzIgUFVTSCBmcm9tIGEgcmFuZG9tIHdl YnNpdGUuICBJIGRpZG4ndCBhc2sgZm9yIHRob3NlIHJlY29yZHMuCgpQYXVsIEhvZmZtYW46IFRo YXQgc2l0ZSB3YXMgbm90IGEgY29uZmlndXJlZCBET0ggc2VydmVyLgoKUGF0cmljazogUmlnaHQs IHRoaXMgaXMgYWJvdXQgYSBjYXNlIHdoZXJlIHlvdSBnZXQgYSByZWNvcmQgZnJvbSBhIHNlcnZl ciB0aGF0IGlzIG5vdCBjb25maWd1cmVkLiAgRG8gd2Ugd2FudCB0byB0YWtlIGEgbmV4dCBzdGVw IHRvIGdpdmUgdGhhdCBzb21lIG1lYW5pbmcuCgpKb2huOgpZb3UgdGFsa2VkIGFib3V0ICJ3aGVy ZSB0aGUgRE5TIGNvbWVzIGZyb20iLiAgRG8geW91IG1lYW4gdGhlIHNlcnZlciwgb3IgdGhlIHpv bmU/ICBJbiBteSBtaW5kLCBpdCBjb21lcyBmcm9tIHRoZSBhdXRob3JpdGF0aXZlIHNlcnZlci4K CkRLRzoKSSBtZWFudCB0aGF0IHRoZSBjaGFubmVsIGJ5IHdoaWNoIHRoZSBhcHBsaWNhdGlvbiBy ZWNlaXZlZCB0aGUgcmVjb3JkIG1heSBub3QgYmUgaW5kaWNhdGl2ZSBvZiBob3cgcmVsaWFibGUg aXQgaXMuCgpUYWxlOgpZb3UgZG9uJ3QgbmVjZXNzYXJpbHkgbmVlZCBhIHJlc29sdmVyIGluIHRo YXQgcGlwZWxpbmUuICBJZiB5b3UncmUgdGFsa2luZyB0byBhIENETiwgdGhleSBjYW4gdGVsbCB5 b3UgaW5mb3JtYXRpb24gYWJvdXQgem9uZXMgdGhhdCB0aGV5IGhvc3QsIHdpdGggRE5TU0VDIHNp Z25hdHVyZXMsIHdpdGhvdXQgZXZlciBoYXZpbmcgdG8gYXNrIGEgcmVzb2x2ZXIgYmVjYXVzZSB0 aGV5IGFscmVhZHkgaGF2ZSB0aGUgbWFwcGluZy4gIEl0IHNob3VsZCBiZSBjb25zaXN0ZW50IHdp dGggd2hhdCB5b3Ugd291bGQgZ2V0IGlmIHlvdSBhc2tlZCBvdmVyIHRoZSBETlMgcHJvdG9jb2wu CgpNaWtlIEJpc2hvcDoKQW5kIHRoYXQncyB3aGVyZSB3ZSBnZXQgaW50byBzb21lIGRldGFpbHMs IGJlY2F1c2UgZGVwZW5kaW5nIG9uIGNsaWVudCBJUCB5b3UncmUgZ29pbmcgdG8gZ2V0IGRpZmZl cmVudCByZXNwb25zZXMgZGVwZW5kaW5nIG9uIHdobyBhc2tzLiAgV2l0aCBBbHQtU3ZjIHlvdSBj YW4gYWxyZWFkeSBnZXQgYW5zd2VycyB0aGF0IHlvdSBtaWdodCBuZXZlciBnZXQgdGhyb3VnaCB0 aGUgRE5TLiAgQW4gZXhhbXBsZSBpcyBjb2FsZXNjaW5nOiBSRkMgNzU0MCBzYXlzIHRvIGNoZWNr IHRoZSBETlMgcmVjb3JkcyBiZWZvcmUgeW91IGNvYWxlc2NlIGV2ZW4gaWYgdGhleSdyZSBhbGwg b24gdGhlIHNhbWUgY2VydGlmaWNhdGUuICBCdXQgc29tZSBwcm9wZXJ0aWVzIHdvdWxkIGxpa2Ug dG8gcm91dGUgZGlmZmVyZW50IHVzZXJzIHRvIGRpZmZlcmVudCBJUCBhZGRyZXNzZXMgYnV0IGFs c28gYWxsb3cgY29hbGVzY2luZy4KClNhcmE6ClRoaXMgaXMgYSB2ZXJzaW9uIG9mIHNwbGl0IGhv cml6b24uCgpUYWxlOgpDb25zaXN0ZW50IHdpdGggdGhlIEROUyBidXQgbm90IGlkZW50aWNhbC4g IFRvIHRoZSBleHRlbnQgdGhhdCB5b3UgYXJlIG1ha2luZyBhbiBhdHRlc3RhdGlvbiBhYm91dCBh IG5hbWUgdW5kZXIgYSBwYXJ0aWN1bGFyIGRvbWFpbiwgdGhhdCBjb21lcyBmcm9tIHRoZSBJQ0FO TiBzdXBlcnN0cnVjdHVyZS4KClBhdHJpY2s6CkluIEhUVFBTLCBXZWJQS0kgaXMgdGhlIHNlY3Vy aXR5IHN5c3RlbS4gIFdlIGFsbG93IElQIE1JVE0gYmVjYXVzZSB0aGF0J3Mgbm90IHBhcnQgb2Yg dGhlIGF1dGhlbnRpY2F0aW9uIG1vZGVsLiAgSWYgdGhhdCdzIHlvdXIgc2VjdXJpdHkgbW9kZWws IHlvdSBtYXkgbm90IGJlIGFsbCB0aGF0IGNvbmNlcm5lZCBhYm91dCBhdHRlc3RhdGlvbi4gIFRo ZXJlIG1heSBiZSBvdGhlciBjb25jZXJucywgYnV0IGl0J3Mgbm90IG5lY2Vzc2FyaWx5IGFib3V0 IGF1dGhlbnRpY2F0aW9uIG9mIHlvdXIgcGVlci4gIENvbmNlcm5zIGxpa2UgY29tcGV0aXRpdmUg aXNzdWVzIChjYXB0dXJpbmcgdHJhZmZpYyksIGVudGl0aWVzIGJlaW5nIGFibGUgdG8gYWRkIHRo ZW1zZWx2ZXMgdG8gdGhlIHBhdGgsIGFtcGxpZmljYXRpb24gb2YgbG9zcyBvZiBjZXJ0aWZpY2F0 ZSBpc3N1ZXMuICBCdXQgdGhlIHVzZSBjYXNlIG9mIGFsbG93aW5nIGV4YW1wbGUuY29tIHRvIHNl bmQgYSByZWNvcmQgZm9yIGFuYWx5dGljcy5leGFtcGxlLmNvbSBpcyBoaWdobHkgdmFsdWFibGUu Cgo6CldlIG5lZWQgdG8gc2VwYXJhdGUgdGhlIGlkZWEgb2YgYXV0aG9yaXRhdGl2ZW5lc3MuICBZ b3UgbWlnaHQgZ2V0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgYW5zd2VyIHRoaXMgd2F5IHZzIHBv cnQgNTMuICBJZiB3ZSBjYW4gbWFrZSBpdCB0aWVkIHRvIHRoYXQgd2ViIHNlc3Npb24sIHRoZW4g d2hvIGNhcmVzIGlmIGl0J3MgZGlmZmVyZW50PyAgVGhleSdyZSBhbHJlYWR5IGRvaW5nIGdlb2xv Y2F0aW9uIHN0ZWVyaW5nLCBzbyB0aGlzIGlzIGp1c3QgZG9pbmcgdGhhdCBvbiBzdGVyb2lkcy4g IFlvdSBtYXkgd2VsbCBnZXQgc29tZXRoaW5nIGJhY2sgd2l0aCBhIEROU1NFQyBzaWduYXR1cmUu CgpQYXVsOgpUbyBhbXBsaWZ5IHdoYXQgeW91IHNhaWQsIHdlIG1heSBiZSByYXRob2xpbmcgZWFy bHkgb24gdGhlIEROU1NFQyBhbmQgYXV0aG9yaXRhdGl2ZW5lc3MuICBCYWQgaWRlYSBmYWlyeTog d2UgY291bGQgYWRkIGFuIEVETlMwIG9wdGlvbiBpbmRpY2F0aW5nIHdoaWNoIGFzcGVjdHMgb2Yg dGhpcyBhbnN3ZXIgYXJlIHVuaXZlcnNhbCwgYW5kIGNhbiBiZSBzcHJheXBhaW50ZWQgb24gYSB3 YWxsLgoKREtHOgpJJ3ZlIGdvdCBzcHJheXBhaW50IGluIG15IGJhZyByaWdodCBub3cuCgpTaGFu ZToKRG8gd2UgaGF2ZSBpbnR1aXRpb24gZm9yIGhvdyB0aGlzIGNoYW5nZSB0byBhcmNoaXRlY3R1 cmUgaXMgZ29pbmcgdG8gYWZmZWN0IHRoZSBuZXR3b3JrIGF0IGxhcmdlPyAgUmVzb2x2ZXJzIGNh Y2hlLCB0aGV5J3JlIGVmZmljaWVudC4gIFdpbGwgdGhpcyBuZXcgYXJjaGl0ZWN0dXJlIGJlIG1v cmUgUDJQIGFuZCBzY2FsZSBldmVuIGJldHRlcj8gIE9yIG5vdD8KCk1pa2U6CklmIHlvdSBoYXZl IEgyIHB1c2hpbmcgYSByZXNvdXJjZSwgeW91IGhhdmUgdWx0aW1hdGUgY2FjaGluZywgYmVjYXVz ZSB0aGUgc2VydmVyIHdpbGwgdXBkYXRlIGl0cyByZXNvdXJjZSBldmVyeSAxNSBtaW51dGVzLCBh bmQgcHVzaCB0aGF0IHJlc291cmNlIHRvIGFsbCBjbGllbnRzLgoKU2hhbmU6CkJ1dCB5b3UgY291 bGQgYmUgcXVlcnlpbmcgM3JkIHBhcnR5IGRhdGEgdG9vLgoKTWlrZToKWW91IGNvdWxkLgoKU3Vi b2RoOgpUaGUgY29tcGVsbGluZyB1c2UgY2FzZSBmb3IgdXMgaXMgdGFyZ2V0aW5nLiAgV2UgZG8g RE5TLWJhc2VkIHRhcmdldGluZyBvZiB1c2VycyB3aGVuIHRoZXkgY29tZSBpbiBmcm9tIGEgc3Bl Y2lmaWMgSVAgc3VibmV0LCB3ZSBwdXNoIHJlY29yZHMgZm9yIHRoYXQgdXNlciB0byB2aXNpdCBh IFBPUCBuZWFyIHRoYXQgdXNlciwgaW5jbHVkaW5nIElTUCBwcmVmZXJlbmNlcyBmb3IgcGVlcmlu ZyBvciB0cmFuc2l0LCB3aGVyZSB0aGUgbGlua3MgaGF2ZSBjYXBhY2l0eSwgZXRjLiAgVGhpcyB3 b3VsZCBhbGxvdyB1cyB0byBtYWtlIG1vcmUgZmluZS1ncmFpbmVkIGRlY2lzaW9ucy4gIFRoZSBp bml0aWFsIEROUyBtaWdodCBiZSBzbG93ZXIgdnMuIHRoZSBJU1BzIGxvY2FsIGNhY2hpbmcgcmVz b2x2ZXIsIGJ1dCB0aGUgc3Vic2VxdWVudCByZXF1ZXN0cyBtaWdodCBiZWNvbWUgd2F5IGZhc3Rl ciBiZWNhdXNlIHRoZXkgd2VudCB0byBhIFBPUCB0aGF0IHdhcyBjbG9zZXIgb3IgbW9yZSBvcHRp bWFsLgoKREtHOwpJIGRvbid0IHRoaW5rIGFueW9uZSBpcyBwcm9wb3NpbmcgZG9pbmcgYXdheSB3 aXRoIHRoZSByZXNvbHZlcnMuICBObyBvbmUgaXMgaW1hZ2luaW5nIHJhZGljYWxseSByZXNoYXBp bmcgdGhlIGVudGlyZSBpbnRlcm5ldC4KClNoYW5lOgpJIHRoaW5rIGlmIHlvdSdyZSBlbnZpc2lv bmluZyBhbnkga2luZCBvZiBzdWNjZXNzIHRoZW4geW91IGRvIG5lZWQgdG8gdGhpbmsgYWJvdXQg aGF2aW5nIG1vcmUgYW5kIG1vcmUgdHJhZmZpYyBzaGlmdCB0byB0aGlzIG1vZGVsLiAgSWYgeW91 IHJlYWxseSBleHBlY3QgdGhpcyB0byBiZXVzZWZ1bCBpbiB0aGUgZ2VuZXJsYSBjYXNlIHRoZW4g eW91IG5lZWQgb3QgaW1hZ2luZSBpdCB0YWtpbmcgb3ZlciBhIHNpZ25pZmljYW50IGFtb3VudCBv ZiB0cmFmZmljOgoKVGFsZToKVGhpcyBoYXMgbWFqb3IgaW1wbGljYXRpb25zIGZvciB0aGUgYmln IHByb3ZpZGVycyBtYWtpbmcgdGhlaXIgbG9hZCBhbmQgZGVtYW5kIGVzdGltYXRlcywgY2FjaGUg aW50ZXJhY3Rpb25zLCBldGMuICBJdCBoYXMgc2lnbmlmaWNhbnQgYXJjaGl0ZWN0dXJhbCBpbXBs aWNhdGlvbnMgdGhhdCB3aWxsIHRlbmQgdG8gZmF2b3Igc29tZSBidXNpbmVzcyBtb2RlbHMgb3Zl ciBvdGhlcnMuCgpFcmlrOgpUd28gY2xhc3NlcyBvZiBwcm9ibGVtcywgcmVzb2x2ZXIgaXMgYSBy ZWQgaGVycmluZy4gIERvIHlvdSBrbm93IGdvIHRocm91Z2ggdGhlIGF1dGhvcml0YXRpdmUgcmVz b2x2ZXJzPyAgT3IgZG8geW91IHRyZWF0IHRoaXMgYXMgdGhlIGtpbGxlciBhcHAgZm9yIEROU1NF QywgaS5lLiB2ZXJpZmllZCByZWNvcmRzIGFyZSBnb29kIG5vIG1hdHRlciBob3cgeW91IGdldCB0 aGVtPyAgVGhhdCdzIG9uZSBjbGFzcyBvZiB0b3BpY3MuICBUaGUgb3RoZXIgY2xhc3MgaXM6IGhv dyBkbyB3ZSBoYW5kbGUgdHJhZmZpYyByb3V0aW5nIGlmIGEgY2xpZW50IGhhcyBhIG5hbWUgYW5k IHdhbnRzIHRvIGdldCBhIHJlc291cmNlPyAgSXQgc2VlbXMgbGlrZSB0aGVyZSdzIGEgbmV3IHR5 cGUgb2YgY2FtZWwgZm9ybWluZyBoZXJlLCBiZXR3ZWVuIEVDUywgQWx0LVN2YywgRE9ILCBETlM2 NC4gIEhhcHB5IGV5ZWJhbGwgdmFyaWFudHMsIGhhbmRsaW5nIG1hbnkgUlJzLCBjaG9vc2luZyBi ZXR3ZWVuIFFVSUMgYW5kIEgyLiAgTG90cyBvZiB3YXlzIHRvIGdvIGZyb20gYSBuYW1lIHRvIGEg Y29ubmVjdGlvbiAoY29ubmVjdGlvbiBjb2FsZXNjaW5nISkuICBDb21wbGV4aXR5IHRoZXJlIGlz IGdyb3dpbmcsIGFuIGVtZXJnZW50IHByb3BlcnR5IHdpdGggbm8gc2luZ2xlIHdvcmtpbmcgZ3Jv dXAuCgpCYXJyeSBHcmVlbjoKVGhlIGVuZCBnb2FsOiBXZSBidWlsdCB0aGUgRE5TIGluIGFuIGVy YSB3aGVuIG5ldHdvcmtzIHdlcmUgbm90IHZlcnkgc3RhYmxlLiAgSWYgYSBodXJyaWNhbmUgY29t ZXMgdGhyb3VnaCBhbmQgdGFrZXMgYW4gSVNQIG9mZmxpbmUsIHRoaW5ncyBzaG91bGQgd29yay4g IElmIG15IEROUyBpcyBhbGwgaGFuZGxlZCBpbi1hcHAgb3ZlciBIVFRQIGJ5IGV2ZXJ5IGFwcCwg dGhlbiBJIGhhdmUgYW4gZXh0ZXJuYWwgZGVwZW5kZW5jeSBmb3IgcmVzaWxpZW5jZSBvZiBteSBu ZXR3b3JrLiAgTGV0cyBkbyBhbGwgRE5TIGxvb2t1cCBmb3IgV2hhdHNhcHAgaW4gV2hhdHNhcHAs IGJ1dCBpbiBhIGh1cnJpY2FuZSwgd2hhdCdzIG15IHJlY292ZXJ5IG1vZGVsPwoKV2hhdCdzIHRo ZSBlbmQgZ29hbD8gIFdoZXJlIGFyZSB3ZSBoZWFkaW5nIHdpdGggdGhpcz8KCkRLRzoKSSBlbnZp c2lvbiB0aGlzIGFzIGFuIGFkZGl0aXZlIHNldCBvZiBwbGFjZXMgd2hlcmUgSSdtIHdpbGxpbmcg dG8gYWNjZXB0IEROUyByZWNvcmRzLiAgSXQgc291bmRzIHRvIG1lIGxpa2UgeW91J3JlIHNheWlu ZyB0aGF0IGlmIHdlIG1ha2UgdGhpcyB3b3JrLCB0aGVuIEknbSBnb2luZyB0byBsb3NlIG15IHRy YWRpdGlvbmFsIEROUyBjaGFubmVsLiAgSSBkb24ndCBrbm93IHdoeSB3ZSB3b3VsZCBsb3NlIGl0 LgoKU2FyYToKT24gRE5TU0VDOiBvbmUgb2YgdGhlIHVzZSBjYXNlcyBpcyBjb21wbGV0ZSB1bnNp Z25lZCBkYXRhLCBzbyBJJ2QgbGlrZSB0byBjbGVhciB0aGF0IHVwLgoKUGF0cmljazoKTm8gbGlt aXRzIGluIHRoaXMgY29udmVyc2F0aW9uLCBidXQgaW4gYSBXRyB3ZSBjb3VsZCBtYWtlIEROU1NF QyBtYW5kYXRvcnksIHRoYXQgd291bGQgYmUgaW4gc2NvcGUuCgpTYXJhOgpJIHRoaW5rIFNoYW5l J3MgcmlnaHQ6IGlmIHRoaXMgd29ya3MsIHdoeSB3b3VsZCB5b3UgZ28gdG8gdGhlIG90aGVyIGNo YW5uZWwgdW5sZXNzIHlvdSdyZSBpbiBhIGRpc2FzdGVyIG1vZGU/ICBJZiBldmVyeSBhcHAgZG9l cyB0aGlzLCB3aGF0J3MgbGVmdCB0byB0aGUgc3lzdGVtIHJlc29sdmVyPwoKSm9objoKV2hhdCBk byB5b3UgbWVhbiBieSBjb250ZXh0PyAgQXJlIHdlIHRhbGtpbmcgYWJvdXQgYSB3ZWJwYWdlLCBv ciB0aGUgY29udGV4dCBvZiB0aGUgd2hvbGUgb3BlcmF0aW5nIHN5c3RlbT8KClBhdWw6Ckl0IHNv dW5kcyBsaWtlIHRoZSBtYWluIHVzZSBjYXNlIGlzICJmYXN0ZXIiLiAgVGhpcyBpcyBhIHNlcnZl ciBwdXNoaW5nIHJlY29yZHMgdG8gbWFrZSB0aGluZ3MgZmFzdGVyLgoKUGF0cmljazoKRmFzdGVy IGFuZCBtb3JlIHByaXZhdGUuCgpQYXVsOgpMZXQncyBzcGxpdCB0aG9zZSBvdXQuICAiZmFzdGVy IiBjb3VsZCBiZSBoYW5kbGVkIGJ5IGRvdWJsZS1jaGVja2luZyB0aHJvdWdoIHRoZSByZWd1bGFy IEROUy4gIFRoYXQgZG9lc24ndCB3b3JrIGZvciAicHJpdmF0ZSIuICBUaGVyZSBtaWdodCBiZSBj bGFzc2VzIG9mIGRhdGEgdGhhdCBhcmVuJ3QgcHJpdmFjeS1zZW5zaXRpdmUgdGhvdWdoLiAgTGV0 J3Mgbm90IHRlbGwgdGhlIHVzZXJzIHdoYXQgdGhlaXIgdXNlIGNhc2VzIGFyZS4KCk15IGZpcnN0 IGd1ZXNzIGlzIHRoYXQgcGVvcGxlIHdhbnQgdG8gcHVzaCB0aGlzIGZvciAiZmFzdGVyIiwgYW5k IHByaXZhY3kgaXMgYSBzZWNvbmRhcnkgY29uc2lkZXJhdGlvbiwgYnV0IHRoZXJlIGFyZSBhbHNv IHBlb3BsZSB3aG8gd2FudCB0aGlzIGZvciBwcml2YWN5IGZpcnN0LgoKUGF0cmljazoKSSB0aGlu ayB0aGUgcXVlc3Rpb24gb2YgY29udGV4dCBvciBzY29wZSBpcyBhIGRlc2lnbiBxdWVzdGlvbi4g IE9uZSBwb3RlbnRpYWwgY29udGV4dCBpcyAiaHR0cHMgd2l0aGluIGEgd2ViIGJyb3dzZXIgdGFi IiwgaS5lLiBzZXBhcmF0ZWQgZnJvbSBvdGhlciBwYXJ0cyBvZiB0aGUgYnJvd3Nlci4gIEFub3Ro ZXIgaXMgIndob2xlIGJyb3dzZXIiIG9yICJ3aG9sZSBPUyIsIGFuZCB0aG9zZSBhcmUgdmVyeSBk aWZmZXJlbnQuCgpBcyBmb3IgdG90YWxseSByZW1vdmluZyByZXNvbHZlci1iYXNlZCBETlMsIHNl cnZlcnMgZG9uJ3Qga25vdyBhbGwgdGhlIG5hbWVzIHlvdSB3aWxsIG5lZWQuICBUaGV5IGtub3cg dGhlIG1vc3Qgb2J2aW91cyBvbmVzLiAgVGhlcmUgd2lsbCBhbHdheXMgYmUgbWlzc2VzLCBzbyB3 ZSdsbCBhbHdheXMgbmVlZCByZXNvbHZlcnMuCgo/Pz86CkN1cnJlbnRseSwgc3R1YnMgYXJlIGR1 bWIgd2l0aCByZXNwZWN0IHRvIEROU1NFQy4gIFdpbGwgd2UgZ2l2ZSBhcHBsaWNhdGlvbnMgdGhl IGFiaWxpdHkgdG8gdmFsaWRhdGUgRE5TU0VDPyAgQXMgYSBjbGllbnQgSSB3b3VsZCBsaWtlIHRv IGRvIGl0IG15c2VsZi4gIElzIHRoYXQgcG9zc2libGU/CgpQYXVsOgpZZXMuCgpSYXk6CmlmIHdl IGRvIGhhdmUgdGhlIHNpdHVhdGlvbiBvZiBzZXJ2ZXJzIHB1c2hpbmcgcmVjb3Jkcywgd2UnbGwg bG9zZSBSUFouICBJdCdzIGNvbW1vbiBmb3IgcGVvcGxlIHRvIHVzZSBETlMgc2VydmVycyB0aGF0 IGZpbHRlciBETlMgZm9yIGJvdG5ldHMuCgpTdWJvZGg6CkluIGFkZGl0aW9uIHRvIHByaXZhY3kg YW5kICJmYXN0Iiwgd2UgYWxzbyBuZWVkIHRvIHRhbGsgYWJvdXQgZGl2ZXJzaXR5LiAgQXMgd2Ug Z28gaW50byB0aGUgRE9IIHNwYWNlLCB3ZSBvbmx5IGhhdmUgb25lIGJyb3dzZXIgYW5kIG9uZSBy ZXNvbHZlciByaWdodCBub3cuICBOb3QgY2xlYXIgaG93IHdlIHdvdWxkIGdldCBtb3JlIGFuZCBi b290c3RyYXAgdGhlbS4gIFRoaXMgaXMgb25lIHBhdGggdG8gZ2V0IGJvb3RzdHJhcHBpbmcgYW5k IGdldCBtb3JlIEROUyBlbnRyaWVzLgoKRXJpazoKT24gdGhlIFJQWiBxdWVzdGlvbiwgdGhhdCdz IGNlcnRhaW5seSByZWxldmFudCBoZXJlLCBidXQgaXQncyBhbHNvIHJlbGV2YW50IHRvIERPSC4g IEZvciB0aGUgbm9ybWFsIHVzZSBjYXNlLCBpcyB0aGVyZSBhIHN0YW5kYXJkaXplZCB3YXkgdG8g Y29uZmlndXJlIGEgY2xpZW50IHRvIHVzZSBhIHRydXN0ZWQgcmVzcG9uc2UgcG9saWN5IHNlcnZl cj8gIE90aGVyd2lzZSwgZW50ZXJwcmlzZSBvciBob21lIGZpbHRlcmluZyB3aWxsIGxvc2UgdGhl IHVzZSBvZiBETlMgaGFzIGEgcG9saWN5IHRvb2wuICBXZSBuZWVkIGhvb2tzIHNvIHRoZSBwZW9w bGUgd2hvIGNvbnRyb2wgdGhvc2UgZW5kcG9pbnRzIGRvbid0IGxvc2UgdGhhdC4KClJheToKSSB3 b3VsZG4ndCBsaWtlIHRvIGhhdmUgdGhlIFJQWiBjaG9pY2UgZGVsZWdhdGVkIHRvIHRoZSBjbGll bnQuCgpQYXRyaWNrOgpXZSBoYXZlIHN0YWtlaG9sZGVycyByZXByZXNlbnRlZCBmb3IgQ0ROcywg YnJvd3NlcnMsIGFuZCB3ZWJzaXRlIG9wZXJhdG9ycywgYnV0IG5vdCBJU1BzIG9yIG5ldHdvcmsg b3BlcmF0b3JzLgoKTW5vdDoKV2hlbiBsZXNzIGluZm9ybWF0aW9uIGlzIGV4cG9zZWQsIElTUHMg YWx3YXlzIHNlZW0gdG8gc2F5IHRoZXkgZG9uJ3QgY2FyZS4gIEl0J3MgZW50ZXJwcmlzZXMsIHNj aG9vbHMsIGhvbWVzLCBhbmQgcHJpc29ucyB3aG8gYXJlIGdvaW5nIHRvIGNhcmUgbW9yZSB0aGFu IElTUHMuCgpQYXRyaWNrOgpEbyB5b3UgdGhpbmsgcmVzb2x2ZXJsZXNzIEROUyBpcyBpbnRlcmVz dGluZyBpbiBhbiBpbmNyZW1lbnRhbCB3YXkgdG8gdGhlIHVzZSBvZiBvcGVuIHJlc29sdmVycywg b3IgaXMgaXQgYSBkaWZmZXJlbnQgcHJvYmxlbT8gIEkgdGhpbmsgaXQncyB0aGUgc2FtZSBwcm9i bGVtLgoKTU5PVDoKWWVzLCBpZiBJIGJsb2NrIHBvcnQgNTMgZm9yIG15IGtpZHMsIHRoZW4gRE9I IGlzIGFscmVhZHkgYSBwcm9ibGVtLgoKOgpOQVQ2NCBpcyBhbHNvIGEgcHJvYmxlbSwgaW4gYWRk aXRpb24gdG8gUlBaLiAgVGhpcyBpcyBhbGwgdHJ5aW5nIHRvIGdldCBwYXN0IHRoYXQsIGFuZCBp dCdzIGdvaW5nIHRvIGVuZCB1cCBicmVha2luZy4gIFdlJ3ZlIGZpeGVkIGEgbG90IG9mIHRoaW5n cyBieSBicmluZ2luZyB0aGUgZml4ZXMgY2xvc2UgYW5kIHlvdSd2ZSBnb3QgdG8gYmUgY2FyZWZ1 bCBoZXJlLgoKQmFycnk6CldpdGggb3BlcmF0b3IgaGF0IG9uLCBJIHRoaW5rIHlvdXIgcGVyc3Bl Y3RpdmUgaXMgVVMvRVUuICBUaGUgQVBBQyBvcGVyYXRvcnMgYXJlIG1hbmlwdWxhdGluZyBETlMg Zm9yIGZpbHRlcmluZyBhbmQgY2Vuc29yc2hpcCwgc28gaWYgeW91IHNheSB5b3UncmUgZ29pbmcg dG8gYnlwYXNzIHRoYXQgdGhlIG9wZXJhdG9ycyBhcmUgZ29pbmcgdG8gY29tcGxhaW4uICBBbm90 aGVyIGNvbnN0aXR1ZW50IHdlIG5lZWQgdG8gaW5jbHVkZSBpcyBteSBtb20sIHdobyBpcyBnb2lu ZyB0byB3YW50IHRvIGtub3cgd2h5IHNvbWV0aGluZyBkb2Vzbid0IHdvcmsgaW4gb25lIHBhcnRp Y3VsYXIgdGFiPyAgVGhpcyBpcyBjcmVhdGluZyBjb21wbGV4aXR5IHBlci1hcHAsIHBlci10YWIg dGhhdCB3aWxsIGJlIGhhcmQgdG8gc3VwcG9ydC4KClBhdHJpY2s6Ckl0J3MgYSB0cnVpc20gdGhh dCBldmVyeSBsZXZlbCBpbiBhbiBpbnRlcm5ldCBleGNoYW5nZSBjbGFpbXMgdGhhdCB0aGUgY3Vz dG9tZXIgY2FsbHMgdGhlbSBmaXJzdC4KClBhdWw6CldlIHN0YXJ0ZWQgd2l0aCAid2hlcmUgbWln aHQgd2UgYmUgZ2V0dGluZyB0aGlzIGRhdGEiPyAgTGV0J3MgbGltaXQgdGhpcyB0byBIVFRQLgoK REtHOgpJIHRoaW5rIHRoYXQgYW4gaW50ZXJlc3RpbmcgdGhvdWdodCBleHBlcmltZW50IHdvdWxk IGJlIHRvIGRlZmluZSB0aGUgbmFycm93ZXN0IHBvc3NpYmxlIHNjb3BlIHdoZXJlIHNvbWV0aGlu ZyBsaWtlIHRoaXMgbWlnaHQgYmUgaW50ZXJlc3RpbmcuICBJZiB0aGF0IG1lYW5zICJ3aXRoaW4g b25lIHRhYiIsIEhUVFBTLW9ubHksIEROU1NFQy1zaWduZWQsIGhvcGVmdWxseSBhdCBzb21lIHBv aW50IHdlIGNhbiBmaW5kIHNvbWV0aGluZyB0aGF0IGRvZXNuJ3QgbWFrZSB0b28gbWFueSBvYmpl Y3Rpb25zLCBhbmQgdGhlbiBtYXliZSB3ZSBjYW4gd2FsayBpdCBvdXQuCgpQYXRyaWNrOgpXaXRo IGRlbGVnYXRlZCBzaG9ydC1saXZlZCBjZXJ0cy4KClN1Ym9kaDoKQmV5b25kICJETlNTRUMgd2ls bCBzb2x2ZSBhbGwgb3VyIHByb2JsZW1zIiwgdGhlIG90aGVyIHRoaW5nIGlzIHRoZSBPUklHSU4g ZnJhbWUgZGlzY3Vzc2lvbnMuICBJZiB3ZSdyZSBzY29waW5nIHRoaXMgdG8gSFRUUC1vbmx5LCB0 aGVuIHdlIG1pZ2h0IHdhbnQgdG8gYXBwbHkgdGhlIHNhbWUgY29uc2lkZXJhdGlvbnMgYXMgT1JJ R0lOIGZyYW1lLCBwbHVzIG1heWJlIHNvbWV0aGluZyBmb3Igd2lsZGNhcmQgaGFuZGxlcnMuICBJ dCBpcyBzbGlnaHRseSBkaWZmZXJlbnQgaW4gdGVybXMgb2Ygd2hvIGNhbiBtb3VudCBhbiBhdHRh Y2suCgpQYXRyaWNrOgpleGFtcGxlLmNvbSBjb3VsZCBwdXNoIGEgRE5TU0VDLXNpZ25lZCByZWNv cmQgZm9yIGdtYWlsLmNvbS4gIE90aGVyd2lzZSBpdCB3b3VsZCByZWx5IG9uIFdlYlBLSS4gIEl0 IGNvdWxkIHB1Ymxpc2ggdGhlIElQIG9mIGl0c2VsZiwgd2hpY2ggZXhhbXBsZS5jb20gY291bGQg bm90IHByb2R1Y2UgYSB2YWxpZCBjZXJ0IGZvciwgYnV0IGl0IGNvdWxkIGZvcndhcmQgdGhlIHBh Y2tldHMgdG8gZ21haWwgYW5kIGFjdCBhcyBhIG5ldHdvcmstbGV2ZWwgTUlUTS4gIE1heWJlIHRo YXQncyB3aHkgd2Ugd2FudCBETlNTRUMuCgpTdWJvZGg6CkRvaW5nIHRoaXMgYXQgc2NhbGUgd291 bGQgYmUgaGFyZAoKUGF0cmljazoKQnV0IHlvdSBjYW4gdGFyZ2V0IHRoaXMuCgpFcmlrOgpUbyBE S0dzIHRob3VnaHQgZXhwZXJpbWVudDogaWYgeW91IHRoaW5rIG9mIGV2ZXJ5dGhpbmcgaW4gYSB0 YWIgYXMgc3RhdGVsZXNzIGl0IG1pZ2h0IHdvcmssIGJ1dCBvbmNlIHlvdSBoYXZlIHN0YXRlIGl0 IGdldHMgbWVzc2llci4gIFdoYXQgaWYgYSByZXNvdXJjZSBpbiB0aGUgdGFiIGFsdGVycyB0aGUg b3JpZ2luIHN0YXRlPyAgTm93IHlvdSBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIGFuIGFkIHBpeGVs IGxlYWtzIGluZm9ybWF0aW9uIHRvIG90aGVyIHRhYnMuCgpUaGF0IG1pZ2h0IGJlIHNvbWV0aGlu ZyB3aGVyZSB3ZSBuZWVkIHRvIGxvb2sgZXZlbiBuYXJyb3dlciwgZS5nLiBvbmx5IHRvIHByaXZh dGUgYnJvd3NpbmcgbW9kZS4gIFRoYXQgbWlnaHQgYmUgYSBwbGFjZSB0byBsb29rIGF0IGZpcnN0 LiAgVGhpcyBhbHNvIGdvZXMgdG8gdGhlIG9yaWdpbmFsIG1vdGl2YXRpb24gZm9yIHRoZSBPUklH SU4gZnJhbWU6IHNvbWUgd2FudGVkIHRvIGV4cGFuZCB0aGUgb3JpZ2luLCBhbmQgc29tZSB3YW50 ZWQgdG8gc2hyaW5rIGl0IGR1ZSB0byBjb3JuZXIgY2FzZXMgd2l0aCBjb25uZWN0aW9uIGNvYWxl c2NpbmcuICBGb3IgZXhhbXBsZSwgc29tZSBicm93c2VycyB3aWxsIGNvYWxlc2NlIGlmIHRoZSBS UnNldHMgb3ZlcmxhcCwgZXZlbiBpZiB0aGUgYWN0dWFsIElQIGluIHVzZSBpc24ndCBhdmFpbGFi bGUgaW4gYm90aC4gIE9yIGNvYWxlc2NpbmcgaW4gSVBWNiB3aGVuIGl0IG9ubHkgd29ya3MgaW4g SVB2NC4gIFRoaXMgaXMgYSBncmVhdCB1c2UgY2FzZSBmb3IgT1JJR0lOIGZyYW1lLgoKUGF0cmlj azoKVG8gdGhlIGV4dGVudCB0aGF0IE9SSUdJTgoKQmVuOgpXZSBuZWVkIHRvIGNvbnNpZGVyIGEg c3VwZXJjb29raWUgYXR0YWNrLCB3aGVyZSBhIHNlcnZlciBwdXNoZXMgYSAoRE5TU0VDLXNpZ25l ZCkgcmVjb3JkIHRoYXQncyB1bmlxdWUgZm9yIGVhY2ggY2xpZW50LCBhbmQgdGhlbiB1c2VzIGEg dHJhY2tpbmcgcGl4ZWwgZm9yIHRoZSBkb21haW4gdG8gY3JlYXRlIGEgc3VwZXJjb29raWUgdGhh dCBmb2xsb3dzIHRoZW0gYXJvdW5kIHRoZSB3ZWIuICBCcm93c2VyIHNvY2tldCBwb29scyBtaWdo dCBub3QgYmUgZGVzaWduZWQgdG8gbGltaXQgdGhlIHVzZSBvZiBhIEROUyByZWNvcmQgdG8gYSBz cGVjaWZpYyBzY29wZSwgc28gZGVmZW5kaW5nIGFnYWluc3QgdGhpcyB3b3VsZCByZXF1aXJlIGFk ZGluZyBhIG5ldyBmZWF0dXJlIHRvIHRoZSBzb2NrZXQgcG9vbHMgdG8gcHJldmVudCByZXF1ZXN0 IGNvYWxlc2NpbmcgZnJvbSBkaWZmZXJlbnQgY29va2llIHNjb3BlcyBvbiB0aGVzZSBzb2NrZXRz LgoKREtHOgpXb3VsZG4ndCBBbHQtU3ZjIGFscmVhZHkgaGF2ZSB0aGlzIHByb2JsZW0/CgpNTk9U OgpGaW5nZXJwcmludGluZyBpc3N1ZSBpcyB0b3VnaC4gIFNlZ3JlZ2F0aW5nIHNvY2tldHMgaXMg Y29udHJvdmVyc2lhbC4gIEl0J3Mgd29ydGggdGFsa2luZyBhYm91dC4gIEkgYWxzbyBrbm93IHRo YXQgc29tZSBtZW1iZXJzIG9mIENocm9tZSBTZWN1cml0eSBoYXZlIGZhaXJseSBkZWVwbHkgaGVs ZCBiZWxpZWZzIGFib3V0IHRoZSB3aXNkb20gb2YgdGhpcyBhcHByb2FjaC4gIFdlIHNob3VsZCBt YWtlIHN1cmUgdG8gZ2V0IHRoZWlyIGlucHV0LgoKREtHOgpJIHdhbnRlZCB0byBvYnNlcnZlIGEg ZGlmZmVyZW50IGJldHdlZW4gIkROU1NFQy1zaWduZWQgcmVjb3JkcyBmb3IgdGhlIC82NCIgdnMu IEFsdC1TdmMuICBJZiBnZXQgdGhlIHNpZ25lZCByZWNvcmRzIEkgY2FuIHJlcGxheSB0aGF0IHRv IGFueWJvZHkgZWxzZSwgd2hpY2ggY291bGQgZ2VuZXJhdGUgY29uZnVzaW9uIGFuZCByZW1vdmUg dGhlIGlkZW50aWZpZXIuICBJZiB3ZSdyZSBhc2tpbmcgZm9yIEROU1NFQy1zaWduZWQgcmVjb3Jk cy4gIFRoYXQgZ2l2ZXMgdXMgdGhlIG9wcG9ydHVuaXR5IHRvIHVzZSBzb21lIGtpbmQgb2YgdHJh bnNwYXJlbmN5IG1vZGVsIHRvIHRyeSB0byBkZXRlY3QgYmFkIGJlaGF2aW9yLgoKUGF0cmljazoK SSB3b3VsZCBsaWtlIHRvIGdldCBhIG1haWxpbmcgbGlzdCB0byBmb2N1cyBvbiBES0cncyBjb25z aWRlcmF0aW9uIG9mIHRoZSBtaW5pbXVtIHVzZWZ1bCBjYXNlLiAgSWYgd2UgY2FuIGZpbmQgYSBt aW5pbWFsIGNhc2UgdGhhdCdzIHdvcnRoIGFkdmFuY2luZyB0aGVuIG1heWJlIHdlIGNhbiBoYXZl IGEgQm9GLgoKSm9objoKV2h5IG5vdCBET0g/CgpQYXRyaWNrOgpUaGlzIHdvcmsgaXMgc3BlY2lm aWNhbGx5IG91dCBvZiBjaGFydGVyIGZvciBET0guCgpQYXVsOgpXZSdyZSBob3BpbmcgdG8gc2h1 dCBkb3duIHRoZSBET0ggd29ya2luZyBncm91cC4gIEkgdGhpbmsgYSBuZXcgbWFpbGluZyBsaXN0 IGlzIGFwcHJvcHJpYXRlLgoKUGF0cmljazoKSSBhbHNvIHdvdWxkIGxpa2UgYW4gQUQgdG8gYmUg YXdhcmUgb2YgdGhpcyB3b3JrLgo= --000000000000b82213057211c474 Content-Type: application/octet-stream; name="resolverless.md" Content-Disposition: attachment; filename="resolverless.md" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jjpuhr5e0 IyBSZXNvbHZlcmxlc3MgRE5TDQoNCjIwMTgtMDctMTYgMTY6MzAgRURUDQoNCiJUb3RhbGx5IiBp bmZvcm1hbA0KDQpBYm91dCA0MCBhdHRlbmRlZXMNCg0KMS4gV2hhdCBmb3JtcyBvZiB0cmFuc3Bv cnQgY291bGQgYmUgaW4gc2NvcGU/IEhUVFAvMiBwdXNoIGlzIG9uZSBzdWNoDQogICB2ZWN0b3Is IGJ1dCBJJ3ZlIGhlYXJkIG90aGVycy4gU3ByYXkgcGFpbnQgZm9yIGV4YW1wbGUuDQoNCjIuIFdo YXQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCB3aGVuIHVzaW5nIHN1Y2ggZGF0YT8gKHNpZ25hdHVy ZXM/DQogICBzY29wZT8gZXRjPykNCg0KMy4gV2hvIGFyZSB0aGUgc3Rha2Vob2xkZXJzIGZvciAx ICsgMj8NCg0KNC4gSXMgdGhlcmUgZW5vdWdoIGludGVyZXN0IHRvIGV4cGxvcmUgZnVydGhlcj8g TmV4dCBzdGVwcyBhcyBvdXRwdXQNCg0KDQpka2c6IFBvdGVudGlhbGx5IHVzZWZ1bCBpbiBhIGxv dCBvZiBzcGFjZXMuIFBvcnQgNTMgYmVpbmcgdGhlIG9ubHkgd2F5DQp0byBnZXQgRE5TIGlzIHJl YWxseSB3cm9uZyB0b2RheS4gV2hlcmUgdGhlIGRhdGEgZ2V0cyBvZmYgdGhlIG5ldHdvcmsNCmlz IG5vdCBhbiBpbmRpY2F0b3Igb2YgaW50ZWdyaXR5LiBXZSBzaG91bGQgYmUgdGhpbmtpbmcgYWJv dXQgd2hlbiB0aGUNCmRhdGEgbWlnaHQgYmUgdXNhYmxlLiBETlNTRUMgY2hhaW4gaXMgYSBzaW5n bGUgdXNlIGNhc2UuDQoNCkpvaG4gRGlja2Vuc29uOiBDb25jZXJuZWQgYWJvdXQgdGhlIHBvc3Np YmxlIHVzZSBvZiBETlMgaW50cm9kdWNlcyB0aGUNCnBvc3NpYmlsaXR5IG9mIGFsdGVybmF0ZSBy b290cy4NCg0KUGF1bCBIb2ZmbWFuOiBTdWJqZWN0IGxpbmUgc2FpZCAicmVzb2x2ZXJsZXNzIiwg YW5kIGluIERvSCB0aGVyZSBpcyBhDQpyZXNvbHZlci4gIFR3byB1c2UgY2FzZXM6IHRydWUgcmVz b2x2ZXJsZXNzLCBidXQgaW4gRG9IIHRoZXJlIGlzIHNvcnQNCm9mIGEgcmVzb2x2ZXIuDQoNCmRr ZzogR2V0dGluZyBETlMgZnJvbSBwbGFjZXMgd2UgaGF2ZSBub3QgZ290dGVuIEROUyBmcm9tIGlu IHRoZSBwYXN0Lg0KVGhpbmtpbmcgYWJvdXQgdGhlICJzZXJ2ZXIgcHVzaCIgc2NlbmFyaW8uDQoN CkpvaG4gRGlja2Vuc29uOiAiV2hlcmUgdGhlIEROUyBjb21lcyBmcm9tPyIgbWVhbnMgdGhlIHJl c29sdmVyIG9yIHRoZQ0KYWN0dWFsIEROUyByZWNvcmRzPyBETlMgZnJvbSBhIHdlYiBzZXJ2ZXIg YW5kIG5vdCBhIEROUyBzZXJ2ZXI/DQoNCmRrZzogQ2hhbm5lbCB0aGUgYXBwbGljYXRpb24gY29t ZXMgZnJvbSBtYXkgbm90IGluZGljYXRlIGhvdyByZWxpYWJsZQ0KaXQgaXMuDQoNClRhbGU6IERv bid0IG5lY2Vzc2FyaWx5IG1lYW4gcmVzb2x2ZXIgaW4gdGhlIHBpcGVsaW5lLiBTZXJ2ZXJzIChD RE4ncykNCmNhbiB0ZWxsIHlvdSBhYm91dCByZWNvcmRzIHRoZXkgaG9wZSB5b3Ugd2lsbCB3YW50 LiBCdXQgdGhlIGFuc3dlcg0Kc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB3aGF0IHlvdSB3b3Vs ZCBnZXQgaWYgeW91IGFza2VkIHRoZSBETlMuDQoNCk1pa2UgQmlzaG9wOiBXZSBhbHJlYWR5IGhh dmUgZGlmZmVyZW50IGFuc3dlcnMgYmFzZWQgb24gY2xpZW50IElQLiBJbg0KSFRUUCB5b3UgbWF5 IGdldCBhbiBhbnN3ZXIgdGhhdCBpcyBub3QgaW4gdGhlIEROUyBiZWNhdXNlIG5vIGNsaWVudA0K Y2FuIGFzayB0aGF0Lg0KDQpTYXJhIERpY2tlbnNvbjogSXMgdGhpcyBsaWtlIGEgInZpZXciIG9m IEROUz8NCg0KVGFsZTogIkNvbnNpc3RlbnQgd2l0aCIgZG9lcyBub3QgbWVhbiAiaWRlbnRpY2Fs IHRvIi4gQnV0IHdlIG5lZWQgdG8NCnRhbGsgYWJvdXQgd2hvIGlzIGF1dGhvcml0YXRpdmUuDQoN ClBhdHJpY2sgTWNNYW51czogSXMgdGhhdCBkZWNpc2lvbiBwYXJ0IG9mIHRoZSBzZWN1cml0eSBt b2RlbCBvZiB0aGUNCmNvbnRleHQ/IFRoZSBETlMgaXMgbm90IGFsd2F5cyBjdXJyZW50LiBUaGVy ZSBtYXkgYmUgb3RoZXIgY29uY2VybnMNCmJ1dCBpdCBtYXkgbm90IGJlIGFib3V0IGF1dGhlbnRp Y2F0aW5nIHlvdXIgcGVlci4gSXNzdWVzIGFyb3VuZCBsb3NzDQpvZiBjZXJ0aWZpY2F0ZXMuIEdl dHRpbmcgYmFjayB0byB0aGUgdXNlIGNhc2Ugb2YgZ29pbmcgdG8NCiJleGFtcGxlLmNvbSIgYW5k IG5vdCBoYXZlICJhbmFseXRpY3MuY29tIiBhbmQgbm90IGhhdmluZyBhbnl0aGluZw0KbGVhay4N Cg0KSmltIFJlaWQ6IFdlYiBicm93c2VyIG5hbWUgbWF5IGJlIGNvbXBsZXRlbHkgZGlmZmVyZW50 IHRoYW4gRE5TIG5hbWUuDQpTaG91bGRuJ3QgYmUgdG8gcHVyZSBhYm91dCB3ZWIgdnMuIEROUy4N Cg0KUGF1bCBIb2ZmbWFuOiBXZSBtYXkgaGF2ZSBzdGFydGVkIHRvIHJhdGhvbGUgZWFybHkuIFNl cnZlciBrbm93cyB0aGUNCmNvbnRleHQgb2Ygd2hhdCBpcyBhc2tlZC4gV2UgY2FuIGFkZCBhbiBF RE5TMCBvcHRpb24gZm9yIGNvbnRleHQNCnNwZWNpZmljIGluZm9ybWF0aW9uLCBzdWNoIGFzICJJ IHdvdWxkIGdpdmUgdGhpcyBhbnN3ZXIgYW55d2hlcmUiDQp2ZXJzdXMgInRoaXMgaXMgZm9yIHlv dSIuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gZ28gdGhlcmUuDQoNClNoYW5lIEtlcnI6 IERvIHdlIGtub3cgaG93IHRoaXMgY2hhbmdlcyB0aGUgYXJjaGl0ZWN0dXJlIGFuZCB0aGUNCmlt cGFjdD8NCg0KTWlrZSBCaXNob3A6IENhY2hpbmcgd2lsbCBiZSB1bHRpbWF0ZS4NCg0KU3Vib2Ro IEl5ZW5nYXI6IFB1c2hpbmcgaXMgbmljZSwgYW5kIGFsc28gdGFyZ2V0aW5nLiBDYW4gYmUgbW9y ZSBvcHRpbWFsLg0KDQpka2c6IE5vYm9keSBpcyB0YWxraW5nIGFib3V0IGRvaW5nIGF3YXkgd2l0 aCByZXNvbHZlcnMuDQoNClNoYW5lIEtlcnI6IEkgYW0hIElmIGl0IGlzIHN1Y2Nlc3NmdWwgdGhl biBpdCBtYXkgcmVwbGFjZSBtb3N0IG9yIGFsbA0Kb2YgcmVzb2x2ZXIgdHJhZmZpYy4NCg0KVGFs ZTogSXQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gaGF2ZSBzaWduaWZpY2FudCBpbXBhY3Qgb24gdHJh ZmZpYywgYW5kDQpvdGhlciBhcmNoaXRlY3R1cmFsIGltcGxpY2F0aW9ucy4gVGhpcyB3aWxsIGZh dm9yIHNvbWUgbW9kZWxzIG92ZXINCm90aGVycy4NCg0KRXJpayBOeWdyZW46IFR3byBjbGFzc2Vz IG9mIHByb2JsZW1zIGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIuIE9uZQ0KZGltZW5zaW9uIGlz IHdhbGtpbmcgdGhlIGF1dGhvcml0eSB0cmVlLCB3aGV0aGVyIHRoZSBjbGllbnQgb3IgdGhlDQpy ZXNvbHZlci4gVGhlIG90aGVyIG9wdGlvbiBpcyB0aGVyZSBvdGhlciB3YXlzIHRvIGdldCB0aGUg aW5mb3JtYXRpb24NCi0ga2lsbGVyIGFwcCBmb3IgRE5TU0VDLiBHZXR0aW5nIEROU1NFQyBkYXRh IGluIGFub3RoZXIgY2hhbm5lbC4NCg0KRXJpayBOeWdyZW46IExhcmdlciBjYW4gb2Ygd29ybXMg Zm9yIGhvdyB3ZSByb3V0ZSB0cmFmZmljIGJhc2VkIG9uIGENCm5hbWUgdG8gYSBjbGllbnQuDQoN CkJhcnJ5IEdyZWVuZTogRE5TIHdhcyBidWlsdCBpbiBhbiBlcmEgd2l0aCB1bnN0YWJsZSBuZXR3 b3Jrcy4NClByb3ZpZGVycyB3aWxsIGdhaW4gYSBuZXcgZXh0ZXJuYWwgZGVwZW5kZW5jeSB0aGF0 IHRoZXkgY2Fubm90IGNvbnRyb2wNCnNpbmNlIGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgdGhlaXIg b3duIEROUyBvdmVyIERvSCBvciB3aGF0ZXZlci4NCg0KZGtnOiBJdCBzZWVtcyBsaWtlIHlvdSBh cmUgc2F5aW5nIHRoYXQgaWYgd2UgbWFrZSBpdCBzbyB0aGF0IGl0IHdvcmtzLA0KaXQgd2lsbCBt YWtlIEROUyBvYnNvbGV0ZS4gVGhhdCBpcyBub3Qgd2hhdCBJIGltYWdpbmUuDQoNClNhcmEgRGlj a2Vuc29uOiAuLi4NCg0KUGF0cmljayBNY01hbnVzOiBTY29wZSBvZiBkaXNjdXNzaW9uIGlzIHdo YXRldmVyIHdlIHdhbnQgaXQgdG8gYmUuDQoNClNhcmEgRGlja2Vuc29uOiBJZiB0aGVyZSBpcyBh IGdvb2QgY2hhbm5lbCwgaXQgd2lsbCBiZSBzd2l0Y2hlZCB0by4NCg0KSm9obiBEaWNrZW5zb246 IElzIGNvbnRleHQgYmVpbmcgb24gYSB3ZWIgcGFnZSBhbmQgdGFsa2luZyB0byB0aGF0DQpwYWdl LCBvciB0aGUgd2hvbGUgb3BlcmF0aW5nIHN5c3RlbT8NCg0KUGF1bCBIb2ZmbWFuOiBUaGUgbWFp biB1c2UgY2FzZSBpcyAiZmFzdGVyIi4gQSBzZXJ2ZXIgcHVzaGluZyByZWNvcmRzDQppcyBmYXN0 ZXIuDQoNCmRmazogTXkgbWFpbiBpZGVhIGlzIG5vdCB0aGF0Lg0KDQpQYXVsIEhvZmZtYW46IE9y IG1vcmUgcHJpdmF0ZS4gTGV0cyBzcGxpdCB0aGVtIG91dC4gV2UgY2FuIGRvdWJsZQ0KY2hlY2sg ImZhc3RlciIgYWdhaW5zdCByZWd1bGFyIEROUywgYnV0IHRoYXQgZG9lc24ndCB3b3JrIGZvciBw cml2YXRlLg0KVGhlcmUgbWlnaHQgYmUgbXVsdGlwbGUgbW9kZXMuIExldHMgbm90IHRlbGwgdGhl IHVzZXIgd2hhdCB0aGVpciB1c2UNCmNhc2VzIGFyZS4NCg0KUGF0cmljayBNY01hbnVzOiBJIGRv bid0IHRoaW5rICJ3aGF0IGlzIHRoZSBjb250ZXh0IiBpcyBhIHBvaW50IG9mDQpjb25mdXNpb24s IEkgdGhpbmsgd2UgbmVlZCB0byBkZWNpZGUgdGhhdC4gT25lIGNvbnRleHQgaXMgSFRUUFMNCndp dGhpbiBhIHdlYiBicm93c2VyLiBBbm90aGVyIG1pZ2h0IGJlIGFsbCBIVFRQUy4gDQoNClBhdHJp Y2sgTWNNYW51czogQXMgZm9yIHJlbW92aW5nIGFsbCBETlMuIFNlcnZlcnMgZG8gbm90IGtub3cg YWxsIHRoZQ0KbmFtZXMgdGhhdCBIVFRQIGNsaWVudHMgd2lsbCB3YW50Lg0KDQpSYW1pIEFsLURh bGt5OiBXaXRoIEROU1NFQywgc3R1YiByZXNvbHZlcnMgcmVseSBvbiByZXNvbHZlcnMuIElmIHdl DQpjYW5ub3QgZG8gdGhpcywgd2lsbCB3ZSBnaXZlIGFwcGxpY2F0aW9ucyB0aGUgYWJpbGl0eSB0 byB2YWxpZGF0ZT8NCg0KUGF1bCBIb2ZmbWFuOiBZZXMuIEFscmVhZHkgdGhlcmUuDQoNClJheSBC ZWxsaXM6IFdlIGhhdmUgdGhlIGNhc2Ugb2Ygc2VydmVycyBwdXNoaW5nIGRhdGEgdG8gRE5TLCBp biBSUFouDQpUaGF0IGhhcyBub3QgY2F1c2VkIGFyY2hpdGVjdHVyYWwgcHJvYmxlbXMuDQoNClN1 Ym9kaCBJeWVuZ2FyOiBXaXRoIGRpdmVyc2l0eSwgd2UgaGF2ZSBubyBjbGVhciBwYXRoIGZvciBt b3JlIERvSA0KcmVzb2x2ZXJzLiAgQm9vdHN0cmFwcGluZyBhIHJlc29sdmVyIGFuZCBkaXNjb3Zl cmluZyBtb3JlIG9uIHRoZSB3YXkNCm1pZ2h0IGJlIGdvb2QuDQoNCkVyaWsgTnlncmVuOiBNYXkg YmUgYSB3YXkgdG8gYXNrIHNlcnZlcnMgdG8gY29ubmVjdCB0byBhIHNlcnZlciB0aGF0IEkNCnRy dXN0IHRvIGdldCBuYW1lcy4NCg0KUGF0cmljayBNY01hbnVzOiBJIHdhbnQgdG8gbWFrZSBzdXJl IHdlIGhhdmUgdGhlIHJpZ2h0IHN0YWtlaG9sZGVycw0KbW92aW5nIGZvcndhcmQuDQoNCk1hcmsg Tm90dGluZ2hhbTogSVNQJ3MgZG9uJ3QgY2FyZSwgYnV0IGVudGVycHJpc2UgbmV0d29ya3MsIHNj aG9vbHMsDQpob21lcywgd2FudCB0byBlbmZvcmNlIHBvbGljeSBvbiBuZXR3b3Jrcy4NCg0KTWFy ayBBbmRyZXdzOiBHZXR0aW5nIHRoZSBBQUFBIHJlY29yZHMgdG8gZ28gdGhyb3VnaCB0aGUgTkFU NjQuIEEgbG90DQpvZiBzdHVmZiBoYXBwZW5zIGxvY2FsIHRvIHRoZSBjbGllbnQgdG9kYXkuIEl0 J3MgYWxsIGdvaW5nIHRvIGVuZCB1cA0KYnJlYWtpbmcuIFdlIGZpeGVkIGEgbG90IG9mIHRoaW5n IGJyaW5naW5nIHRoZSBmaXhlcyBjbG9zZS4NCg0KQmFycnkgR3JlZW5lOiBUaGUgSVNQIGNvbnRl eHQgaXMgRXVyb3BlYW4gb3IgQW1lcmljYW4uIFdoZW4geW91DQpzdWRkZW5seSBieXBhc3MgdGhl bSBhbmQgZG8gRE5TIGRpcmVjdGx5IHlvdSB3aWxsIGdldCBjb21wbGFpbnRzLg0KVHJvdWJsZXNo b290aW5nIEROUyBwcm9ibGVtcyB3aWxsIHJlcXVpcmUgZGlmZmVyZW50IHN1cHBvcnQuDQoNClBh dWwgSG9mZm1hbjogTGV0cyBkcm9wIHRoZSBpZGVhIG9mIGdldHRpbmcgZGF0YSBmcm9tIFRMUyBh bmQganVzdCB1c2UNCkRvSC4NCg0KZGtnOiBJbiB0ZXJtcyBvZiBtb3ZpbmcgZm9yd2FyZCwgd2Ug c2hvdWxkIGRlZmluZSBpbiB0aGUgbmFycm93ZXN0DQp0ZXJtcyBwb3NzaWJsZS4gSWYgdGhhdCBt ZWFucyBpbiBvbmUgdGFiIHdlIGdvIHRvIGFuIEhUVFBTIGVuZHBvaW50DQphbmQgZ2V0IEROU1NF QyBzaWduZWQgZGF0YSAoZm9yIGV4YW1wbGUpLCBhbmQgdGhlbiB3YWxrIHRoZSBzY29wZSBvdXQN CmlmIG5lY2Vzc2FyeS4NCg0KRXJpayBOeWdyZW46IFdobyB0cnVzdHMgd2hvbT8gVGhlIG9yaWdp biBkaXNjdXNzaW9uPyBSZXN0cmljdCBpdCBzb21laG93Lg0KDQpQYXRyaWNrIE1jTWFudXM6IGV4 YW1wbGUuY29tIGNvdWxkIHB1c2ggYSByZWNvcmQgZm9yIGdtYWlsLiBJZiBpdCBpcw0Kbm90IERO U1NFQyBzaWduZWQsIHRoZW4gaXQgY291bGQgcHVibGlzaCB0aGUgSVAgYWRkcmVzcyBmb3IgaXRz ZWxmIGFzDQpnbWFpbC5jb20uDQoNCj8/PzQ6IEV2ZW4gcmVzdHJpY3RpbmcgaW4gYSB0YWIgY2Fu IGJlY29tZSBtZXNzeS4gQSB0YWIgbWF5IHVzZQ0KaW5mb3JtYXRpb24gZnJvbSBvdGhlciB0YWJz LiBNYXliZSB3ZSBoYXZlIHRvIHNheSBvbmx5IGluIHByaXZhdGUNCmJyb3dzZXIgbW9kZSwgd2l0 aCBhIHRvdGFsbHkgc2VwYXJhdGUgY29udGV4dCBhbmQgc3Ryb25nZXIgZmlyZXdhbGxzLg0KDQpC ZW4gU2Nod2FydHo6IElmIEkgb3duIGEgZG9tYWluIEkgY2FuIGNyZWF0ZSBETlNTRUMtc2lnbmVk IHJlY29yZHMgYW5kDQpzcGFtIGFuIGVudGlyZSAvNjQsIHRoZW4gYW55IHBhZ2UgdGhhdCB5b3Ug bG9hZCB3aGlsZSB0aGF0IGlzIGluIGNhY2hlDQp0aGVuIGEgdHJhY2tpbmcgcGl4ZWwgd2lsbCBh bGxvdyB0cmFja2luZy4gQ29va2llIHNjb3BlIHBhcnRpdGlvbmluZw0KbmVlZHMgdG8gYXBwbHkg dG8gSVAgYWRkcmVzc2VzLg0KDQpNYXJrIE5vdHRpbmdoYW06IFRoaXMgaXMgcG9zc2libGUuIFNl Z3JlZ2F0aW5nIHNvY2tldHMgaXMgc3RpbGwgYQ0KY29udHJvdmVyc2lhbCB0b3BpYywgYnV0IGl0 IGlzIHdvcnRoIHRhbGtpbmcgYWJvdXQuDQoNCmRrZzogQSBkaWZmZXJlbmNlIGJldHdlZW4gRE5T U0VDIHNpZ25lZCByZWNvcmRzIGZvciBhIC82NCBhbmQgdGhlDQphbHRlcm5hdGl2ZSBpcyB0aGF0 IGlmIEkgZ2V0IGEgc2lnbmVkIHJlY29yZCB0aGVuIEkgY2FuIHJlcGxheSBpdCBmb3INCmFueW9u ZSBlbHNlLiBTaWduZWQgcmVjb3JkcyBnaXZlcyB1cyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHNvbWUg c29ydCBvZg0KdHJhbnNwYXJlbmN5IG1vZGVsLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUGF0cmljayBN Y01hbnVzOiBXZSB3aWxsIGNyZWF0ZSBhIG1haWxpbmcgbGlzdCwgdG8gd29yayB3aXRoIGRrZydz DQpzdWdnZXN0aW9uIG9mIHdvcmtpbmcgdG93YXJkcyBhIG1pbmltYWwgbW9kZWwuIElmIHdlIGNh biBkbyB0aGF0IGluDQp0aGUgbmV4dCAzIHRvIDQgbW9udGhzIHRoZW4gd2UgY2FuIGNvbnNpZGVy IHdoYXQgdG8gZG8uDQo= --000000000000b82213057211c474--