From nobody Sat Aug 4 01:53:24 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 214F912F295; Sat, 4 Aug 2018 01:53:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: draft-ietf-doh-dns-over-https.all@ietf.org, doh@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153337279710.31560.12854746020010274260@ietfa.amsl.com> Date: Sat, 04 Aug 2018 01:53:17 -0700 Archived-At: Subject: [Doh] Genart last call review of draft-ietf-doh-dns-over-https-12 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: Sat, 04 Aug 2018 08:53:17 -0000 Reviewer: Stewart Bryant Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-doh-dns-over-https-12 Reviewer: Stewart Bryant Review Date: 2018-08-04 IETF LC End Date: 2018-08-08 IESG Telechat date: Not scheduled for a telechat Summary: ID-Nits picks up a downref, but the appropriate warning was included in the IETF LC email. Major issues: 4. Selection of DoH Server SB> I am surprised that there is no discussion of the need to specify SB> the raw IP address of the sever as part of the URI, and that there SB> is no discussion of the server address IP address family in the document. SB> I would have thought that there should at least be a reference to SB> "happy eyeballs" and and discussion of an optimization strategy of SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. ========== The same DNS query for www.example.com, using the POST method would be: :method = POST :scheme = https :authority = dnsserver.example.net :path = /dns-query accept = application/dns-message content-type = application/dns-message content-length = 33 <33 bytes represented by the following hex encoding> 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 SB> At this point in the text am at a loss to understand the 33 bytes. SB> Having read to the end of the text, I assume that this is a binary encoded SB> DNS query in "one the wire format" but this point needs to be made clear, SB> as does the explicit encoding. It would be really useful if there was an SB> example of both formats side by side. ========= The DNS query is 94 bytes represented by the following hex encoding SB> Again in what format? ========= :method = GET :scheme = https :authority = dnsserver.example.net :path = /dns-query? (no space or CR) dns=AAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR) bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR) dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ accept = application/dns-message SB> I am not a DNS or HTTP specialist, so please help me understand SB> what the string starting "dns=" is. ========== 5.2.2. HTTP Response Example SB> Nits says: -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? SB> I am not sure if there are any IPv4 vs IPv6 issues but it would be helpful to SB> clarify the point. ========= <64 bytes represented by the following hex encoding> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 SB> At this point in the text I am still wondering what this encoding means, I assume that SB> it is a hex representation of the payload received SB> back from a normal DNS query. ========= 7. Definition of the application/dns-message media type The data payload for the application/dns-message media type is a single message of the DNS on-the-wire format defined in Section 4.2.1 of [RFC1035]. SB> That would have been useful to have known earlier SB> However 4.2.1 just talks about UDP and not the message syntax. SB> Also presumably we are talking about the payload of the UDP SB> message excluding the UDP header. SB> "on-the-wire" is a potentially confusing term, since it gets us SB> into network byte order etc. SB> I think the whole thing would be clearer is you said that your SB> message was identical to the payload of the UDP payload of an SB> RFC1035 as seen by a server (and then add some specification SB> about the payload to hex method you are using) SB> It would also be helpful to the reader to note whether SB> any of the 25 updates to RFC1035 impact any of the specification SB> described in this memo. ======= The format was originally for DNS over UDP. Although [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", that was later updated by [RFC6891]. This media type restricts the maximum size of the DNS message to 65535 bytes. Note that the wire format used in this media type is different than the wire format used in [RFC7858] (which uses the format defined in Section 4.2.2 of [RFC1035]). SB> 4.2.2 does not seem to describe a format, unless you are implicitly SB> saying that 4.2.1 does not have a length 4.2.2 does and you SB> are encoding the length another way and hence use 4.2.1 format. SB> Either way neither of these sections of RFC1035 really specify the SB> format, that is provided earlier in the RFC. =========== Encoding considerations: This is a binary format. The contents are a DNS message as defined in RFC 1035. The format used here is for DNS over UDP, which is the format defined in the diagrams in RFC 1035. SB> With or without the UDP header? ========== Minor issues: Abstract This document describes how to make DNS queries over HTTPS. SB> This is the shortest abstract I have seen in a long while, if SB> not forever. It would be helpful to the undecided reader if SB> a little more context from the Introduction was included in the SB> abstract. ========= Nits/editorial comments: These caches may exist beteen the SB> s/beteen/between/ From nobody Sat Aug 4 08:08: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 A94EE130DE6; Sat, 4 Aug 2018 08:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 lRpca620P-rI; Sat, 4 Aug 2018 08:08:49 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E6D130DE5; Sat, 4 Aug 2018 08:08:49 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 4 Aug 2018 08:08:47 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Sat, 4 Aug 2018 08:08:47 -0700 From: Paul Hoffman To: Stewart Bryant CC: "gen-art@ietf.org" , "draft-ietf-doh-dns-over-https.all@ietf.org" , DoH WG , IETF Thread-Topic: [Ext] Genart last call review of draft-ietf-doh-dns-over-https-12 Thread-Index: AQHUK9CY9aK289XK4U2BPvsoN2uiO6SwJ8wA Date: Sat, 4 Aug 2018 15:08:46 +0000 Message-ID: <30EE90B8-F5D0-4870-8353-FE1A0EEE11C1@icann.org> References: <153337279710.31560.12854746020010274260@ietfa.amsl.com> In-Reply-To: <153337279710.31560.12854746020010274260@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <85AB2E6C64EBAD4981488C8ED4297568@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Genart last call review of 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: Sat, 04 Aug 2018 15:08:52 -0000 On Aug 4, 2018, at 1:53 AM, Stewart Bryant wrote= : >=20 > Reviewer: Stewart Bryant > Review result: On the Right Track >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-doh-dns-over-https-12 > Reviewer: Stewart Bryant > Review Date: 2018-08-04 > IETF LC End Date: 2018-08-08 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > ID-Nits picks up a downref, but the appropriate warning was included in t= he IETF LC email. >=20 > Major issues: >=20 > 4. Selection of DoH Server >=20 > SB> I am surprised that there is no discussion of the need to specify > SB> the raw IP address of the sever as part of the URI, and that there > SB> is no discussion of the server address IP address family in the docum= ent. A URI can have either host names or IP addresses in the authority part. > SB> I would have thought that there should at least be a reference to > SB> "happy eyeballs" and and discussion of an optimization strategy of=20 > SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. Happy eyeballs is orthogonal to the document. How the client turns a host n= ame in the URI into an IP address is completely up to the client using what= ever strategies it wants to use. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The same DNS query for www.example.com, using the POST method would > be: >=20 > :method =3D POST > :scheme =3D https > :authority =3D dnsserver.example.net > :path =3D /dns-query > accept =3D application/dns-message > content-type =3D application/dns-message > content-length =3D 33 >=20 > <33 bytes represented by the following hex encoding> > 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 > 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 > 01 >=20 > SB> At this point in the text am at a loss to understand the 33 bytes.=20 > SB> Having read to the end of the text, I assume that this is a binary en= coded > SB> DNS query in "one the wire format" but this point needs to be made cl= ear, > SB> as does the explicit encoding. Will do. > SB> It would be really useful if there was an > SB> example of both formats side by side. Could you explain more what you want here? The two formats will look the sa= me: a bunch of hex. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > The DNS query is 94 bytes represented by the following hex encoding > SB> Again in what format? Wire format. We'll add a note of that. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > :method =3D GET > :scheme =3D https > :authority =3D dnsserver.example.net > :path =3D /dns-query? (no space or CR) > dns=3DAAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR) > bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR) > dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ > accept =3D application/dns-message >=20 > SB> I am not a DNS or HTTP specialist, so please help me understand > SB> what the string starting "dns=3D" is. The path is the last part of the HTTP query. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 5.2.2. HTTP Response Example >=20 > SB> Nits says: >=20 > -- The document has examples using IPv4 documentation addresses accordin= g > to RFC6890, but does not use any IPv6 documentation addresses. Maybe > there should be IPv6 examples, too? >=20 > SB> I am not sure if there are any IPv4 vs IPv6 issues but it would be he= lpful to > SB> clarify the point. We are changing the example to be for IPv6 (based on the AD review). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > <64 bytes represented by the following hex encoding> > 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 > 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 > 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f > 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 >=20 > SB> At this point in the text I am still wondering what this encoding mea= ns, I assume that > SB> it is a hex representation of the payload received > SB> back from a normal DNS query. Correct. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 7. Definition of the application/dns-message media type >=20 > The data payload for the application/dns-message media type is a > single message of the DNS on-the-wire format defined in Section 4.2.1 > of [RFC1035].=20 >=20 > SB> That would have been useful to have known earlier > SB> However 4.2.1 just talks about UDP and not the message syntax. > SB> Also presumably we are talking about the payload of the UDP > SB> message excluding the UDP header. We will make the contents of the payloads clearer earlier in the document. = The reason the reference is to Section 4.2.1 of RFC 1035 is that the DNS wi= re format changes if it is over TCP. >=20 > SB> "on-the-wire" is a potentially confusing term, since it gets us > SB> into network byte order etc. > SB> I think the whole thing would be clearer is you said that your > SB> message was identical to the payload of the UDP payload of an > SB> RFC1035 as seen by a server Agree. > SB> (and then add some specification=20 > SB> about the payload to hex method you are using) Not sure what you mean here. > SB> It would also be helpful to the reader to note whether > SB> any of the 25 updates to RFC1035 impact any of the specification > SB> described in this memo. None of them do. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > The format was originally for DNS over UDP. Although > [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", > that was later updated by [RFC6891]. This media type restricts the > maximum size of the DNS message to 65535 bytes. Note that the wire > format used in this media type is different than the wire format used > in [RFC7858] (which uses the format defined in Section 4.2.2 of > [RFC1035]). >=20 > SB> 4.2.2 does not seem to describe a format, unless you are implicitly > SB> saying that 4.2.1 does not have a length 4.2.2 does That is exactly what we are saying because that is what RFC 1035 says. > SB> and you > SB> are encoding the length another way and hence use 4.2.1 format. The DNS wire format for UDP does not encode the length, and so DoH does not= either. > SB> Either way neither of these sections of RFC1035 really specify the > SB> format, that is provided earlier in the RFC. We will clear this up. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Encoding considerations: This is a binary format. The contents are a > DNS message as defined in RFC 1035. The format used here is for DNS > over UDP, which is the format defined in the diagrams in RFC 1035. >=20 > SB> With or without the UDP header? Without. RFC 1035 says nothing about the UDP header as part of the wire for= mat. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Minor issues: >=20 > Abstract >=20 > This document describes how to make DNS queries over HTTPS. >=20 > SB> This is the shortest abstract I have seen in a long while, if > SB> not forever. It would be helpful to the undecided reader if > SB> a little more context from the Introduction was included in the > SB> abstract. Fixed (based on the AD review). It now says: 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. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Nits/editorial comments:=20 >=20 > These caches may exist beteen the > SB> s/beteen/between/ Good catch; will fix. Thanks for the review! --Paul Hoffman From nobody Sat Aug 4 10:11: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 7706F130DEB; Sat, 4 Aug 2018 10:11:04 -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 Nsv702EYVqh4; Sat, 4 Aug 2018 10:11:00 -0700 (PDT) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 A37ED124C04; Sat, 4 Aug 2018 10:10:57 -0700 (PDT) Received: by mail-qk0-x243.google.com with SMTP id b5-v6so6191637qkg.6; Sat, 04 Aug 2018 10:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tjePfU1XWpDjPjpoLXGgXHOs7IxdRlS0CdwT6KEr+mc=; b=p6AFJnekgGijsI/pVRaIoBcYPAon1YjaprQpbHtTg1sdmWUNpw+YddMGYm0Ygfb0cm yfrvQ3I2NLXxqkY/LNkWTL1xI36G07EsBYrYsj50mdxp7LcTiu1xb7hIFvg9epILPu5z 3dm+HuRqTe9TfCNmmBpi52QwJbQaCIpIc0BAaGpuJD5mhJsXfcvBTQlRPNPpuXE1hx9p 9L+n+3fPeH3few49o94F2TJa0EaYQVedSh5ojtWkT5TOYd9er/lyFzpEEYKx/PuZrusx rSu5napjSKJo9c4ztL3EQ9HDYejGiVzDcjrR4HjuWEvFwf6AEnmBva8om7zCFbzhH+1W nZVA== 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=tjePfU1XWpDjPjpoLXGgXHOs7IxdRlS0CdwT6KEr+mc=; b=dIwAJiVUCw/oparB9NgGIzalExWVmjD1JWXWV+TDW51a7bdsDwOJ3FoU3mJEbiOK6J WVl8kIWIyCH/4yVTMtM2SyDJc8ZgOrHGXBN4wpQpK3aUffx4kBSxocnQ3fhGNf50Ll3N iLNHr4NXKvNW6+roV8L8eGVJ93U+NcW14tNDC7lTDMx0xmhyWRUo/qLIbKpSAIzhxrta nbG/2G1ClKLvwdwM/YqKxjxlVhCuslzgCdXm5XvkgyTDIHpVzSP+uIcGrEX2wIOF3+WK aVNJagsbyngf+XAWTn0+8GXdZ7iGoy8TiDKr01CNEzVWxkqn/Va9cKY5OLB9FSoRw7uf 6LNw== X-Gm-Message-State: AOUpUlGsWpuE4EGUrAeVhyUTlNVGNhcEeolJdFESQM0S7rF5NVFnTObx efSZRlb9dSWkDocnsdnuUoFN01eF2tU= X-Google-Smtp-Source: AAOMgpfiEFFPc0QrX24AK2+JHzgmh7GbL2ADMysxQe9fUOxU2Z3vC6QNIzaS6cFJfJ8p2K+yeAWC8w== X-Received: by 2002:a37:a58a:: with SMTP id o132-v6mr8007237qke.338.1533402656509; Sat, 04 Aug 2018 10:10:56 -0700 (PDT) Received: from [10.134.82.25] ([66.45.255.43]) by smtp.gmail.com with ESMTPSA id z123-v6sm5760227qke.68.2018.08.04.10.10.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Aug 2018 10:10:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Stewart Bryant X-Mailer: iPad Mail (15G77) In-Reply-To: <30EE90B8-F5D0-4870-8353-FE1A0EEE11C1@icann.org> Date: Sat, 4 Aug 2018 18:10:54 +0100 Cc: "gen-art@ietf.org" , "draft-ietf-doh-dns-over-https.all@ietf.org" , DoH WG , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <698CDB47-161C-4FA1-959E-6259983A7FF3@gmail.com> References: <153337279710.31560.12854746020010274260@ietfa.amsl.com> <30EE90B8-F5D0-4870-8353-FE1A0EEE11C1@icann.org> To: Paul Hoffman Archived-At: Subject: Re: [Doh] [Ext] Genart last call review of 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: Sat, 04 Aug 2018 17:11:04 -0000 Sent from my iPad > On 4 Aug 2018, at 16:08, Paul Hoffman wrote: >=20 >> On Aug 4, 2018, at 1:53 AM, Stewart Bryant wro= te: >>=20 >> Reviewer: Stewart Bryant >> Review result: On the Right Track >>=20 >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >>=20 >> For more information, please see the FAQ at >>=20 >> . >>=20 >> Document: draft-ietf-doh-dns-over-https-12 >> Reviewer: Stewart Bryant >> Review Date: 2018-08-04 >> IETF LC End Date: 2018-08-08 >> IESG Telechat date: Not scheduled for a telechat >>=20 >> Summary: >>=20 >> ID-Nits picks up a downref, but the appropriate warning was included in t= he IETF LC email. >>=20 >> Major issues: >>=20 >> 4. Selection of DoH Server >>=20 >> SB> I am surprised that there is no discussion of the need to specify >> SB> the raw IP address of the sever as part of the URI, and that there >> SB> is no discussion of the server address IP address family in the docum= ent. >=20 > A URI can have either host names or IP addresses in the authority part. I do not understand. How does a system that is using this as its DNS access m= echanism find the IP address of the DNS service given only the name of the s= erver? >=20 >> SB> I would have thought that there should at least be a reference to >> SB> "happy eyeballs" and and discussion of an optimization strategy of=20= >> SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. >=20 > Happy eyeballs is orthogonal to the document. How the client turns a host n= ame in the URI into an IP address is completely up to the client using whate= ver strategies it wants to use. My assumption is that someone used to DNS would understand all the issues. B= ut you have written this document so that web applications specialists can d= o a DNS lookup from within their web application. It would seem reasonable t= o give them some hints about the issues, even if only by reference. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> The same DNS query for www.example.com, using the POST method would >> be: >>=20 >> :method =3D POST >> :scheme =3D https >> :authority =3D dnsserver.example.net >> :path =3D /dns-query >> accept =3D application/dns-message >> content-type =3D application/dns-message >> content-length =3D 33 >>=20 >> <33 bytes represented by the following hex encoding> >> 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 >> 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 >> 01 >>=20 >> SB> At this point in the text am at a loss to understand the 33 bytes.=20= >> SB> Having read to the end of the text, I assume that this is a binary en= coded >> SB> DNS query in "one the wire format" but this point needs to be made cl= ear, >> SB> as does the explicit encoding. >=20 > Will do. >=20 >> SB> It would be really useful if there was an >> SB> example of both formats side by side. >=20 > Could you explain more what you want here? The two formats will look the s= ame: a bunch of hex. >=20 How about showing the mapping of this to a 1035 message using the parameters= the coder would use. So for example some of that ascii is presumably the Na= me of the address being looked up. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> The DNS query is 94 bytes represented by the following hex encoding >> SB> Again in what format? >=20 >=20 > Wire format. We'll add a note of that. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >> :method =3D GET >> :scheme =3D https >> :authority =3D dnsserver.example.net >> :path =3D /dns-query? (no space or CR) >> dns=3DAAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or CR) >> bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or CR) >> dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ >> accept =3D application/dns-message >>=20 >> SB> I am not a DNS or HTTP specialist, so please help me understand >> SB> what the string starting "dns=3D" is. >=20 > The path is the last part of the HTTP query. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 5.2.2. HTTP Response Example >>=20 >> SB> Nits says: >>=20 >> -- The document has examples using IPv4 documentation addresses according= >> to RFC6890, but does not use any IPv6 documentation addresses. Maybe >> there should be IPv6 examples, too? >>=20 >> SB> I am not sure if there are any IPv4 vs IPv6 issues but it would be he= lpful to >> SB> clarify the point. >=20 > We are changing the example to be for IPv6 (based on the AD review). >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> <64 bytes represented by the following hex encoding> >> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 >> 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 >> 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f >> 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 >>=20 >> SB> At this point in the text I am still wondering what this encoding mea= ns, I assume that >> SB> it is a hex representation of the payload received >> SB> back from a normal DNS query. >=20 > Correct. It would be helpful to the new reader to explain that. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> 7. Definition of the application/dns-message media type >>=20 >> The data payload for the application/dns-message media type is a >> single message of the DNS on-the-wire format defined in Section 4.2.1 >> of [RFC1035].=20 >>=20 >> SB> That would have been useful to have known earlier >> SB> However 4.2.1 just talks about UDP and not the message syntax. >> SB> Also presumably we are talking about the payload of the UDP >> SB> message excluding the UDP header. >=20 > We will make the contents of the payloads clearer earlier in the document.= The reason the reference is to Section 4.2.1 of RFC 1035 is that the DNS wi= re format changes if it is over TCP. Yes, but rather than have the reader work out the minor difference in please= tell them. >=20 >>=20 >> SB> "on-the-wire" is a potentially confusing term, since it gets us >> SB> into network byte order etc. >> SB> I think the whole thing would be clearer is you said that your >> SB> message was identical to the payload of the UDP payload of an >> SB> RFC1035 as seen by a server >=20 > Agree. >=20 >> SB> (and then add some specification=20 >> SB> about the payload to hex method you are using) >=20 > Not sure what you mean here. >=20 >> SB> It would also be helpful to the reader to note whether >> SB> any of the 25 updates to RFC1035 impact any of the specification >> SB> described in this memo. >=20 > None of them do. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> The format was originally for DNS over UDP. Although >> [RFC1035] says "Messages carried by UDP are restricted to 512 bytes", >> that was later updated by [RFC6891]. This media type restricts the >> maximum size of the DNS message to 65535 bytes. Note that the wire >> format used in this media type is different than the wire format used >> in [RFC7858] (which uses the format defined in Section 4.2.2 of >> [RFC1035]). >>=20 >> SB> 4.2.2 does not seem to describe a format, unless you are implicitly >> SB> saying that 4.2.1 does not have a length 4.2.2 does >=20 > That is exactly what we are saying because that is what RFC 1035 says. One sentence will stop the reader having to work this out. >=20 >> SB> and you >> SB> are encoding the length another way and hence use 4.2.1 format. >=20 > The DNS wire format for UDP does not encode the length, and so DoH does no= t either. >=20 >> SB> Either way neither of these sections of RFC1035 really specify the >> SB> format, that is provided earlier in the RFC. >=20 > We will clear this up. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Encoding considerations: This is a binary format. The contents are a >> DNS message as defined in RFC 1035. The format used here is for DNS >> over UDP, which is the format defined in the diagrams in RFC 1035. >>=20 >> SB> With or without the UDP header? >=20 > Without. RFC 1035 says nothing about the UDP header as part of the wire fo= rmat. It might be better to talk about UDP payload do it is completely clear.=20 >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Minor issues: >>=20 >> Abstract >>=20 >> This document describes how to make DNS queries over HTTPS. >>=20 >> SB> This is the shortest abstract I have seen in a long while, if >> SB> not forever. It would be helpful to the undecided reader if >> SB> a little more context from the Introduction was included in the >> SB> abstract. >=20 > Fixed (based on the AD review). It now says: >=20 > 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. >=20 Better. Thanks. >=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Nits/editorial comments:=20 >>=20 >> These caches may exist beteen the >> SB> s/beteen/between/ >=20 > Good catch; will fix. >=20 > Thanks for the review! >=20 > --Paul Hoffman >=20 Thanks - Stewart From nobody Sat Aug 4 10:35: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 BCFDC1274D0; Sat, 4 Aug 2018 10:35: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 2y5Z87sbQNXQ; Sat, 4 Aug 2018 10:34:58 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368B7129AB8; Sat, 4 Aug 2018 10:34:58 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 4 Aug 2018 10:34:56 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Sat, 4 Aug 2018 10:34:56 -0700 From: Paul Hoffman To: Stewart Bryant CC: "gen-art@ietf.org" , "draft-ietf-doh-dns-over-https.all@ietf.org" , DoH WG , IETF Thread-Topic: [Ext] Genart last call review of draft-ietf-doh-dns-over-https-12 Thread-Index: AQHUK9CY9aK289XK4U2BPvsoN2uiO6SwJ8wAgAAiHwCAAAa3AA== Date: Sat, 4 Aug 2018 17:34:56 +0000 Message-ID: <9CFFA4F2-FBF8-4009-96AE-DEE4603B347A@icann.org> References: <153337279710.31560.12854746020010274260@ietfa.amsl.com> <30EE90B8-F5D0-4870-8353-FE1A0EEE11C1@icann.org> <698CDB47-161C-4FA1-959E-6259983A7FF3@gmail.com> In-Reply-To: <698CDB47-161C-4FA1-959E-6259983A7FF3@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <39853D4FD8074E4690BC9C51D676DF2A@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Genart last call review of 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: Sat, 04 Aug 2018 17:35:01 -0000 On Aug 4, 2018, at 10:10 AM, Stewart Bryant wrot= e: >=20 >>> 4. Selection of DoH Server >>>=20 >>> SB> I am surprised that there is no discussion of the need to specify >>> SB> the raw IP address of the sever as part of the URI, and that there >>> SB> is no discussion of the server address IP address family in the doc= ument. >>=20 >> A URI can have either host names or IP addresses in the authority part. >=20 > I do not understand. How does a system that is using this as its DNS acce= ss mechanism find the IP address of the DNS service given only the name of = the server? If a client is using DoH as its only access to the DNS, then the URI clearl= y needs an IP address in it. However, most of the current expected applicat= ions of DoH are for getting better DNS service, not being the exclusive or = first DNS service. For example, browsers are expected to use DoH in additio= n to the OS's stub resolver in order to get the benefits described in the d= raft's Introduction. >>> SB> I would have thought that there should at least be a reference to >>> SB> "happy eyeballs" and and discussion of an optimization strategy of= =20 >>> SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. >>=20 >> Happy eyeballs is orthogonal to the document. How the client turns a hos= t name in the URI into an IP address is completely up to the client using w= hatever strategies it wants to use. >=20 > My assumption is that someone used to DNS would understand all the issues= . But you have written this document so that web applications specialists c= an do a DNS lookup from within their web application. It would seem reasona= ble to give them some hints about the issues, even if only by reference. Those hints would be for the developer of the browser or other HTTP client = stack, not to DoH. DoH requires (and should not require!) any changes to th= ose. >>> SB> It would be really useful if there was an >>> SB> example of both formats side by side. >>=20 >> Could you explain more what you want here? The two formats will look the= same: a bunch of hex. >>=20 > How about showing the mapping of this to a 1035 message using the paramet= ers the coder would use. So for example some of that ascii is presumably th= e Name of the address being looked up. I apologize for being dense, but I still don't see what you are asking for = here. The DoH client marshals a DNS query just like a DNS client does by pu= tting together all the bits from RFC 1035. The DNS name being looked up is = not in ASCII: RFC 1035 says how you put together the labels of a name in a = binary format. >>>=20 >>> <64 bytes represented by the following hex encoding> >>> 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 >>> 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 >>> 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f >>> 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 >>>=20 >>> SB> At this point in the text I am still wondering what this encoding m= eans, I assume that >>> SB> it is a hex representation of the payload received >>> SB> back from a normal DNS query. >>=20 >> Correct. >=20 > It would be helpful to the new reader to explain that. Got it; will do. >>=20 >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> 7. Definition of the application/dns-message media type >>>=20 >>> The data payload for the application/dns-message media type is a >>> single message of the DNS on-the-wire format defined in Section 4.2.1 >>> of [RFC1035].=20 >>>=20 >>> SB> That would have been useful to have known earlier >>> SB> However 4.2.1 just talks about UDP and not the message syntax. >>> SB> Also presumably we are talking about the payload of the UDP >>> SB> message excluding the UDP header. >>=20 >> We will make the contents of the payloads clearer earlier in the documen= t. The reason the reference is to Section 4.2.1 of RFC 1035 is that the DNS= wire format changes if it is over TCP. >=20 > Yes, but rather than have the reader work out the minor difference in ple= ase tell them. We did that in an earlier draft and was told by the WG to take it out becau= se it was confusing.=20 >>> SB> 4.2.2 does not seem to describe a format, unless you are implicitly >>> SB> saying that 4.2.1 does not have a length 4.2.2 does >>=20 >> That is exactly what we are saying because that is what RFC 1035 says. >=20 > One sentence will stop the reader having to work this out. The fact that RFC 1035 is subtle on this point is not helpful to us. RFC 10= 35 talks about the format throughout as if it will always be used in UDP; i= t's only in Section 4.2.2 that it adds (without even a diagram) the two len= gth bytes for TCP transport. We're kind of stuck with the history of the DN= S RFCs here. --Paul Hoffman= From nobody Sat Aug 4 13:10:54 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0088F130DD2; Sat, 4 Aug 2018 13:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 by_9HNYQ4bzy; Sat, 4 Aug 2018 13:10:37 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-oln040092004065.outbound.protection.outlook.com [40.92.4.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62820120049; Sat, 4 Aug 2018 13:10:37 -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=aAoe83yjk3/cgMjVxjIpc6mwi2ppea23MCoPbKEC9Pc=; b=Zp9ksPriMbSRsmD0JEWKnWKOT2CswFiFU1l00TJiefpdCHuzaflKzAjeXko7VDh9Ud0V03dhtiUOWnfnVZdmXzOX5xZaIzyV/nMbCBogUPcGfExQQ79bxwziKmw8uzRkczWue0afFU0LRYTSjUOnVIWWb36LRqIpHV7qvJzoECw6em2OIHwjhC81HSBkEaKMftgPSeohSpBGCkBDO4qBtFm83TlwLRMNAJD1MTELRvjTAx5tW1w4G1mztgaNGQJ9MHJDAV5AnA4alCUXAMP2mQyiM7bH+3lcm7PU5EiGRjZb7u541/YA2cyHRqleVar9Ze8T/M5EfRPNQ9nltJzKrg== Received: from SN1NAM02FT034.eop-nam02.prod.protection.outlook.com (10.152.72.60) by SN1NAM02HT066.eop-nam02.prod.protection.outlook.com (10.152.73.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1038.13; Sat, 4 Aug 2018 20:10:35 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.72.53) by SN1NAM02FT034.mail.protection.outlook.com (10.152.72.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1038.3 via Frontend Transport; Sat, 4 Aug 2018 20:10:35 +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.1017.018; Sat, 4 Aug 2018 20:10:35 +0000 From: Star Brilliant To: DoH WG CC: "draft-ietf-doh-dns-over-https.all@ietf.org" , "gen-art@ietf.org" , IETF , Paul Hoffman , Stewart Bryant Thread-Topic: [Ext] Genart last call review of draft-ietf-doh-dns-over-https-12 Thread-Index: AQHULBmT/X489747LUGGOVuwfjKdZaSwBZFf Date: Sat, 4 Aug 2018 20:10:35 +0000 Message-ID: References: <153337279710.31560.12854746020010274260@ietfa.amsl.com> <30EE90B8-F5D0-4870-8353-FE1A0EEE11C1@icann.org> <698CDB47-161C-4FA1-959E-6259983A7FF3@gmail.com>, <9CFFA4F2-FBF8-4009-96AE-DEE4603B347A@icann.org> In-Reply-To: <9CFFA4F2-FBF8-4009-96AE-DEE4603B347A@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:5700CD0B7CCF020627CD6513F8C955674794A94B3AAFEFAD280BA0D3A3236EDC; UpperCasedChecksum:C24E57FBD674D50FF790FA89B4589083F814182FC69815EFDA17D95D8970212E; SizeAsReceived:7525; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [I39pCCYY86peo+6k0DpwiCux3W1aN/b3WMb0Fc4yqGgVQYJyKx4Yxw==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT066; 6:+yc7KcTUFcGrc9ki1PFU47la47SRluFBcnd+znMxpVm3X9RJb4qOUKrfq5omIuedni/gx32WW39gdaXUvYMeugzxpLkKTiBwjyRovUbZ/3soGZFXcTtOVcokMB6XXJzOPNy3YoZPc31yFzibZWve+BWTGbEfSJSo1xoikkLcCVspJhrC51beZa+bAankxHz/ot3iGUoBL2tRHtaYwdlHnpWSs5xtKzUAlGQrhdX4X0LXtceTx5Qbf/IxB6/dq5XbcVRCjMBQLHhyU3B9BH7rRi7Y1Nyar9BkdaYMhgxqT4vALnQdqhBFA9mtZNEhTFfOInw2pne9dNL9wpYMWUlZcQjIV0Opo6+ve25159JKapSq/5qf258olyiGFAqAlYZE0sPWdzlq5WgYrrFefzonuQ7iMZsX0dUDlWadxsiH0vf7qxgCeSBYtV3cdTgxk3cJs2K/rkZlo/NJve+F8hX2Og==; 5:7sJVNvUJXX3OeJqKvCYHlr/V/JhMbGZu/A6hEpBfOS+GxjoXTrIc79IVrPbvnTs+IuUpnHYsVJEHUue4EV96e8vqVnn1s9G/0aAhnMrKE13PEcRsz0SwQcedeawyGEZM1bCKCsLFuLnufjYr2f32jy2VSdVhxyWAyaoiJX1+uiY=; 7:zquxcK9CsVBJSjDpQArQXn10SidcuGEujv223zTfCNw+/cwoW0LO4Af7nuLdBGfsZl4YuTj0cS6dvq0VwqFSYw3zzDXl7nMatWi+CWO32fN8spcRJt9GkeUVdYMcFoBvP/YRASeSz+UMKYAJtrZGNpun3KK0daXwT+X9qd8oA6se+nB5/O83xgDGP6DZ6c9wUcD2U1D7bIkxtfP5p7LGXl8F9TmCBBpAcYIACRQT4WFQ/PQMP7pRhXCMlY+TohI4 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:SN1NAM02HT066; x-ms-traffictypediagnostic: SN1NAM02HT066: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566005)(82015058); SRVR:SN1NAM02HT066; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT066; x-forefront-prvs: 0754F7E325 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(14444005)(105586002)(106356001)(6916009)(6246003)(5250100002)(8936002)(256004)(14454004)(83332001)(81156014)(11346002)(446003)(8676002)(6436002)(6346003)(6506007)(9686003)(54906003)(486006)(87572001)(53546011)(55016002)(86362001)(102836004)(476003)(99286004)(46003)(20460500001)(2900100001)(56003)(305945005)(7696005)(229853002)(93886005)(68736007)(97736004)(73972006)(76176011)(39060400002)(25786009)(74316002)(82202002)(4326008)(5660300001)(33656002)(104016004)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT066; 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: IUzGP3cLdKZJeEdGINm4Oxht2l0eslqOeVDDqNGMyJ56LW2VuCk/Z/ImcNhXVl2s+glTAaoBEFD4HMER7ape0eMakupxRyxhhtjnebt9B+xqumU2P1MGf3ijwHsC690K21f+OeeChFZkC8+WpPTGcThL3BlDaC6dZCqhiB9znScOHANT4S3PDtgYNh/Pxsb+ly5aWbOy8k9mDQXFtznRiBylsQMXVHUX7ngAGdzjd7o= 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: c44946a0-72b1-413d-b4a7-08d5fa465723 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2018 20:10:35.8334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT066 Archived-At: Subject: Re: [Doh] [Ext] Genart last call review of 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: Sat, 04 Aug 2018 20:10:39 -0000 Hi Stewart Bryant, Just to declare that I am not the core author of the draft, but I want to g= ive my personal opinions on your questions. On Aug 4, 2018, at 10:10 AM, Stewart Bryant wrot= e: > > I do not understand. How does a system that is using this as its DNS acce= ss mechanism find the IP address of the DNS service given only the name of = the server? Yes, bootstrap is truly a problem. Currently we have (at least) 3 different= ways to solve this problem: 1) Use a traditional DNS server for bootstrapping the IP address of DoH ser= ver. Firefox's TRR uses this method. In a common situation that DoH is run insid= e a browser, this is the mostly adopted solution. 2) Anchor the IP address but still uses the host name to refer the DoH serv= er. A simple /etc/hosts will do. This is friendly to SNI and many other stuff, but with the drawback of diff= iculty to do load-balancing except by using TCP Anycast, which is much tric= kier than UDP Anycast. 3) Issue a TLS certificate directly with the IP address, and use the IP add= ress directly to refer the DoH server. Cloudflare uses this method. But most CA does not issue certificates for IP= address. And again TCP Anycast is difficult for most DNS providers. Also w= e lose the ability to dynamically update the address. There must be some more and better methods to solve the bootstrap problem. = Do we really need to force the client to use one of these methods? > How about showing the mapping of this to a 1035 message using the paramet= ers the coder would use. So for example some of that ascii is presumably th= e Name of the address being looked up. Nope, DNS wire format is a compressed binary format. It splits the domain n= ame into labels, and use a dictionary-based method to compress the message. I don't think we need to explain how the message is encoded -- that was alr= eady described in RFC1035. Neither does the reader need to understand each byte of the message -- it i= s just an ordinary DNS message that you can produce with any DNS utility li= brary.= From nobody Wed Aug 8 10:03:30 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 28B4E130E9B; Wed, 8 Aug 2018 10:03:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: doh@ietf.org Message-ID: <153374780811.6604.743758581371071183@ietfa.amsl.com> Date: Wed, 08 Aug 2018 10:03:28 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-13.txt 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, 08 Aug 2018 17:03:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS (DoH) Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-13.txt Pages : 21 Date : 2018-08-08 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-13 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 8 10:09: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 58D8C130EA1 for ; Wed, 8 Aug 2018 10:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 GdQ_DV-LNxqe for ; Wed, 8 Aug 2018 10:09:38 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5423C130EA3 for ; Wed, 8 Aug 2018 10:09:38 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 8 Aug 2018 10:09:36 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Wed, 8 Aug 2018 10:09:36 -0700 From: Paul Hoffman To: "doh@ietf.org" Thread-Topic: [Ext] [Doh] I-D Action: draft-ietf-doh-dns-over-https-13.txt Thread-Index: AQHULzm+k+qoDf8P2kqKdkGdePa3haS2jA6A Date: Wed, 8 Aug 2018 17:09:36 +0000 Message-ID: <14BC5A8C-BCD1-4804-8389-E10E721F4511@icann.org> References: <153374780811.6604.743758581371071183@ietfa.amsl.com> In-Reply-To: <153374780811.6604.743758581371071183@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <392E469E8A1A1945AC4A7D7200586EDB@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] I-D Action: draft-ietf-doh-dns-over-https-13.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, 08 Aug 2018 17:09:39 -0000 This draft includes the comments we got during IETF Last Call, which closed= earlier today. We might still get IETF Last Call comments, and we'll deal = with them as we see them. --Paul and Patrick= From nobody Thu Aug 9 10:43:10 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 E92A7130E89 for ; Thu, 9 Aug 2018 10:43:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153383658694.28659.10147611631291596919.idtracker@ietfa.amsl.com> Date: Thu, 09 Aug 2018 10:43:06 -0700 From: IETF Secretariat Archived-At: Subject: [Doh] Milestones changed for doh WG 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: Thu, 09 Aug 2018 17:43:08 -0000 Changed milestone "Submit specification for performing DNS queries over HTTPS to the IESG for publication as PS", resolved as "Done". URL: https://datatracker.ietf.org/wg/doh/about/ From nobody Sat Aug 11 01:00:28 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 D13EE130EF9; Sat, 11 Aug 2018 01:00:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Fernando Gont To: Cc: draft-ietf-doh-dns-over-https.all@ietf.org, doh@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153397442482.20828.13036371457377811227@ietfa.amsl.com> Date: Sat, 11 Aug 2018 01:00:24 -0700 Archived-At: Subject: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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: Sat, 11 Aug 2018 08:00:25 -0000 Reviewer: Fernando Gont Review result: Almost Ready Hi, all, I've reviewed this document as part of the Transport Area Review Team's (TSVART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. When done at the time of IETF Last Call, the authors should consider this review together with any other last-call comments they receive. Please always CC ​tsv-art@ietf.org if you reply to or forward this review. Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-doh-dns-over-https-13 Title: DNS Queries over HTTPS (DoH) Reviewer: Fernando Gont Review Date: August 11, 2018 Summary: This document is almost ready, but requires some clarifications and, more importantly, an analysis of the impact of switching from a connection-less protocol (UDP) to a connection-oriented protocol (HTTPS/TCP) for DNS resolution. ** Technical comments ** * Page 5: > Using the GET method is friendlier to many HTTP cache > implementations. Could the queries really be cached for the POST case? * Page 15: > It is the choice of a client to either > perform full DNSSEC validation of answers or to trust the DoH server > to do DNSSEC validation and inspect the AD (Authentic Data) bit in > the returned message to determine whether an answer was authentic or > not. Relying on the DoH server for DNSsec validation does not seem like a good idea. You want DNSsec to be end-to-end. * Page 15 (Security Considerations): DoH essentialy switches from a connection-less transport (UDP) to a connection-oriented one (TCP). This means that now the server should take care of all state-exhaustion attacks against TCP (e.g., take a look at: https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). Defending against such attacks maybe non-trivial. This should at least be mentioned in the security considerations. * Page 16:> > HTTP [RFC7230] is a stateless application-level protocol and > therefore DoH implementations do not provide stateful ordering > guarantees between different requests. Are you meaning that requests that are pipelined could be responded in different order? Something else? * Page 16: > A DoH server is allowed to answer queries with any valid DNS > response. For example, a valid DNS response might have the TC > (truncation) bit set in the DNS header to indicate that the server > was not able to retrieve a full answer for the query but is providing > the best answer it could get. A DoH server can reply to queries with > an HTTP error for queries that it cannot fulfill. Why should this happen? Why not encode this information in the encoded DNS response (in wire format)' ** Editorial comments ** Page 3: > Two primary uses cases were considered during this protocol's > development. s/uses/use/ Page 3: Please introduce and expand de acronym "DoH" the first time you employ it. Page 7: > This might mean that the > DoH client retries the query with the same DoH server, such as > authorization failures (HTTP status code 401 [RFC7235] Section 3.1). s/such as/such as for/ ? * Page 16:> Note that these deadlocks > also need to be considered for server that a DoH server might > redirect to. s/for server/for servers/ ? Thanks! Fernando From nobody Sat Aug 11 15:57: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 79719130E66; Sat, 11 Aug 2018 15:57:03 -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 JzFXEVUUHBmE; Sat, 11 Aug 2018 15:56:59 -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 294BE1277CC; Sat, 11 Aug 2018 15:56:58 -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 3B4D53A021; Sat, 11 Aug 2018 18:56:57 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id w126-v6so21593772oie.7; Sat, 11 Aug 2018 15:56:57 -0700 (PDT) X-Gm-Message-State: AOUpUlHp8AYdUjerXcmeYYytRFCNzyXHha+zmEco5rwZSCycvtDvTlzB b9TLjmYjxdIWfodmc0yM57ybDQXAwPYU/2i9XGE= X-Google-Smtp-Source: AA+uWPxL2BUqep/cgxsgeXoGKcHJM4MjZ4shoMcTUl0vdn7dZTJJl4pj5mj62fmh3qt3rPKtbK2osyXWgTYZ4SbuXe4= X-Received: by 2002:aca:5f0a:: with SMTP id t10-v6mr11440444oib.337.1534028216877; Sat, 11 Aug 2018 15:56:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Sat, 11 Aug 2018 15:56:56 -0700 (PDT) In-Reply-To: <153397442482.20828.13036371457377811227@ietfa.amsl.com> References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> From: Patrick McManus Date: Sat, 11 Aug 2018 18:56:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: tsv-art@ietf.org, draft-ietf-doh-dns-over-https.all@ietf.org, DoH WG , IETF Discussion Mailing List Content-Type: multipart/alternative; boundary="000000000000f149d2057330c6b0" Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 11 Aug 2018 22:57:04 -0000 --000000000000f149d2057330c6b0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable thanks for the review! On Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont wrote: > > * Page 5: > > Using the GET method is friendlier to many HTTP cache > > implementations. > > Could the queries really be cached for the POST case? > > sometimes. sort of. see 7231 4.3.3 > * Page 15: > > It is the choice of a client to either > > perform full DNSSEC validation of answers or to trust the DoH server > > to do DNSSEC validation and inspect the AD (Authentic Data) bit in > > the returned message to determine whether an answer was authentic or > > not. > > Relying on the DoH server for DNSsec validation does not seem like a good > idea. > You want DNSsec to be end-to-end. > > my understanding is that giving the client the choice between doing DNSSEC validation and trusting the recursive to do so is standard DNS practice. > * Page 15 (Security Considerations): > > DoH essentialy switches from a connection-less transport (UDP) to a > connection-oriented one (TCP). I disagree a bit. It adds a third TCP based DNS based approach to the DNS over TCP and DNS over TLS approaches already standardized so it is not breaking new ground in that sense. This means that now the server should take care > of all state-exhaustion attacks against TCP (e.g., take a look at: > https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). > Defending > against such attacks maybe non-trivial. This should at least be mentioned > in > the security considerations. > > DoH seeks to use HTTPS substrate best practices in order to inherit the well known properties and defenses of HTTPS. The first sentence of the security considerations tries to say this "Running DNS over HTTPS relies on the security of the underlying HTTP transport." I don't think it makes sense to have each foo-over-http consider the baseline considerations separately. > * Page 16:> > > HTTP [RFC7230] is a stateless application-level protocol and > > therefore DoH implementations do not provide stateful ordering > > guarantees between different requests. > > Are you meaning that requests that are pipelined could be responded in > different order? Something else? > > one of the relevant things http means when it says it is stateless (which iirc is the first sentence of 7230) is the requests themselves can also be reordered by intermediaries or even routed onto different connections.. some may hit various caches and not even be placed on the connection. sometimes the 'intermediary' is the library or javascript engine you are using - DoH is meant to be expressable at the semantic layer of bodies and headers. This particular point was raised in conjunction with dnsop's session signal draft which requires a stateful DNS transport.. HTTPS is stateless message based (despite being layered on TCP) and therefore we want to be clear DoH won't work for building a session layer. (that draft is coordinated). > * Page 16: > > A DoH server is allowed to answer queries with any valid DNS > > response. For example, a valid DNS response might have the TC > > (truncation) bit set in the DNS header to indicate that the server > > was not able to retrieve a full answer for the query but is providin= g > > the best answer it could get. A DoH server can reply to queries wit= h > > an HTTP error for queries that it cannot fulfill. > > Why should this happen? Why not encode this information in the encoded DN= S > response (in wire format)' > > I'll let paul answer that - he does it more concisely than I can manage :) > ** Editorial comments ** > > Page 3: > > Two primary uses cases were considered during this protocol's > > development. > > s/uses/use/ > > thanks! > Page 3: > Please introduce and expand de acronym "DoH" the first time you employ it= . > > ack Page 7: > > > This might mean that the > > DoH client retries the query with the same DoH server, such as > > authorization failures (HTTP status code 401 [RFC7235] Section 3.1). > > s/such as/such as for/ ? > > thanks > * Page 16:> Note that these deadlocks > > also need to be considered for server that a DoH server might > > redirect to. > > s/for server/for servers/ ? > > > thanks On Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont wrote: > Reviewer: Fernando Gont > Review result: Almost Ready > > Hi, all, > > I've reviewed this document as part of the Transport Area Review Team's > (TSVART) ongoing effort to review key IETF documents. These comments were > written primarily for the transport area directors, but are copied to the > document's authors for their information and to allow them to address any > issues raised. When done at the time of IETF Last Call, the authors shoul= d > consider this review together with any other last-call comments they > receive. > Please always CC =E2=80=8Btsv-art@ietf.org if you reply to or forward thi= s review. > > Please resolve these comments along with any other Last Call comments you > may > receive. Please wait for direction from your document shepherd or AD befo= re > posting a new version of the draft. > > Document: draft-ietf-doh-dns-over-https-13 > Title: DNS Queries over HTTPS (DoH) > Reviewer: Fernando Gont > Review Date: August 11, 2018 > > Summary: > > This document is almost ready, but requires some clarifications and, more > importantly, an analysis of the impact of switching from a connection-les= s > protocol (UDP) to a connection-oriented protocol (HTTPS/TCP) for DNS > resolution. > > ** Technical comments ** > > * Page 5: > > Using the GET method is friendlier to many HTTP cache > > implementations. > > Could the queries really be cached for the POST case? > > * Page 15: > > It is the choice of a client to either > > perform full DNSSEC validation of answers or to trust the DoH server > > to do DNSSEC validation and inspect the AD (Authentic Data) bit in > > the returned message to determine whether an answer was authentic or > > not. > > Relying on the DoH server for DNSsec validation does not seem like a good > idea. > You want DNSsec to be end-to-end. > > * Page 15 (Security Considerations): > > DoH essentialy switches from a connection-less transport (UDP) to a > connection-oriented one (TCP). This means that now the server should take > care > of all state-exhaustion attacks against TCP (e.g., take a look at: > https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). > Defending > against such attacks maybe non-trivial. This should at least be mentioned > in > the security considerations. > > * Page 16:> > > HTTP [RFC7230] is a stateless application-level protocol and > > therefore DoH implementations do not provide stateful ordering > > guarantees between different requests. > > Are you meaning that requests that are pipelined could be responded in > different order? Something else? > > * Page 16: > > A DoH server is allowed to answer queries with any valid DNS > > response. For example, a valid DNS response might have the TC > > (truncation) bit set in the DNS header to indicate that the server > > was not able to retrieve a full answer for the query but is providin= g > > the best answer it could get. A DoH server can reply to queries wit= h > > an HTTP error for queries that it cannot fulfill. > > Why should this happen? Why not encode this information in the encoded DN= S > response (in wire format)' > > ** Editorial comments ** > > Page 3: > > Two primary uses cases were considered during this protocol's > > development. > > s/uses/use/ > > Page 3: > Please introduce and expand de acronym "DoH" the first time you employ it= . > > Page 7: > > > This might mean that the > > DoH client retries the query with the same DoH server, such as > > authorization failures (HTTP status code 401 [RFC7235] Section 3.1). > > s/such as/such as for/ ? > > * Page 16:> Note that these deadlocks > > also need to be considered for server that a DoH server might > > redirect to. > > s/for server/for servers/ ? > > Thanks! > Fernando > > > --000000000000f149d2057330c6b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
thanks for the review!


On Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont <fgont@si= 6networks.com> wrote:

* Page 5:
>=C2=A0 Using the GET method is friendlier to many HTTP cache
>=C2=A0 implementations.

Could the queries really be cached for the POST case?


sometimes. sort of. see 7231 4.= 3.3
=C2=A0
* Page 15:
> It is the choice of a client to either
>=C2=A0 =C2=A0 perform full DNSSEC validation of answers or to trust the= DoH server
>=C2=A0 =C2=A0 to do DNSSEC validation and inspect the AD (Authentic Dat= a) bit in
>=C2=A0 =C2=A0 the returned message to determine whether an answer was a= uthentic or
>=C2=A0 =C2=A0 not.

Relying on the DoH server for DNSsec validation does not seem like a good i= dea.
You want DNSsec to be end-to-end.


my understanding is that=20 giving the client the choice between doing DNSSEC validation and=20 trusting the recursive to do so is standard DNS practice.

=C2=A0
* Page 15 (Security Considerations):

DoH essentialy switches from a connection-less transport (UDP) to a
connection-oriented one (TCP).

I=20 disagree a bit. It adds a third TCP based DNS based approach to the DNS=20 over TCP and DNS over TLS approaches already standardized so it is not=20 breaking new ground in that sense.
<= br>
This means that= now the server should take care
of all state-exhaustion attacks against TCP (e.g., take a look at:
https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). Defending
against such attacks maybe non-trivial. This should at least be mentioned i= n
the security considerations.


DoH seeks to use HTTPS=20 substrate best practices in order to inherit the well known properties=20 and defenses of HTTPS. The first sentence of the security considerations tries to say this "Running DNS over HTTPS relies on the security of t= he underlying HTTP transport." I don't think it makes sense to have = each=20 foo-over-http consider the baseline considerations separately.
=C2=A0
* Page 16:>
>=C2=A0 =C2=A0 HTTP [RFC7230] is a stateless application-level protocol = and
>=C2=A0 =C2=A0 therefore DoH implementations do not provide stateful ord= ering
>=C2=A0 =C2=A0 guarantees between different requests.

Are you meaning that requests that are pipelined could be responded in
different order? Something else?


one of the relevant things=20 http means when it says it is stateless (which iirc is the first=20 sentence of 7230) is the requests themselves can also be reordered by=20 intermediaries or even routed onto different connections.. some may hit=20 various caches and not even be placed on the connection. sometimes the=20 'intermediary' is the library or javascript engine you are using - = DoH=20 is meant to be expressable at the semantic layer of bodies and headers.=20 This particular point was raised in conjunction with dnsop's session=20 signal draft which requires a stateful DNS transport.. HTTPS is=20 stateless message based (despite being layered on TCP) and therefore we=20 want to be clear DoH won't work for building a session layer. (that=20 draft is coordinated).
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> * Page 16:
>=C2=A0 =C2=A0 A DoH server is allowed to answer queries with any valid = DNS
>=C2=A0 =C2=A0 response.=C2=A0 For example, a valid DNS response might h= ave the TC
>=C2=A0 =C2=A0 (truncation) bit set in the DNS header to indicate that t= he server
>=C2=A0 =C2=A0 was not able to retrieve a full answer for the query but = is providing
>=C2=A0 =C2=A0 the best answer it could get.=C2=A0 A DoH server can repl= y to queries with
>=C2=A0 =C2=A0 an HTTP error for queries that it cannot fulfill.

Why should this happen? Why not encode this information in the encoded DNS<= br> response (in wire format)'


I'll let paul answer that -= he does it more concisely than I can manage :)
=C2=A0
** Editorial comments **

Page 3:
>=C2=A0 Two primary uses cases were considered during this protocol'= s
>=C2=A0 development.

s/uses/use/


thanks!
=C2=A0
Page 3:
Please introduce and expand de acronym "DoH" the first time you e= mploy it.


ack

Page 7:

> This might mean that the
>=C2=A0 =C2=A0 DoH client retries the query with the same DoH server, su= ch as
>=C2=A0 =C2=A0 authorization failures (HTTP status code 401 [RFC7235] Se= ction 3.1).

s/such as/such as for/ ?

thanks
= =C2=A0
* Page 16:> Note that these deadlocks
>=C2=A0 =C2=A0 also need to be considered for server that a DoH server m= ight
>=C2=A0 =C2=A0 redirect to.

s/for server/for servers/ ?


thanks


O= n Sat, Aug 11, 2018 at 4:00 AM, Fernando Gont <fgont@si6networks.com> wrote:
Reviewer: Fernando G= ont
Review result: Almost Ready

Hi, all,

I've reviewed this document as part of the Transport Area Review Team&#= 39;s
(TSVART) ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address a= ny
issues raised. When done at the time of IETF Last Call, the authors should<= br> consider this review together with any other last-call comments they receiv= e.
Please always CC =E2=80=8Btsv-art@ietf.= org if you reply to or forward this review.

Please resolve these comments along with any other Last Call comments you m= ay
receive. Please wait for direction from your document shepherd or AD before=
posting a new version of the draft.

Document: draft-ietf-doh-dns-over-https-13
Title: DNS Queries over HTTPS (DoH)
Reviewer: Fernando Gont
Review Date: August 11, 2018

Summary:

This document is almost ready, but requires some clarifications and, more importantly, an analysis of the impact of switching from a connection-less<= br> protocol (UDP) to a connection-oriented protocol (HTTPS/TCP) for DNS resolu= tion.

** Technical comments **

* Page 5:
>=C2=A0 Using the GET method is friendlier to many HTTP cache
>=C2=A0 implementations.

Could the queries really be cached for the POST case?

* Page 15:
> It is the choice of a client to either
>=C2=A0 =C2=A0 perform full DNSSEC validation of answers or to trust the= DoH server
>=C2=A0 =C2=A0 to do DNSSEC validation and inspect the AD (Authentic Dat= a) bit in
>=C2=A0 =C2=A0 the returned message to determine whether an answer was a= uthentic or
>=C2=A0 =C2=A0 not.

Relying on the DoH server for DNSsec validation does not seem like a good i= dea.
You want DNSsec to be end-to-end.

* Page 15 (Security Considerations):

DoH essentialy switches from a connection-less transport (UDP) to a
connection-oriented one (TCP). This means that now the server should take c= are
of all state-exhaustion attacks against TCP (e.g., take a look at:
https://www.gont.com.ar/pape= rs/tn-03-09-security-assessment-TCP.pdf). Defending
against such attacks maybe non-trivial. This should at least be mentioned i= n
the security considerations.

* Page 16:>
>=C2=A0 =C2=A0 HTTP [RFC7230] is a stateless application-level protocol = and
>=C2=A0 =C2=A0 therefore DoH implementations do not provide stateful ord= ering
>=C2=A0 =C2=A0 guarantees between different requests.

Are you meaning that requests that are pipelined could be responded in
different order? Something else?

* Page 16:
>=C2=A0 =C2=A0 A DoH server is allowed to answer queries with any valid = DNS
>=C2=A0 =C2=A0 response.=C2=A0 For example, a valid DNS response might h= ave the TC
>=C2=A0 =C2=A0 (truncation) bit set in the DNS header to indicate that t= he server
>=C2=A0 =C2=A0 was not able to retrieve a full answer for the query but = is providing
>=C2=A0 =C2=A0 the best answer it could get.=C2=A0 A DoH server can repl= y to queries with
>=C2=A0 =C2=A0 an HTTP error for queries that it cannot fulfill.

Why should this happen? Why not encode this information in the encoded DNS<= br> response (in wire format)'

** Editorial comments **

Page 3:
>=C2=A0 Two primary uses cases were considered during this protocol'= s
>=C2=A0 development.

s/uses/use/

Page 3:
Please introduce and expand de acronym "DoH" the first time you e= mploy it.

Page 7:

> This might mean that the
>=C2=A0 =C2=A0 DoH client retries the query with the same DoH server, su= ch as
>=C2=A0 =C2=A0 authorization failures (HTTP status code 401 [RFC7235] Se= ction 3.1).

s/such as/such as for/ ?

* Page 16:> Note that these deadlocks
>=C2=A0 =C2=A0 also need to be considered for server that a DoH server m= ight
>=C2=A0 =C2=A0 redirect to.

s/for server/for servers/ ?

Thanks!
Fernando



--000000000000f149d2057330c6b0-- From nobody Sat Aug 11 15:59: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 7979C130EA7; Sat, 11 Aug 2018 15:58:51 -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 3BaFZRjWJZvC; Sat, 11 Aug 2018 15:58:49 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001084.outbound.protection.outlook.com [40.92.1.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5240C130E66; Sat, 11 Aug 2018 15:58:49 -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=nmMZDJ5mAi8wL41EeDSBqUqqV8XUDNCC23Qdv3WB1bA=; b=L8kQPBpZqAOT/vpqU5wAQP0ZQOBime3FeH7IKp67k5NNB1JFFzj1+J3JV/TpZe5f5EQshVlOf9KLjlW7FIs0Xjqlq/q89SkON0W2ZcRXtfUaPsIrMd0o3diTWZCY5+q1m8UPduN0xX7fWj92YrqSA94gowGIEPPV7N3C4i14zQTMU02coJtFL32vE4xdm7HIMzL985osJ/FaJidapTtvVjlmS38oMsJ3GYqYxoKYFEA3dNChhbp8andgxAeqIXp/tzKHpjVh1u5j1xeHRjhvp2D77ToWoIRMpiBhrcZHOYxSizXJOLIDPnCmPQJXs2yhabbpFrf1AySCLS0mJYMoSQ== Received: from BN3NAM01FT062.eop-nam01.prod.protection.outlook.com (10.152.66.54) by BN3NAM01HT113.eop-nam01.prod.protection.outlook.com (10.152.67.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1059.14; Sat, 11 Aug 2018 22:58:47 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.66.51) by BN3NAM01FT062.mail.protection.outlook.com (10.152.66.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1059.14 via Frontend Transport; Sat, 11 Aug 2018 22:58:47 +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.1017.022; Sat, 11 Aug 2018 22:58:47 +0000 From: Star Brilliant To: Fernando Gont , "tsv-art@ietf.org" CC: "draft-ietf-doh-dns-over-https.all@ietf.org" , "doh@ietf.org" , "ietf@ietf.org" Thread-Topic: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 Thread-Index: AQHUMUlhaDwSy0sptEW0dunH9M5M5KS7KvSO Date: Sat, 11 Aug 2018 22:58:46 +0000 Message-ID: References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> In-Reply-To: <153397442482.20828.13036371457377811227@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:C5112A405350CFB317DED646B0A409C3281A592E5DDF4F41D9D5D873D25B84A5; UpperCasedChecksum:33E28FD45CA8979727CAF65B463DBDA2247244BFC70546C54406FC543AA919BE; SizeAsReceived:7353; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ZxYXnT8uXioYZpHvBMTmQOiNxjD0gpKhoEJoRXa1He1YlSecDpWIPw==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT113; 6:KlC40OXpNb//b1up9gYQ+Cz1fRObP4/s9SL16tUjVigGI3AMrWKl7Ujg0cP5WGqV+Cya/ZsvsiITfK15jm1vYd2bnh7MCncff3rF+AHGWCJApkkcJEkrZpK8/Qpfq2HOeRNFtxMhPXGhobtKgQx9otbVkonJKKUqSZREObRO3YpWjf0PIk4lYSPycG77LxG5f3LB7l/RPB7kQGg3xUszFWmk9uFij5lvtquhxtm5qE5mMWonOXEkwZGUDEhSW8nuWoNSzd2sBpse7aWp2JpbTYlWWHcXfb0iqAVkHrRvyLiLByfOpxsmXhqKS/F968VLaUJdaigtQv8SHPemV6OdWqfbPfdBwBrC5CzQFrofacdpsBre2k/EGmUggszNRK2bSo5v9E8SJF27l/+rtk528niAVTp7v4sGvcLjaUgV+AfN/d0Vhwb4ZS3grh1WO48IopNtZn/bVfHSj33++wnvZA==; 5:yCF8TTaB2u4EHJ1hSTft+l+1OqKF8Th2VipgFsViBrcmfTZUY/aLMuKl1sMNNaFfU+gcSkijWjan5/BmwPmm2JPuA82cxd/dEhOBS85FQJDgtY1SyvjPqyauFkWQklGscm9tlnRVVE+kenFmdrQwMdZZg7/eGqzgfYn5P+4JDDI=; 7:ca7oBrHKZckWuE+/rDgbnlU4j1vOiCt6HjzITpO33GDHjEazpEncnd8LSx95daWfDtPROszDF8uRCEwTm/hbkR/7XlTc3SLR0FouZAgkULGHC9Ibl/sPryUiwWA41d4o1Twv1vDnk1Ng9bRQArv6e48oy+PuoFhx8ERs5yhtvQFNqURBeGKSZjwDBxi2YbVgBSrqbiAQHhWMGWlwjjFO5kAhJtZuSGhpD4Pkb9i8j9cQ1yAL9dU7tlpNE+P+Y+D8 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:BN3NAM01HT113; x-ms-traffictypediagnostic: BN3NAM01HT113: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BN3NAM01HT113; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT113; x-forefront-prvs: 0761DE1EDD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(43544003)(25786009)(5250100002)(4326008)(68736007)(83332001)(2900100001)(73972006)(55016002)(97736004)(20460500001)(14454004)(6306002)(56003)(229853002)(6246003)(9686003)(966005)(86362001)(6436002)(104016004)(2501003)(82202002)(14444005)(256004)(486006)(476003)(54906003)(110136005)(53546011)(6506007)(5660300001)(11346002)(8936002)(8676002)(99286004)(7696005)(76176011)(106356001)(46003)(105586002)(74316002)(305945005)(81156014)(87572001)(446003)(33656002)(102836004)(6346003)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT113; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: EQa1GG7HKtsV9EsfCG3FQx8+RzHzG+s37NJZ8n8JFtDw3M5WXq48ltr1xWQcrehOmyuDTwoonr8rIEBURTElIxm6KLbST3bTel7HWMRkKJdwGkkKmQVQrEMnoX1yCICJp4911HdBx+cAuu45kPgJaSaoJXn2N2TpUdZmqqxGr+QtIYsEP09Tux1Pw9PF9xAENMqykS9KSU46y4k0NFbwz4DGDskIbbtWfLuL7hOsFrQ= 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: 8d44a50c-fc30-4a00-906f-08d5ffddfeca X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2018 22:58:46.9135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT113 Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 11 Aug 2018 22:58:52 -0000 Hello Femando and the mail list, Thanks for your review! I would like to answer some of the questions based on what the contributors= had discussed before. Paul Hoffman is the core author, so if I made a mistake, please consider hi= s answer as the authoritative. On Sat, Aug 11, 2018 at 6:00 PM Fernando Gont wrote= : > > * Page 5: > > Using the GET method is friendlier to many HTTP cache > > implementations. > > Could the queries really be cached for the POST case? Yes, they can. >From RFC 7231: "In general, safe methods that do not depend on a current or= authoritative response are defined as cacheable; this specification define= s GET, HEAD, and POST as cacheable, although the overwhelming majority of c= ache implementations only support GET and HEAD." But GET is friendlier than POST, because of the fact most ISP's transparent= proxy or cloud WAF systems do not cache POST. > * Page 15: > > It is the choice of a client to either > > perform full DNSSEC validation of answers or to trust the DoH server > > to do DNSSEC validation and inspect the AD (Authentic Data) bit in > > the returned message to determine whether an answer was authentic or > > not. > > Relying on the DoH server for DNSsec validation does not seem like a good= idea. > You want DNSsec to be end-to-end. We discussed about this paragraph before. The problem depends on how you de= ploy DoH services. 1) For most people's needs, the users grab a list of DoH servers from the I= nternet and configure their systems to use the DoH servers. These public se= rvers are untrustworthy. So the users need to validate DNSSEC at their end. 2) A web-based application using DoH with a pre-configured server maintaine= d by the application author. Then the server has the same trust level as th= e JavaScript code that validates the records. If anyone does not trust the = server, they should not use the web app. In addition, by checking the recor= ds on the server, we can save some bandwidth for mobile users. 3) A dedicated enterprise cloud environment with hundreds of machines, serv= ing trillions of requests per day. The administrator would want to offload = the DNSSEC check to the gateway to reduce service latency, improve cache hi= t-rate, reduce intra-AS bandwidth cost, and to increase service quality. 4) A resource-constrained device (some Arduino or ESP8266 or other IoT-like= things). You will want to delegate the check to your PC as long as the PC = can be trusted. Conclusion: People use DoH in different ways. Sometimes it is better to "gi= ve the user more choices, but make the default choice secure". Therefore, we have the text "It is the choice of a client to either trust o= r distrust". > > * Page 15 (Security Considerations): > > DoH essentialy switches from a connection-less transport (UDP) to a > connection-oriented one (TCP). This means that now the server should take= care > of all state-exhaustion attacks against TCP (e.g., take a look at: > https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). Def= ending > against such attacks maybe non-trivial. This should at least be mentioned= in > the security considerations. > > * Page 16:> > > HTTP [RFC7230] is a stateless application-level protocol and > > therefore DoH implementations do not provide stateful ordering > > guarantees between different requests. > > Are you meaning that requests that are pipelined could be responded in > different order? Something else? The DNS wire protocol is not always a single query-and-response model. Some= functions (e.g. zone transfer) require multiple messages to be sent and re= ceived. As already stated in the text elsewhere, DoH does not support this = kind of functions (at least not in this version). > > * Page 16: > > A DoH server is allowed to answer queries with any valid DNS > > response. For example, a valid DNS response might have the TC > > (truncation) bit set in the DNS header to indicate that the server > > was not able to retrieve a full answer for the query but is providin= g > > the best answer it could get. A DoH server can reply to queries wit= h > > an HTTP error for queries that it cannot fulfill. > > Why should this happen? Why not encode this information in the encoded DN= S > response (in wire format)' If you are asking about "an HTTP error", here is the explain: 1) Some errors indicates a problem happening on HTTP layer, not DNS layer. For example, 302 Redirection, 404 Not Found, 401 Unauthorized 2) Sometimes it is technically impossible to reply with an encoded DNS resp= onse. For example, the web server crashed, throwing a default 500-504 error page DoH is a double-layered protocol. It is intuitive that each layer may break= , resulting with an error that represents that layer. (Additionally, since = DoH runs on TCP/IP, a DoH server can even reply with an icmp-port-unreachab= le error.) Layered error is the nature of Internet protocols. If you are asking about the TC bit, this happens in many situations. One ca= use is broken TCP on the authoritative server, which happens quite frequent= ly with anycast servers.= From nobody Sat Aug 11 16:20: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 A9CB0124BE5; Sat, 11 Aug 2018 16:19:50 -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 YkOCgN27LCQT; Sat, 11 Aug 2018 16:19:48 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FBF2127333; Sat, 11 Aug 2018 16:19:48 -0700 (PDT) Received: from [192.168.1.250] (unknown [109.103.90.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A23D18250A; Sun, 12 Aug 2018 01:19:46 +0200 (CEST) To: Patrick McManus Cc: tsv-art@ietf.org, draft-ietf-doh-dns-over-https.all@ietf.org, DoH WG , IETF Discussion Mailing List References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <90445a8e-be3f-8752-c8ee-6e021c621ed5@si6networks.com> Date: Sun, 12 Aug 2018 01:19:09 +0200 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 11 Aug 2018 23:19:51 -0000 On 08/11/2018 09:20 PM, Patrick McManus wrote: > * Page 15: > > It is the choice of a client to either > >    perform full DNSSEC validation of answers or to trust the DoH > server > >    to do DNSSEC validation and inspect the AD (Authentic Data) bit in > >    the returned message to determine whether an answer was > authentic or > >    not. > > Relying on the DoH server for DNSsec validation does not seem like a > good idea. > You want DNSsec to be end-to-end. > > > my understanding is that giving the client the choice between doing > DNSSEC validation and trusting the recursive to do so is standard DNS > practice. What I had in mind when making this comment is this: There seem to be anycast resolvers implementing DoH (e.g., CLoudflare's and others, if I understand correctly). Giving them the responsibility for DNSsec validation would seem to me as giving them way too much power (i.e., what if they were compromised and/or went evil?) > * Page 15 (Security Considerations): > > DoH essentialy switches from a connection-less transport (UDP) to a > connection-oriented one (TCP). > > I disagree a bit. It adds a third TCP based DNS based approach to the > DNS over TCP and DNS over TLS approaches already standardized so it is > not breaking new ground in that sense. To put it in a different way: * What would be the impact if an attacker were to DoS TCP-based resolution in the traditional case? (i.e., while UDP-based resolution still works) * What would be the impact if an attacker were to DoS (HTTPS/)TCP-based resolution in the DoH case? If the impact were the same, then just say that, and no need to worry. But my understanding is that in current deployments you normally only fall back to TCP when the UDP response was truncated, whereas with DoH, you rely 100% on TCP. > This means that now the server should take care > of all state-exhaustion attacks against TCP (e.g., take a look at: > https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf > ). > Defending > against such attacks maybe non-trivial. This should at least be > mentioned in > the security considerations. > > DoH seeks to use HTTPS substrate best practices in order to inherit the > well known properties and defenses of HTTPS. The first sentence of the > security considerations tries to say this "Running DNS over HTTPS relies > on the security of the underlying HTTP transport." I don't think it > makes sense to have each foo-over-http consider the baseline > considerations separately. I don't mean you need to elaborate on how to defend it. JUst noted that if you completely get rid of UDP-base resolution, then the TCP one (in this case DoH) becomes even more critical, and the impact of a DoS against TCP-based resolution is higher. And defending a stateful protocol like TCP against resource exhaustion attacks is non-trivial. >   > > * Page 16:> > >    HTTP [RFC7230] is a stateless application-level protocol and > >    therefore DoH implementations do not provide stateful ordering > >    guarantees between different requests. > > Are you meaning that requests that are pipelined could be responded in > different order? Something else? > > > one of the relevant things http means when it says it is stateless > (which iirc is the first sentence of 7230) is the requests themselves > can also be reordered by intermediaries or even routed onto different > connections.. some may hit various caches and not even be placed on the > connection. sometimes the 'intermediary' is the library or javascript > engine you are using - DoH is meant to be expressable at the semantic > layer of bodies and headers. This particular point was raised in > conjunction with dnsop's session signal draft which requires a stateful > DNS transport.. HTTPS is stateless message based (despite being layered > on TCP) and therefore we want to be clear DoH won't work for building a > session layer. (that draft is coordinated). Maybe I'm a bit confused. If, on the same connection, I send a request to resolve "A" and subsequently a request to resolve "B", the result of the later might come before than the result of the former? (I'm trying to understand what the "ordering guarantees" that are not provided with DoH). Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Aug 11 16:35: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 DA367130DDF; Sat, 11 Aug 2018 16:35:02 -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 t1qZs-THUxos; Sat, 11 Aug 2018 16:35:01 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8196124BE5; Sat, 11 Aug 2018 16:35:00 -0700 (PDT) Received: from [192.168.1.250] (unknown [109.103.90.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8C8D680D0D; Sun, 12 Aug 2018 01:34:57 +0200 (CEST) To: Star Brilliant , "tsv-art@ietf.org" Cc: "draft-ietf-doh-dns-over-https.all@ietf.org" , "doh@ietf.org" , "ietf@ietf.org" References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: <508cc0f8-4826-ac8c-f52f-704a02f0bb9a@si6networks.com> Date: Sun, 12 Aug 2018 01:34:38 +0200 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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 11 Aug 2018 23:35:03 -0000 Hello, Thanks for the response. Inline.... On 08/12/2018 12:58 AM, Star Brilliant wrote: >> * Page 15: >>> It is the choice of a client to either >>> perform full DNSSEC validation of answers or to trust the DoH server >>> to do DNSSEC validation and inspect the AD (Authentic Data) bit in >>> the returned message to determine whether an answer was authentic or >>> not. >> >> Relying on the DoH server for DNSsec validation does not seem like a good idea. >> You want DNSsec to be end-to-end. > > We discussed about this paragraph before. The problem depends on how you deploy DoH services. > > 1) For most people's needs, the users grab a list of DoH servers from the Internet and configure their systems to use the DoH servers. These public servers are untrustworthy. So the users need to validate DNSSEC at their end. This is the scenario I was assuming, for which it seemed a bad idea to ahve the DOH server do DNSsec validation. Anyway to clarify this so that others do't fall into the same assumption? >> * Page 16: >>> A DoH server is allowed to answer queries with any valid DNS >>> response. For example, a valid DNS response might have the TC >>> (truncation) bit set in the DNS header to indicate that the server >>> was not able to retrieve a full answer for the query but is providing >>> the best answer it could get. A DoH server can reply to queries with >>> an HTTP error for queries that it cannot fulfill. >> >> Why should this happen? Why not encode this information in the encoded DNS >> response (in wire format)' > > If you are asking about "an HTTP error", here is the explain: > > 1) Some errors indicates a problem happening on HTTP layer, not DNS layer. > For example, 302 Redirection, 404 Not Found, 401 Unauthorized > > 2) Sometimes it is technically impossible to reply with an encoded DNS response. > For example, the web server crashed, throwing a default 500-504 error page > > DoH is a double-layered protocol. It is intuitive that each layer may break, resulting with an error that represents that layer. (Additionally, since DoH runs on TCP/IP, a DoH server can even reply with an icmp-port-unreachable error.) Layered error is the nature of Internet protocols. > > If you are asking about the TC bit, this happens in many situations. One cause is broken TCP on the authoritative server, which happens quite frequently with anycast servers. My understanding of the quoted text above was that DoH might signal via HTTP error codes some events that could also be signaled via DNS responses. -- whereas my expectation was for HTTP response codes to only signal stuff related to HTTP stransport. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Aug 11 16:35: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 99AE713113F; Sat, 11 Aug 2018 16:35:09 -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 lMBcL8QkvCZW; Sat, 11 Aug 2018 16:35:07 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-oln040092006077.outbound.protection.outlook.com [40.92.6.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 8492413111E; Sat, 11 Aug 2018 16:35:07 -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=pxkZ+OASaDZ8EOTQwxdBBASJcd92YiebIg3Od8rhaNc=; b=cmixsPr11D7hJnn9unst9oTkPtIGanUgy/bqIPe7hbxdB0e+9m0PA3qxOhEAt62EME9iE/U57NqQHcDXxvTIcK7WFU6YvMQEnA6cC9BFzoohXf5KRkyaAE+mVJRmftUhrUKSkCtVBUQSA5PLpAUAGX7DCabkuvITpkGkuT2dHKhz2VEkoSpW8NWViUCsgfdWRREfyUksVhjSzQHdHGFi74PkwUOE3Pt9LPsCa2/ReWvEbGZ4heRNLi8fbbwNHFUsXVyvsXTe4soJm1IC4fvqx7J57Ahm44X8M9V8+PrZBYkTbvHoCr85rTv2w+MgSIKZBkzNDFQtsNmJ2xOu6kwmOw== Received: from CO1NAM03FT012.eop-NAM03.prod.protection.outlook.com (10.152.80.56) by CO1NAM03HT162.eop-NAM03.prod.protection.outlook.com (10.152.81.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1038.13; Sat, 11 Aug 2018 23:35:06 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.80.51) by CO1NAM03FT012.mail.protection.outlook.com (10.152.80.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14 via Frontend Transport; Sat, 11 Aug 2018 23:35:06 +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.1017.022; Sat, 11 Aug 2018 23:35:06 +0000 From: Star Brilliant To: Fernando Gont , "tsv-art@ietf.org" CC: "draft-ietf-doh-dns-over-https.all@ietf.org" , "doh@ietf.org" , "ietf@ietf.org" Thread-Topic: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 Thread-Index: AQHUMUlhaDwSy0sptEW0dunH9M5M5KS7KvSOgAAI2ys= Date: Sat, 11 Aug 2018 23:35:05 +0000 Message-ID: References: <153397442482.20828.13036371457377811227@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:F2397544907676F64FB5182F85257293CEC5F8C9F07F97313DF8EF17AB33CF75; UpperCasedChecksum:B448E7E9ADEE11AE8E1CB17D05E273E8BF1B67F64EE3BB704AE7278C2156489F; SizeAsReceived:7481; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [lTNi+I7yo5K/3Dg+fcFYQO0+dYHAQOs1OY8k7rNVGTgZZMsHkyKdnw==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM03HT162; 6:eQG6cXws7cQtpAp10bV1h9GStSrQ/l1ZcXPvyoGgMr4Wp0gneV/tdcuZbU7a6KP+y3iEbYguMD5K6Zuh5bUltr/r+NdRuIcB4duU+GHUlJqE9EAHPbtNLaAOT2NpOCkPumHzxaBO9QQT50JKH4qwJPuvr/0ozPtsmu3LMLEyGg/g2NPMuoKh4fPu+SwQfNm2yXnEk+zLCXwgbR0KArLaY4nZlI1NrWphM0/W459DUL5hoLpoyCXPg0YH2yocuG6/fTMTi8z3HkVmP7UMNJJ/whTFDN5FuAmcXCncum79LTc+9Akp1khYniGfPgw9q3/GFzpWNEgz8TIgjSZ4hdPzseeK0kMDCaiufCjlpYoH9YU5pxwdz+JLvlu/jdkwg1i1xNVjEVC4U1zISUCHpTRkyWN1Cg77Cr87MQj5GL8YNpWjfq1eCdLXeoDNopRlmdNm//jC7e+bHzQIPmrFk2GpAg==; 5:FyVaku41aC1EyxDeikzwgX4NOaAGYnaMZ8kKEPPxdjhNvyIwSwJTTVQNAifG7QbldymX9JHsw5CTw96ud0DjUIH7wHmjy2tSXVELQC0YiV4IwpP25/Wzf0LtkUYD94lPuZAavzctnUz7rm9NIfTh6VwKYWcHYALx100+M+YcGEI=; 7:2ggvbU1a/UshFwEYXgIntoEkv2i+TojbUlXqUWndjnUXyQzSP0/EckAUycuy7DjYQ/vMDHBxELmm4A9POo75jUcsihM0zHKVR9eC+PAWk5PqFdtrKbzxHY/9aYjjAfQZuIt+6kPuV0idqhRZVur1HcIIJIsjV+uQDIjRRBz9nODXPxm077MZ8l71LKqEntQ4xn47Ixn9g0SQfFhxnUHnqZM5WADUrj6XnMZFmA24mm7EwvcGVrTPQ8uU5YuA8IDc x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM03HT162; x-ms-traffictypediagnostic: CO1NAM03HT162: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM03HT162; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT162; x-forefront-prvs: 0761DE1EDD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(43544003)(199004)(33656002)(4326008)(87572001)(73972006)(20460500001)(5660300001)(6436002)(486006)(5250100002)(110136005)(2501003)(229853002)(54906003)(2900100001)(6306002)(9686003)(55016002)(68736007)(83332001)(97736004)(11346002)(476003)(446003)(25786009)(6246003)(104016004)(2940100002)(14454004)(82202002)(106356001)(6346003)(105586002)(966005)(99286004)(46003)(8676002)(56003)(76176011)(7696005)(102836004)(8936002)(14444005)(256004)(53546011)(86362001)(74316002)(305945005)(81156014)(6506007)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM03HT162; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: Q7DspJ5AvpKM25CrhHaHlNp0qzkmSiKcdK7Vu6G9kwPjjWXVTA0UHKvkR9WRDeaR9ieTcdNseFs/uaWM57yYxyvufJTJ/PiLwmulwuyANQBnOPTrm/WidT5fiKatpqJ3Gh9AkFaMo7Mk7SK7yfgoWo8S/xYNINmU8zdEGkos7tL+ItcAPB1vC1Ti15JV+GPcxAriqO9hyd3GUvPy8AKzBh/tMmM9uy0Y+4vsUQvibZM= 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: ea2f7d55-cd90-44b8-e5e4-08d5ffe31199 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2018 23:35:05.9529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT162 Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 11 Aug 2018 23:35:15 -0000 Hello Fermando and the maillist, I just found that I forgot to address one question in my previous mail. Her= e is the addition. On Sat, Aug 11, 2018 at 6:00 PM Fernando Gont wrote= : > * Page 15 (Security Considerations): > > DoH essentialy switches from a connection-less transport (UDP) to a > connection-oriented one (TCP). This means that now the server should take= care > of all state-exhaustion attacks against TCP (e.g., take a look at: > https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). Def= ending > against such attacks maybe non-trivial. This should at least be mentioned= in > the security considerations. On contrast, by switching from UDP to TCP, the server is now able to defend= attacks more *easily*. 1) TCP requires 3-way handshake before establishing the connection. This pr= evented simple DoS attack with spoofed source address since the attacker wi= ll not receive the 2nd packet. 2) In the past, the server started to allocate resources upon receiving the= first SYN packet, making it vulnerable to SYN Flood attack. Now we use SYN= Cookies [RFC 4987], so the server does not allocate resources until the 3-= way handshake has finished, to mitigate the attack as long as the server's = Internet pipe is not full. 3) UDP is vulnerable to UDP Amplification attack, that is to send a very sm= all request, requiring kilobytes of response. Combined with spoofed source = address (1), the attacker can make request and response packets bouncing be= tween 2 servers, producing a 2^n amount of junk traffic, preventing the ser= ver from operating. Typical amplification victims include DNS and NTP, and = they are all UDP . 4) Nowadays, the majority of DDoS attack is to send TB/s or PB/s of arbitra= ry garbage to fill the server's 100Mbps Internet pipe to make your server o= ffline. Generally you need a powerful hardware firewall to wash out the gar= bage, and as many as BGP peers with other ISPs so legitimate users can reac= h your server directly in a clean pipe. For this type of attack, UDP and TC= P have no difference. 5) We already have many articles talking about TCP/IP security [RFC 4953, 4= 987, 5961, 6528, etc]. I disagree that we need to talk about everything fro= m TCP to IP to Ethernet in this DoH document. On Sun, Aug 12, 2018 at 8:59 AM Star Brilliant wrote: > > Hello Femando and the mail list, > > Thanks for your review! > > I would like to answer some of the questions based on what the contributo= rs had discussed before. > > Paul Hoffman is the core author, so if I made a mistake, please consider = his answer as the authoritative. > > > On Sat, Aug 11, 2018 at 6:00 PM Fernando Gont wro= te: > > > > * Page 5: > > > Using the GET method is friendlier to many HTTP cache > > > implementations. > > > > Could the queries really be cached for the POST case? > > Yes, they can. > > >From RFC 7231: "In general, safe methods that do not depend on a current= or authoritative response are defined as cacheable; this specification def= ines GET, HEAD, and POST as cacheable, although the overwhelming majority o= f cache implementations only support GET and HEAD." > > But GET is friendlier than POST, because of the fact most ISP's transpare= nt proxy or cloud WAF systems do not cache POST. > > > > * Page 15: > > > It is the choice of a client to either > > > perform full DNSSEC validation of answers or to trust the DoH serv= er > > > to do DNSSEC validation and inspect the AD (Authentic Data) bit in > > > the returned message to determine whether an answer was authentic = or > > > not. > > > > Relying on the DoH server for DNSsec validation does not seem like a go= od idea. > > You want DNSsec to be end-to-end. > > We discussed about this paragraph before. The problem depends on how you = deploy DoH services. > > 1) For most people's needs, the users grab a list of DoH servers from the= Internet and configure their systems to use the DoH servers. These public = servers are untrustworthy. So the users need to validate DNSSEC at their en= d. > > 2) A web-based application using DoH with a pre-configured server maintai= ned by the application author. Then the server has the same trust level as = the JavaScript code that validates the records. If anyone does not trust th= e server, they should not use the web app. In addition, by checking the rec= ords on the server, we can save some bandwidth for mobile users. > > 3) A dedicated enterprise cloud environment with hundreds of machines, se= rving trillions of requests per day. The administrator would want to offloa= d the DNSSEC check to the gateway to reduce service latency, improve cache = hit-rate, reduce intra-AS bandwidth cost, and to increase service quality. > > 4) A resource-constrained device (some Arduino or ESP8266 or other IoT-li= ke things). You will want to delegate the check to your PC as long as the P= C can be trusted. > > Conclusion: People use DoH in different ways. Sometimes it is better to "= give the user more choices, but make the default choice secure". > Therefore, we have the text "It is the choice of a client to either trust= or distrust". > > > > > * Page 15 (Security Considerations): > > > > DoH essentialy switches from a connection-less transport (UDP) to a > > connection-oriented one (TCP). This means that now the server should ta= ke care > > of all state-exhaustion attacks against TCP (e.g., take a look at: > > https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). D= efending > > against such attacks maybe non-trivial. This should at least be mention= ed in > > the security considerations. > > > > * Page 16:> > > > HTTP [RFC7230] is a stateless application-level protocol and > > > therefore DoH implementations do not provide stateful ordering > > > guarantees between different requests. > > > > Are you meaning that requests that are pipelined could be responded in > > different order? Something else? > > The DNS wire protocol is not always a single query-and-response model. So= me functions (e.g. zone transfer) require multiple messages to be sent and = received. As already stated in the text elsewhere, DoH does not support thi= s kind of functions (at least not in this version). > > > > > * Page 16: > > > A DoH server is allowed to answer queries with any valid DNS > > > response. For example, a valid DNS response might have the TC > > > (truncation) bit set in the DNS header to indicate that the server > > > was not able to retrieve a full answer for the query but is provid= ing > > > the best answer it could get. A DoH server can reply to queries w= ith > > > an HTTP error for queries that it cannot fulfill. > > > > Why should this happen? Why not encode this information in the encoded = DNS > > response (in wire format)' > > If you are asking about "an HTTP error", here is the explain: > > 1) Some errors indicates a problem happening on HTTP layer, not DNS layer= . > For example, 302 Redirection, 404 Not Found, 401 Unauthorized > > 2) Sometimes it is technically impossible to reply with an encoded DNS re= sponse. > For example, the web server crashed, throwing a default 500-504 error pag= e > > DoH is a double-layered protocol. It is intuitive that each layer may bre= ak, resulting with an error that represents that layer. (Additionally, sinc= e DoH runs on TCP/IP, a DoH server can even reply with an icmp-port-unreach= able error.) Layered error is the nature of Internet protocols. > > If you are asking about the TC bit, this happens in many situations. One = cause is broken TCP on the authoritative server, which happens quite freque= ntly with anycast servers. From nobody Sat Aug 11 16:44: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 BB2F3130E66; Sat, 11 Aug 2018 16:44:35 -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 hcFSvEMxj2QM; Sat, 11 Aug 2018 16:44:32 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A797A124BE5; Sat, 11 Aug 2018 16:44:32 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sat, 11 Aug 2018 16:44:31 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Sat, 11 Aug 2018 16:44:31 -0700 From: Paul Hoffman To: Fernando Gont CC: "draft-ietf-doh-dns-over-https.all@ietf.org" , "tsv-art@ietf.org" , DoH WG , IETF Discussion Mailing List Thread-Topic: [Ext] [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 Thread-Index: AQHUMc0/uJzctOZAvUuMiBoCYe5/vw== Date: Sat, 11 Aug 2018 23:44:30 +0000 Message-ID: <6397F525-1861-4850-9266-453D2B190BCA@icann.org> References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 11 Aug 2018 23:44:36 -0000 On Aug 11, 2018, at 3:56 PM, Patrick McManus wrote: > * Page 16: > > A DoH server is allowed to answer queries with any valid DNS > > response. For example, a valid DNS response might have the TC > > (truncation) bit set in the DNS header to indicate that the server > > was not able to retrieve a full answer for the query but is providin= g > > the best answer it could get. A DoH server can reply to queries wit= h > > an HTTP error for queries that it cannot fulfill. >=20 > Why should this happen? Why not encode this information in the encoded DN= S > response (in wire format)' There was a lot of discussion in the WG about this. The result was similar = to what Star replied: let the semantics of the inner protocol (DNS) retain = their exact meanings, and let the semantics of the outer layer (HTTP) retai= n their exact meaning. A DoH client is expected to understand DNS errors *a= nd* be a real HTTP client that can deal with normal HTTP semantics. On Aug 11, 2018, at 4:19 PM, Fernando Gont wrote: > What I had in mind when making this comment is this: There seem to be > anycast resolvers implementing DoH (e.g., CLoudflare's and others, if I > understand correctly). Giving them the responsibility for DNSsec > validation would seem to me as giving them way too much power (i.e., > what if they were compromised and/or went evil?) DoH clients are no different in this regard than normal DNS (port 53) or DN= S-over-TLS clients. Any of the three types of DNS client can do its own DNS= validation by asking for the supporting DNS records; DoH by design doesn't= change this at all. But to be clear, the ratio of end clients that do thei= r own validation is still incredibly small. >> * Page 15 (Security Considerations): >>=20 >> DoH essentialy switches from a connection-less transport (UDP) to a >> connection-oriented one (TCP). >>=20 >> I disagree a bit. It adds a third TCP based DNS based approach to the >> DNS over TCP and DNS over TLS approaches already standardized so it is >> not breaking new ground in that sense. >=20 > To put it in a different way: >=20 > * What would be the impact if an attacker were to DoS TCP-based > resolution in the traditional case? (i.e., while UDP-based resolution > still works) >=20 > * What would be the impact if an attacker were to DoS (HTTPS/)TCP-based > resolution in the DoH case? >=20 > If the impact were the same, then just say that, and no need to worry. > But my understanding is that in current deployments you normally only > fall back to TCP when the UDP response was truncated, whereas with DoH, > you rely 100% on TCP. DoH servers do not need to reside on the same hosts as DNS/UDP or DNS/TCP s= ervers. Cloudflare happens to do so, possibly due to address cuteness, but = there is nothing in the protocol that says they should. The impact on DoH s= erver on attacks is identical to the impact on attacks on normal TLS-based = web services. > I don't mean you need to elaborate on how to defend it. JUst noted that > if you completely get rid of UDP-base resolution, then the TCP one (in > this case DoH) becomes even more critical, and the impact of a DoS > against TCP-based resolution is higher. And defending a stateful > protocol like TCP against resource exhaustion attacks is non-trivial. DoH is never expected to "get rid of UDP-based resolution". The use cases f= or DoH are very much a subset of the use cases for general DNS resolution, = and that will be UDP-based for the foreseeable future. > Maybe I'm a bit confused. If, on the same connection, I send a request > to resolve "A" and subsequently a request to resolve "B", the result of > the later might come before than the result of the former? (I'm trying > to understand what the "ordering guarantees" that are not provided with > DoH). Yep! This is why the DoH WG has been such a good learning experience for DN= S folks about the modern HTTP world, and for HTTP folks for the modern DNS = world. We're not all holding hands and singing kumbaya yet, but at least we= understand better the weirdnesses that the others take for granted. --Paul Hoffman= From nobody Sun Aug 12 16:43: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 24E33130E46; Sun, 12 Aug 2018 16:42:54 -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 WOtGXl8iF0vh; Sun, 12 Aug 2018 16:42:52 -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 5C631130E2C; Sun, 12 Aug 2018 16:42:52 -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 8A2D23AB03E; Sun, 12 Aug 2018 23:42:51 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 33F3F160051; Sun, 12 Aug 2018 23:42:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 1311F16006E; Sun, 12 Aug 2018 23:42: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 gYnEwJtCP67w; Sun, 12 Aug 2018 23:42: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 A9699160051; Sun, 12 Aug 2018 23:42: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: Date: Mon, 13 Aug 2018 09:42:42 +1000 Cc: Fernando Gont , "tsv-art@ietf.org" , "draft-ietf-doh-dns-over-https.all@ietf.org" , "doh@ietf.org" , "ietf@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4436035B-89D4-437D-AB24-17E352379F88@isc.org> References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> To: Star Brilliant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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: Sun, 12 Aug 2018 23:42:54 -0000 > On 12 Aug 2018, at 9:35 am, Star Brilliant wrote: >=20 > Hello Fermando and the maillist, >=20 > I just found that I forgot to address one question in my previous = mail. Here is the addition. >=20 > On Sat, Aug 11, 2018 at 6:00 PM Fernando Gont = wrote: >> * Page 15 (Security Considerations): >>=20 >> DoH essentialy switches from a connection-less transport (UDP) to a >> connection-oriented one (TCP). This means that now the server should = take care >> of all state-exhaustion attacks against TCP (e.g., take a look at: >> https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf). = Defending >> against such attacks maybe non-trivial. This should at least be = mentioned in >> the security considerations. >=20 >=20 > On contrast, by switching from UDP to TCP, the server is now able to = defend attacks more *easily*. >=20 > 1) TCP requires 3-way handshake before establishing the connection. = This prevented simple DoS attack with spoofed source address since the = attacker will not receive the 2nd packet. Which also exists for DNS over UDP using DNS COOKIE. > 2) In the past, the server started to allocate resources upon = receiving the first SYN packet, making it vulnerable to SYN Flood = attack. Now we use SYN Cookies [RFC 4987], so the server does not = allocate resources until the 3-way handshake has finished, to mitigate = the attack as long as the server's Internet pipe is not full. DNS COOKIE doesn=E2=80=99t have any server state. > 3) UDP is vulnerable to UDP Amplification attack, that is to send a = very small request, requiring kilobytes of response. Combined with = spoofed source address (1), the attacker can make request and response = packets bouncing between 2 servers, producing a 2^n amount of junk = traffic, preventing the server from operating. Typical amplification = victims include DNS and NTP, and they are all UDP . Not with DNS COOKIE. > 4) Nowadays, the majority of DDoS attack is to send TB/s or PB/s of = arbitrary garbage to fill the server's 100Mbps Internet pipe to make = your server offline. Generally you need a powerful hardware firewall to = wash out the garbage, and as many as BGP peers with other ISPs so = legitimate users can reach your server directly in a clean pipe. For = this type of attack, UDP and TCP have no difference. >=20 > 5) We already have many articles talking about TCP/IP security [RFC = 4953, 4987, 5961, 6528, etc]. I disagree that we need to talk about = everything from TCP to IP to Ethernet in this DoH document. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 13 05:54: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 376A7130EFE for ; Mon, 13 Aug 2018 05:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 N_SXhpNwLTkO for ; Mon, 13 Aug 2018 05:54:39 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 78AC9120049 for ; Mon, 13 Aug 2018 05:54:38 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w7DCsYiF018850 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 13 Aug 2018 14:54:34 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w7DCsX1V018845 for ; Mon, 13 Aug 2018 14:54:34 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Mon, 13 Aug 2018 14:54:33 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: doh@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [Doh] Public endpoints to draft-13 please? 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, 13 Aug 2018 12:54:42 -0000 Hi, I'm keeping a little list of public DoH servers [1]. Today I tried them all with my draft-13 compliant client and noticed that three out of seven servers in the list don't like "application/dns-message" as Content-Type, even though it's been documented since about the draft-07 time frame or so. This isn't ideal for interop. This email is just to highlight the situation and for me to beg that if you run such a server you update it soon so that we all play by the same book! Thanks, [1] = https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers -- / daniel.haxx.se From nobody Mon Aug 13 07:59:06 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 A5100130E0A; Mon, 13 Aug 2018 07:58:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153417233866.25070.3751592720564238859.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 07:58:58 -0700 Archived-At: Subject: [Doh] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-doh-dns-over-https-13=3A_=28with_COMMENT=29?= 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: Mon, 13 Aug 2018 14:58:59 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-doh-dns-over-https-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One question: In case DoH doesn't work for some reason, is this supposed to fallback to DNS over TLS? I guess if the selected host name would allow detection of DNS and SNI is used, it wouldn't be too hard to block DoH requests....? Is that a concern? Also one smallish comment: As already brought up in the TSV-ART review (Thanks Ferando!) I would recommend to further clarify this sentence in section 5.1: "Using the GET method is friendlier to many HTTP cache implementations." What does "friendlier" mean...? Or at least maybe provide a forward reference to sec 6.1. From nobody Mon Aug 13 10:06: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 8004E130FA3; Mon, 13 Aug 2018 10:06:44 -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 oHU4Mc9Dk86g; Mon, 13 Aug 2018 10:06:43 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 22C56130FBA; Mon, 13 Aug 2018 10:06:40 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by linode64.ducksong.com (Postfix) with ESMTPSA id 51DB23A024; Mon, 13 Aug 2018 13:06:39 -0400 (EDT) Received: by mail-oi0-f47.google.com with SMTP id q11-v6so28486050oic.12; Mon, 13 Aug 2018 10:06:39 -0700 (PDT) X-Gm-Message-State: AOUpUlF0UT8EnPHUUhj5X0Ui6RjORxq70JbqwcxVsbEFU8lFB2CJXdj4 M8WmcfaL0jvlf55NbAcsNuy+ZzqY52HevNs5lEE= X-Google-Smtp-Source: AA+uWPxJ4669kGecsfomuBYZ48CSPkiEWlcpVpmIOLkcRRGQw4KQablZf1u+UnXx1yBoqu+n2lH++fhgf8EYn7C6Jng= X-Received: by 2002:aca:5f0a:: with SMTP id t10-v6mr17718429oib.337.1534179999021; Mon, 13 Aug 2018 10:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 10:06:38 -0700 (PDT) In-Reply-To: <153417233866.25070.3751592720564238859.idtracker@ietfa.amsl.com> References: <153417233866.25070.3751592720564238859.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Mon, 13 Aug 2018 13:06:38 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, DoH WG Content-Type: multipart/alternative; boundary="000000000000dd027b0573541d60" Archived-At: Subject: Re: [Doh] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-doh-dns-over-https-13=3A_=28with_COMMENT=29?= 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, 13 Aug 2018 17:06:45 -0000 --000000000000dd027b0573541d60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Mirja. On Mon, Aug 13, 2018 at 10:58 AM, Mirja K=C3=BChlewind wrote: > > One question: > In case DoH doesn't work for some reason, is this supposed to fallback to > DNS > over TLS? I guess if the selected host name would allow detection of DNS > and > SNI is used, it wouldn't be too hard to block DoH requests....? Is that a > concern? > > DoH doesn't proscribe any particular path to choosing servers and protocols (even for choosing the DoH server) - each protocol has different properties and particular servers might have properties only the configurer can understand (e.g. trust in the service, not just authentication) in the context of the endpoints it knows about. So whether fallback is suitable is something DoH can only really comment on by describing its properties (encrypted and authenticated transport). There is no expectation that the same server run DNS service using more than one protocol (i.e. there is no expectation that you use the same host and ratchet down from doh, to dot, to plaintext tcp, to dns.) > Also one smallish comment: > As already brought up in the TSV-ART review (Thanks Ferando!) I would > recommend > to further clarify this sentence in section 5.1: "Using the GET method is > friendlier to many HTTP cache implementations." What does "friendlier" > mean...? > Or at least maybe provide a forward reference to sec 6.1 roughly it means more likely to work for a variety of reasons.. I'm not sure delving into those reasons really is helpful to the DoH reader - the important property is that HTTP caching works-well with GET and not-so-well with POST. Is friendly a bad word for that? its commonly used in the http and application space around caching afaict. -P --000000000000dd027b0573541d60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mirja.

On Mon, Aug 13, 2018 at 10:58 AM, Mirja K=C3=BChlewin= d <ietf@kuehlewind.net> wrote:

One question:
In case DoH doesn't work for some reason, is this supposed to fallback = to DNS
over TLS? I guess if the selected host name would allow detection of DNS an= d
SNI is used, it wouldn't be too hard to block DoH requests....? Is that= a
concern?


DoH doesn't proscribe any particul= ar path to choosing servers and protocols (even for choosing the DoH server= ) - each protocol has different properties and particular servers might hav= e properties only the configurer can understand (e.g. trust in the service,= not just authentication) in the context of the endpoints it knows about. S= o whether fallback is suitable is something DoH can only really comment on = by describing its properties (encrypted and authenticated transport).
=

There is no expectation that the same server run DNS se= rvice using more than one protocol (i.e. there is no expectation that you u= se the same host and ratchet down from doh, to dot, to plaintext tcp, to dn= s.)

=C2=A0
Also one smallish comment:
As already brought up in the TSV-ART review (Thanks Ferando!) I would recom= mend
to further clarify this sentence in section 5.1: "Using the GET method= is
friendlier to many HTTP cache implementations." What does "friend= lier" mean...?
Or at least maybe provide a forward reference to sec 6.1
<= br>
roughly it means more likely to work for a variety of reasons= .. I'm not sure delving into those reasons really is helpful to the DoH= reader - the important property is that HTTP caching works-well with GET a= nd not-so-well with POST. Is friendly a bad word for that? its commonly use= d in the http and application space around caching afaict.

-P



=C2=A0
--000000000000dd027b0573541d60-- From nobody Mon Aug 13 12:32:11 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 39741130FB5; Mon, 13 Aug 2018 12:32:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: bemasc@google.com, draft-ietf-doh-dns-over-https@ietf.org, doh@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2018 12:32:09 -0700 Archived-At: Subject: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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: Mon, 13 Aug 2018 19:32:09 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-doh-dns-over-https-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4890 COMMENTS S 1. > > 1. Introduction > > This document defines a specific protocol for sending DNS [RFC1035] > queries and getting DNS responses over HTTP [RFC7540] using https > URIs (and therefore TLS [RFC5246] security for integrity and You will need a cite for HTTPS. S 1. > > Two primary uses cases were considered during this protocol's > development. They included preventing on-path devices from > interfering with DNS operations and allowing web applications to > access DNS information via existing browser APIs in a safe way > consistent with Cross Origin Resource Sharing (CORS) [CORS]. No "considered"..."include" is odd. I would probably just make this a bulleted list, but alternately, "They were". S 4. > > o Supporting insecure HTTP > > 4. Selection of DoH Server > > Configuration, discovery, and updating of the URI Template [RFC6570] At this point in the document, it is not clear why I would need a URI template, because you don't explain that till S 5. Perhaps in some overview above. S 4. > offers an unsolicited response that appears to be a valid answer to a > DNS query. This specification does not extend DNS resolution > privileges to URIs that are not recognized by the DoH client as > configured URIs. Such scenarios may create additional operational, > tracking, and security hazards that require limitations for safe > usage. A future specification may support this use case. I am having some trouble understanding what you are prohibiting here. Also, "configured" is an odd term if you are talking about web apps S 5.1. > DoH servers MUST implement both the POST and GET methods. > > When using the POST method the DNS query is included as the message > body of the HTTP request and the Content-Type request header field > indicates the media type of the message. POST-ed requests are > smaller than their GET equivalents. Because? I assume b/c no encoding. With that said, it is not obvious that this is true because (as shown below) you have to put content- length and content-type in the POST version, so if you had a smallish request, you might gt more expansion that way, S 5.1. > The DoH client SHOULD include an HTTP "Accept" request header field > to indicate what type of content can be understood in response. > Irrespective of the value of the Accept request header field, the > client MUST be prepared to process "application/dns-message" (as > described in Section 7) responses but MAY also process any other type > it receives. Why is this good? What would I do with like image/jpeg. I tend to think of draft-thomson-postel-was-wrong here. S 5.2. > from a DNS response. For example, one response type might include > information from the DNS header bytes while another might omit it. > The amount and type of information that a media type gives is solely > up to the format, and not defined in this protocol. > > Each DNS request-response pair is matched to one HTTP exchange. The I think you mean "mapped" S 5.2.1. > DNS response codes indicate either success or failure for the DNS > query. A successful HTTP response with a 2xx status code ([RFC7231] > Section 6.3) can be used for any valid DNS response, regardless of > the DNS response code. For example, a successful 2xx HTTP status > code is used even with a DNS message whose DNS response code > indicates failure, such as SERVFAIL or NXDOMAIN. You say "can" but the text below implies MUST. S 6.1. > The stale-while-revalidate and stale-if-error Cache-Control > directives ([RFC5861]) could be well-suited to a DoH implementation > when allowed by server policy. Those mechanisms allow a client, at > the server's discretion, to reuse a cache entry that is no longer > fresh. In such a case, the client reuses all of a cached entry, or > none of it. Is this a normative requirement or a statement of fact? S 6.3. > establish that the HTTP request URI can be used for the DoH query. > For HTTP requests initiated by the DoH client, this is implicit in > the selection of URI. For HTTP server push ([RFC7540] Section 8.2) > extra care must be taken to ensure that the pushed URI is one that > the client would have directed the same query to if the client had > initiated the request. As well as the other push security check S 9.1. > DoH encrypts DNS traffic and requires authentication of the server. > This mitigates both passive surveillance [RFC7258] and active attacks > that attempt to divert DNS traffic to rogue servers ([RFC7626] > Section 2.5.1). DNS over TLS [RFC7858] provides similar protections, > while direct UDP and TCP based transports are vulnerable to this > class of attack. A citation to draft-ietf-dprive-padding-policy seems in order here, as well as later. S 10. > > In the absence of DNSSEC information, a DoH server can give a client > invalid data in response to a DNS query. Section 4 disallows the use > of DoH DNS responses that do not originate from configured servers. > This prohibition does not guarantee protection against invalid data, > but it does reduce the risk. Do you want to say something about TSIG (and it maybe not being needed here) From nobody Mon Aug 13 13:16: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 7AFF7130FF4; Mon, 13 Aug 2018 13:16:17 -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 qAe5r-M-oBJ4; Mon, 13 Aug 2018 13:16:15 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CCC3131000; Mon, 13 Aug 2018 13:16:15 -0700 (PDT) Received: from [169.254.102.180] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w7DKFp5T091850 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Aug 2018 13:15:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.102.180] From: "Paul Hoffman" To: "Eric Rescorla" Cc: "The IESG" , draft-ietf-doh-dns-over-https@ietf.org, doh@ietf.org, doh-chairs@ietf.org Date: Mon, 13 Aug 2018 13:16:11 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org> In-Reply-To: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> References: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 13 Aug 2018 20:16:17 -0000 Thanks for the thorough review. We have a new PR for the changes below. --Paul Hoffman On 13 Aug 2018, at 12:32, Eric Rescorla wrote: > COMMENTS > S 1. >> >> 1. Introduction >> >> This document defines a specific protocol for sending DNS >> [RFC1035] >> queries and getting DNS responses over HTTP [RFC7540] using >> https >> URIs (and therefore TLS [RFC5246] security for integrity and > > You will need a cite for HTTPS. We'll copy the {{RFC2818}} reference here as well. > S 1. >> >> Two primary uses cases were considered during this protocol's >> development. They included preventing on-path devices from >> interfering with DNS operations and allowing web applications to >> access DNS information via existing browser APIs in a safe way >> consistent with Cross Origin Resource Sharing (CORS) [CORS]. No > > "considered"..."include" is odd. I would probably just make this a > bulleted list, but alternately, "They were". "They were" is good here. > S 4. >> >> o Supporting insecure HTTP >> >> 4. Selection of DoH Server >> >> Configuration, discovery, and updating of the URI Template >> [RFC6570] > > At this point in the document, it is not clear why I would need a URI > template, because you don't explain that till S 5. Perhaps in some > overview above. Saying "URI Templates were used because that's the new way to do things in the web world" would be honest, but maybe not that helpful in the document. Others might have a better way to say this. > S 4. >> offers an unsolicited response that appears to be a valid answer >> to a >> DNS query. This specification does not extend DNS resolution >> privileges to URIs that are not recognized by the DoH client as >> configured URIs. Such scenarios may create additional >> operational, >> tracking, and security hazards that require limitations for safe >> usage. A future specification may support this use case. > > I am having some trouble understanding what you are prohibiting here. I send an query to https://www.ekrexample.com/ over HTTP/2. During that HTTP/2 session, I get a DoH request/response pair from that origin. https://www.ekrexample.com/ is not in the list of configured URIs allowed for DoH for this client. I MUST NOT do anything with that DoH request/response. > Also, "configured" is an odd term if you are talking about web apps Even web apps appear to have configuration in them, although usually as JavaScript list and object declarations. > S 5.1. >> DoH servers MUST implement both the POST and GET methods. >> >> When using the POST method the DNS query is included as the >> message >> body of the HTTP request and the Content-Type request header >> field >> indicates the media type of the message. POST-ed requests are >> smaller than their GET equivalents. > > Because? I assume b/c no encoding. With that said, it is not obvious > that this is true because (as shown below) you have to put content- > length and content-type in the POST version, so if you had a smallish > request, you might gt more expansion that way, All DoH responses are at least about 17 bytes long (the 12-byte DNS message header plus the shortest possible domain name plus the type and class), much more typically at least 40 bytes with typical names and even a short answer. Base64 of that will be longer than the content length and content type. Normal answers will definitely be longer. > S 5.1. >> The DoH client SHOULD include an HTTP "Accept" request header >> field >> to indicate what type of content can be understood in response. >> Irrespective of the value of the Accept request header field, >> the >> client MUST be prepared to process "application/dns-message" (as >> described in Section 7) responses but MAY also process any other >> type >> it receives. > > Why is this good? To allow other future types of messages that encode DNS information. > What would I do with like image/jpeg. Nothing. That's why it is a MAY. > I tend to think of draft-thomson-postel-was-wrong here. This should be on a different thread, I believe. > S 5.2. >> from a DNS response. For example, one response type might >> include >> information from the DNS header bytes while another might omit >> it. >> The amount and type of information that a media type gives is >> solely >> up to the format, and not defined in this protocol. >> >> Each DNS request-response pair is matched to one HTTP exchange. >> The > > I think you mean "mapped" Agree. > S 5.2.1. >> DNS response codes indicate either success or failure for the >> DNS >> query. A successful HTTP response with a 2xx status code >> ([RFC7231] >> Section 6.3) can be used for any valid DNS response, regardless >> of >> the DNS response code. For example, a successful 2xx HTTP >> status >> code is used even with a DNS message whose DNS response code >> indicates failure, such as SERVFAIL or NXDOMAIN. > > You say "can" but the text below implies MUST. Agree. s/can be/is/ > S 6.1. >> The stale-while-revalidate and stale-if-error Cache-Control >> directives ([RFC5861]) could be well-suited to a DoH >> implementation >> when allowed by server policy. Those mechanisms allow a client, >> at >> the server's discretion, to reuse a cache entry that is no >> longer >> fresh. In such a case, the client reuses all of a cached entry, >> or >> none of it. > > Is this a normative requirement or a statement of fact? Not sure. Input from the HTTP crowd is welcome here. > S 6.3. >> establish that the HTTP request URI can be used for the DoH >> query. >> For HTTP requests initiated by the DoH client, this is implicit >> in >> the selection of URI. For HTTP server push ([RFC7540] Section >> 8.2) >> extra care must be taken to ensure that the pushed URI is one >> that >> the client would have directed the same query to if the client >> had >> initiated the request. > > As well as the other push security check Yep, added. > > > S 9.1. >> DoH encrypts DNS traffic and requires authentication of the >> server. >> This mitigates both passive surveillance [RFC7258] and active >> attacks >> that attempt to divert DNS traffic to rogue servers ([RFC7626] >> Section 2.5.1). DNS over TLS [RFC7858] provides similar >> protections, >> while direct UDP and TCP based transports are vulnerable to this >> class of attack. > > A citation to draft-ietf-dprive-padding-policy seems in order here, as > well as later. Agree. > > > S 10. >> >> In the absence of DNSSEC information, a DoH server can give a >> client >> invalid data in response to a DNS query. Section 4 disallows >> the use >> of DoH DNS responses that do not originate from configured >> servers. >> This prohibition does not guarantee protection against invalid >> data, >> but it does reduce the risk. > > Do you want to say something about TSIG (and it maybe not being needed > here) Not really. The WG discussed TSIG and decided it was not needed here. From nobody Mon Aug 13 13:28: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 B0A4013104E for ; Mon, 13 Aug 2018 13:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 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, 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=rtfm-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 KqAEw4ltmpM3 for ; Mon, 13 Aug 2018 13:28:11 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 DB01413104F for ; Mon, 13 Aug 2018 13:28:08 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id g6-v6so12164078lfb.11 for ; Mon, 13 Aug 2018 13:28:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dbyVew+Sde8ygFI4DFN8e5IH0pHB3uE3jLfpPn/EqTE=; b=cRry2PcgE2kJ0WBPNLU09AbgenUVyevPjmqpe2XXzqlaNnTs/8qCV9n9zMwhC1ISf+ IRe8AxENn20fHfx+n/4P0imjOOZDaSPrUC/n1fbkv0mjSAHdX8/EZywhZzpNRM7jmopg XfmF+zwxE2EQJ8vQS6AL/ImxhAr7biEo5bxFzLhkhmWjce3NOLOH3fsLiElQ5HHQG8Hg mLBCNwr2LrVCwICLnLnv/FsUvRbxMBoHdY/TFKUn74r2uzNLBzFFzwfxbqS4SZGdRPlq uGs5rAM19BhPKz+i/MxZvN/L/K6ICUbMfjuqLQaNzIckzIzCNvwsyjO/Rb5ZzcW+XOjM 98tA== 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=dbyVew+Sde8ygFI4DFN8e5IH0pHB3uE3jLfpPn/EqTE=; b=JjrIstv9FQYlneHdOnBI6jdofZME2O+SXaGHSk30qhxyR4lY0j2jQt7XUPZQzqUh5k E3yHw6hJGHZAeH755NdketdKoh/qz33Gb1izhLSum9cDz3PrxX2R1u8BiiaE50BeWw36 JCRWtrNToO8D0fes4rCk3RaM1PXW6+LD46C1DNfszK2DknN4pQSRi+VDD8ZkTi4p1zqE T5/oBRII7DdY6vi1dB4A6Ix7PDnItBB894DSxGWNRsMgkyN/ZbaqiD9zAMKvnptKcb2O 6h2YcRe8amaraX0dRqvS+ER1F1J55OYrymIHNhvgdYYmlT+QuORg65/Bi2CTDJF2DY/e 5Adw== X-Gm-Message-State: AOUpUlEv9PmD91Son/DTWuDssHxCLH0jBKpy5txmRbJHkPk+4tnAEtj7 VS7nhtMuwc1Cx8dUKcnr83B65yjjMOMXiH8I7WBOjA== X-Google-Smtp-Source: AA+uWPxW3uT1qOeij4oc5XOZzISFoqY+HaPO9NAgU+ZcdrBjHCXwSn+XX1bCsyX0BhMY8CAIUAgDxey9fdB+RoZCwKY= X-Received: by 2002:a19:c3c7:: with SMTP id t190-v6mr9364717lff.108.1534192086858; Mon, 13 Aug 2018 13:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 13:27:26 -0700 (PDT) In-Reply-To: <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org> References: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org> From: Eric Rescorla Date: Mon, 13 Aug 2018 13:27:26 -0700 Message-ID: To: Paul Hoffman Cc: The IESG , draft-ietf-doh-dns-over-https@ietf.org, DoH WG , doh-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ad282057356ee39" Archived-At: Subject: Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 13 Aug 2018 20:28:14 -0000 --0000000000005ad282057356ee39 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 13, 2018 at 1:16 PM, Paul Hoffman wrote: > Thanks for the thorough review. We have a new PR for the changes below. > > --Paul Hoffman > > On 13 Aug 2018, at 12:32, Eric Rescorla wrote: > > COMMENTS >> S 1. >> >>> >>> 1. Introduction >>> >>> This document defines a specific protocol for sending DNS [RFC1035] >>> queries and getting DNS responses over HTTP [RFC7540] using https >>> URIs (and therefore TLS [RFC5246] security for integrity and >>> >> >> You will need a cite for HTTPS. >> > > We'll copy the {{RFC2818}} reference here as well. > > S 1. >> >>> >>> Two primary uses cases were considered during this protocol's >>> development. They included preventing on-path devices from >>> interfering with DNS operations and allowing web applications to >>> access DNS information via existing browser APIs in a safe way >>> consistent with Cross Origin Resource Sharing (CORS) [CORS]. No >>> >> >> "considered"..."include" is odd. I would probably just make this a >> bulleted list, but alternately, "They were". >> > > "They were" is good here. > > S 4. >> >>> >>> o Supporting insecure HTTP >>> >>> 4. Selection of DoH Server >>> >>> Configuration, discovery, and updating of the URI Template [RFC6570] >>> >> >> At this point in the document, it is not clear why I would need a URI >> template, because you don't explain that till S 5. Perhaps in some >> overview above. >> > > Saying "URI Templates were used because that's the new way to do things in > the web world" would be honest, but maybe not that helpful in the document. > Others might have a better way to say this. > Sorry, this isn't an argument about templates but rather "why are templates relevant here at all". I think you want to say something like "The DOH client is configured with a URI template [RFC6570] which describes how to construct the URL to use for resolution." > S 4. >> >>> offers an unsolicited response that appears to be a valid answer to >>> a >>> DNS query. This specification does not extend DNS resolution >>> privileges to URIs that are not recognized by the DoH client as >>> configured URIs. Such scenarios may create additional operational, >>> tracking, and security hazards that require limitations for safe >>> usage. A future specification may support this use case. >>> >> >> I am having some trouble understanding what you are prohibiting here. >> > > I send an query to https://www.ekrexample.com/ over HTTP/2. During that > HTTP/2 session, I get a DoH request/response pair from that origin. > https://www.ekrexample.com/ is not in the list of configured URIs allowed > for DoH for this client. I MUST NOT do anything with that DoH > request/response. > How would you get a DoH request/response pair from that origin? Via push? Also, "configured" is an odd term if you are talking about web apps >> > > Even web apps appear to have configuration in them, although usually as > JavaScript list and object declarations. > I don't think this is typically how Web programmers would think of it. > S 5.1. >> >>> DoH servers MUST implement both the POST and GET methods. >>> >>> When using the POST method the DNS query is included as the message >>> body of the HTTP request and the Content-Type request header field >>> indicates the media type of the message. POST-ed requests are >>> smaller than their GET equivalents. >>> >> >> Because? I assume b/c no encoding. With that said, it is not obvious >> that this is true because (as shown below) you have to put content- >> length and content-type in the POST version, so if you had a smallish >> request, you might gt more expansion that way, >> > > All DoH responses are at least about 17 bytes long (the 12-byte DNS > message header plus the shortest possible domain name plus the type and > class), much more typically at least 40 bytes with typical names and even a > short answer. Base64 of that will be longer than the content length and > content type. Normal answers will definitely be longer. > Well, it's not b64 of that that matters but rather 1/3 of the base64 of that, because it's only the expansion that matters. Back of the envelope: 40 * 1/3 ~= 13, and "application/dns-message" is 23 characters. > S 5.1. >> >>> The DoH client SHOULD include an HTTP "Accept" request header field >>> to indicate what type of content can be understood in response. >>> Irrespective of the value of the Accept request header field, the >>> client MUST be prepared to process "application/dns-message" (as >>> described in Section 7) responses but MAY also process any other >>> type >>> it receives. >>> >> >> Why is this good? >> > > To allow other future types of messages that encode DNS information. > When those types of messages are defined, they can update this draft. > What would I do with like image/jpeg. >> > > Nothing. That's why it is a MAY. > This just seems like a confusing, non-interoperable, place holder. > I tend to think of draft-thomson-postel-was-wrong here. >> > > This should be on a different thread, I believe. > I don't think so. We're talking about the wisdom of this design choice. >>> In the absence of DNSSEC information, a DoH server can give a client >>> invalid data in response to a DNS query. Section 4 disallows the >>> use >>> of DoH DNS responses that do not originate from configured servers. >>> This prohibition does not guarantee protection against invalid data, >>> but it does reduce the risk. >>> >> >> Do you want to say something about TSIG (and it maybe not being needed >> here) >> > > Not really. The WG discussed TSIG and decided it was not needed here. > Right, and what I'm saying is that this document should say that it displaces TSIG. -Ekr --0000000000005ad282057356ee39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 13, 2018 at 1:16 PM, Paul Hoffman <paul.hoffman@vpnc.o= rg> wrote:
Thanks for the thorough review. We have a new PR for the changes below.<= br>
--Paul Hoffman

On 13 Aug 2018, at 12:32, Eric Rescorla wrote:

COMMENTS
S 1.

=C2=A0 1.=C2=A0 Introduction

=C2=A0 =C2=A0 =C2=A0This document defines a specific protocol for sending D= NS [RFC1035]
=C2=A0 =C2=A0 =C2=A0queries and getting DNS responses over HTTP [RFC7540] u= sing https
=C2=A0 =C2=A0 =C2=A0URIs (and therefore TLS [RFC5246] security for integrit= y and

You will need a cite for HTTPS.

 We'll copy the {{RFC2818}} reference here as well.

S 1.

=C2=A0 =C2=A0 =C2=A0Two primary uses cases were considered during this prot= ocol's
=C2=A0 =C2=A0 =C2=A0development.=C2=A0 They included preventing on-path dev= ices from
=C2=A0 =C2=A0 =C2=A0interfering with DNS operations and allowing web applic= ations to
=C2=A0 =C2=A0 =C2=A0access DNS information via existing browser APIs in a s= afe way
=C2=A0 =C2=A0 =C2=A0consistent with Cross Origin Resource Sharing (CORS) [C= ORS].=C2=A0 No

"considered"..."include" is odd. I would probably just = make this a
bulleted list, but alternately, "They were".

 "They were" is good here.

S 4.

=C2=A0 =C2=A0 =C2=A0o=C2=A0 Supporting insecure HTTP

=C2=A0 4.=C2=A0 Selection of DoH Server

=C2=A0 =C2=A0 =C2=A0Configuration, discovery, and updating of the URI Templ= ate [RFC6570]

At this point in the document, it is not clear why I would need a URI
template, because you don't explain that till S 5. Perhaps in some
overview above.

 Saying "URI Templates were used because that's the new way to do t= hings in the web world" would be honest, but maybe not that helpful in= the document. Others might have a better way to say this.

Sorr= y, this isn't an argument about templates but rather "why are temp= lates relevant here at all".

I think you= want to say something like "The DOH client is configured with a URI t= emplate [RFC6570] which describes how to construct the URL to use for resol= ution."


S 4.
=C2=A0 =C2=A0 =C2=A0offers an unsolicited response that appears to be a val= id answer to a
=C2=A0 =C2=A0 =C2=A0DNS query.=C2=A0 This specification does not extend DNS= resolution
=C2=A0 =C2=A0 =C2=A0privileges to URIs that are not recognized by the DoH c= lient as
=C2=A0 =C2=A0 =C2=A0configured URIs.=C2=A0 Such scenarios may create additi= onal operational,
=C2=A0 =C2=A0 =C2=A0tracking, and security hazards that require limitations= for safe
=C2=A0 =C2=A0 =C2=A0usage.=C2=A0 A future specification may support this us= e case.

I am having some trouble understanding what you are prohibiting here.

 I send an query to https://www.ekrexample.com/ over HTTP/2. During th= at HTTP/2 session, I get a DoH request/response pair from that origin. ht= tps://www.ekrexample.com/ is not in the list of configured URIs allowed= for DoH for this client. I MUST NOT do anything with that DoH request/resp= onse.

How would you get a DoH request/response pair from that o= rigin? Via push?


Also, "configured" is an odd term if you are talking about web ap= ps

 Even web apps appear to have configuration in them, although usually as Jav= aScript list and object declarations.

I don't think this is= typically how Web programmers would think of it.

=

S 5.1.
=C2=A0 =C2=A0 =C2=A0DoH servers MUST implement both the POST and GET method= s.

=C2=A0 =C2=A0 =C2=A0When using the POST method the DNS query is included as= the message
=C2=A0 =C2=A0 =C2=A0body of the HTTP request and the Content-Type request h= eader field
=C2=A0 =C2=A0 =C2=A0indicates the media type of the message.=C2=A0 POST-ed = requests are
=C2=A0 =C2=A0 =C2=A0smaller than their GET equivalents.

Because? I assume b/c no encoding. With that said, it is not obvious
that this is true because (as shown below) you have to put content-
length and content-type in the POST version, so if you had a smallish
request, you might gt more expansion that way,

 All DoH responses are at least about 17 bytes long (the 12-byte DNS message= header plus the shortest possible domain name plus the type and class), mu= ch more typically at least 40 bytes with typical names and even a short ans= wer. Base64 of that will be longer than the content length and content type= . Normal answers will definitely be longer.

Well, it's not = b64 of that that matters but rather 1/3 of the base64 of that, because it&#= 39;s only the expansion that matters.

Back of the = envelope: 40 * 1/3 ~=3D 13, and "application/dns-message" is 23 c= haracters.



S 5.1.
=C2=A0 =C2=A0 =C2=A0The DoH client SHOULD include an HTTP "Accept"= ; request header field
=C2=A0 =C2=A0 =C2=A0to indicate what type of content can be understood in r= esponse.
=C2=A0 =C2=A0 =C2=A0Irrespective of the value of the Accept request header = field, the
=C2=A0 =C2=A0 =C2=A0client MUST be prepared to process "application/dn= s-message" (as
=C2=A0 =C2=A0 =C2=A0described in Section 7) responses but MAY also process = any other type
=C2=A0 =C2=A0 =C2=A0it receives.

Why is this good?

 To allow other future types of messages that encode DNS information.

When those types of messages are defined, they can update this draft.=


What would I do with like image/jpeg.

Nothing. That's why it is a MAY.

This just seems like a con= fusing, non-interoperable, place holder.


I tend to think of draft-thomson-postel-was-wrong here.

 This should be on a different thread, I believe.

I don't th= ink so. We're talking about the wisdom of this design choice.



=C2=A0 =C2=A0 =C2=A0In the absence of DNSSEC information, a DoH server can = give a client
=C2=A0 =C2=A0 =C2=A0invalid data in response to a DNS query.=C2=A0 Section = 4 disallows the use
=C2=A0 =C2=A0 =C2=A0of DoH DNS responses that do not originate from configu= red servers.
=C2=A0 =C2=A0 =C2=A0This prohibition does not guarantee protection against = invalid data,
=C2=A0 =C2=A0 =C2=A0but it does reduce the risk.

Do you want to say something about TSIG (and it maybe not being needed
here)

Not really. The WG discussed TSIG and decided it was not needed here.

Right, and what I'm saying is that this = document should say that it displaces TSIG.

-Ekr


--0000000000005ad282057356ee39-- From nobody Mon Aug 13 13:50:49 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2325C130DC6; Mon, 13 Aug 2018 13:50:48 -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 l1BA053vHVuE; Mon, 13 Aug 2018 13:50:45 -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 8AF2F131092; Mon, 13 Aug 2018 13:50:45 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) by linode64.ducksong.com (Postfix) with ESMTPSA id DB2793A019; Mon, 13 Aug 2018 16:50:44 -0400 (EDT) Received: by mail-oi0-x236.google.com with SMTP id w126-v6so29698123oie.7; Mon, 13 Aug 2018 13:50:44 -0700 (PDT) X-Gm-Message-State: AOUpUlGZpuiHiXN0EVsVme1V6RTlgO6L8QH0H1mUe2S+Bmmyk3hQtg/F 9jTyKRQ6o57PyMT+oqbmq8pLc+fs4jIxNbnLMm8= X-Google-Smtp-Source: AA+uWPx/NPmSJhzMT7BCcn2jSf+iuDDUPnyuxt6EksY91BKdqNCGb+GuSTOFmf0X0V8DpBK+1RSNg+yuq/b8d1+v53I= X-Received: by 2002:aca:2e86:: with SMTP id u128-v6mr18345927oiu.132.1534193443596; Mon, 13 Aug 2018 13:50:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 13:50:42 -0700 (PDT) In-Reply-To: <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org> References: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org> From: Patrick McManus Date: Mon, 13 Aug 2018 16:50:42 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Hoffman Cc: Eric Rescorla , The IESG , draft-ietf-doh-dns-over-https@ietf.org, DoH WG , doh-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000038f23f0573573f52" Archived-At: Subject: Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 13 Aug 2018 20:50:48 -0000 --00000000000038f23f0573573f52 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 13, 2018 at 4:16 PM, Paul Hoffman wrote: > > > S 5.1. >> >>> DoH servers MUST implement both the POST and GET methods. >>> >>> When using the POST method the DNS query is included as the message >>> body of the HTTP request and the Content-Type request header field >>> indicates the media type of the message. POST-ed requests are >>> smaller than their GET equivalents. >>> >> >> Because? I assume b/c no encoding. With that said, it is not obvious >> that this is true because (as shown below) you have to put content- >> length and content-type in the POST version, so if you had a smallish >> request, you might gt more expansion that way, >> > > All DoH responses are at least about 17 bytes long (the 12-byte DNS > message header plus the shortest possible domain name plus the type and > class), much more typically at least 40 bytes with typical names and even a > short answer. Base64 of that will be longer than the content length and > content type. Normal answers will definitely be longer. > to clarify - the text is about requests, not responses.. which will be a bit shorter that what Paul mentions in the dns-message part. fwiw - the h2 hpack overhead here, which we expect is the common case - is on the order of 4 bytes iirc. I think we should resolve this just by hedging.. "are generally smaller than their GET equivalents." > S 6.1. >> >>> The stale-while-revalidate and stale-if-error Cache-Control >>> directives ([RFC5861]) could be well-suited to a DoH implementation >>> when allowed by server policy. Those mechanisms allow a client, at >>> the server's discretion, to reuse a cache entry that is no longer >>> fresh. In such a case, the client reuses all of a cached entry, or >>> none of it. >>> >> >> Is this a normative requirement or a statement of fact? >> > > Not sure. Input from the HTTP crowd is welcome here. > it is a statement of fact about http - its drawn out a bit here because its particularly relevant to DNS (as similar algorithms are considered elsewhere in the DNS world as well), and therefore DoH implementors, when considering whether they want to make use of conditional validations. --00000000000038f23f0573573f52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 13, 2018 at 4:16 PM, Paul Hoffman <paul.hoffman@vpnc.o= rg> wrote:


S 5.1.
=C2=A0 =C2=A0 =C2=A0DoH servers MUST implement both the POST and GET method= s.

=C2=A0 =C2=A0 =C2=A0When using the POST method the DNS query is included as= the message
=C2=A0 =C2=A0 =C2=A0body of the HTTP request and the Content-Type request h= eader field
=C2=A0 =C2=A0 =C2=A0indicates the media type of the message.=C2=A0 POST-ed = requests are
=C2=A0 =C2=A0 =C2=A0smaller than their GET equivalents.

Because? I assume b/c no encoding. With that said, it is not obvious
that this is true because (as shown below) you have to put content-
length and content-type in the POST version, so if you had a smallish
request, you might gt more expansion that way,

 All DoH responses are at least about 17 bytes long (the 12-byte DNS message= header plus the shortest possible domain name plus the type and class), mu= ch more typically at least 40 bytes with typical names and even a short ans= wer. Base64 of that will be longer than the content length and content type= . Normal answers will definitely be longer.


to clarify - the text is about requests, n= ot responses.. which will be a bit shorter that what Paul mentions in the d= ns-message part.

fwiw - the h2 hpack overhead here= , which we expect is the common case - is on the order of 4 bytes iirc.
=

I think we should resolve this just by hedging.. "are ge= nerally smaller than their GET equivalents."



S 6.1.
=C2=A0 =C2=A0 =C2=A0The stale-while-revalidate and stale-if-error Cache-Con= trol
=C2=A0 =C2=A0 =C2=A0directives ([RFC5861]) could be well-suited to a DoH im= plementation
=C2=A0 =C2=A0 =C2=A0when allowed by server policy.=C2=A0 Those mechanisms a= llow a client, at
=C2=A0 =C2=A0 =C2=A0the server's discretion, to reuse a cache entry tha= t is no longer
=C2=A0 =C2=A0 =C2=A0fresh.=C2=A0 In such a case, the client reuses all of a= cached entry, or
=C2=A0 =C2=A0 =C2=A0none of it.

Is this a normative requirement or a statement of fact?

 Not sure. Input from the HTTP crowd is welcome here.


it is a statement of fact ab= out http - its drawn out a bit here because its particularly relevant to DNS (as similar=20 algorithms are considered elsewhere in the DNS world as well), and=20 therefore DoH implementors, when considering whether they want to make=20 use of conditional validations.

=C2=A0

<= /div>
--00000000000038f23f0573573f52-- From nobody Mon Aug 13 14: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 01AF31310DE; Mon, 13 Aug 2018 14:44:26 -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 jmXSc48nItBl; Mon, 13 Aug 2018 14:44:23 -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 272F01310F0; Mon, 13 Aug 2018 14:44:23 -0700 (PDT) Received: from mail-oi0-f43.google.com (mail-oi0-f43.google.com [209.85.218.43]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5444D3A019; Mon, 13 Aug 2018 17:44:19 -0400 (EDT) Received: by mail-oi0-f43.google.com with SMTP id m11-v6so30028056oic.2; Mon, 13 Aug 2018 14:44:19 -0700 (PDT) X-Gm-Message-State: AOUpUlE1RfHc4kwR61ZELWmSTpuqWWHdEQXEU8zsltBU3WzuVVj3TcBU 99VOW1kRvzkeGdXNhsdoALbx/tOLnFYkBjI3Eck= X-Google-Smtp-Source: AA+uWPyFwj9vi3eJLu4BqrfDS8WJyc7EgEHovWKtubLGa8edJP4yQLJ5AxVi2J0HbxKbNZaTMNEhde3BuqjBz2sMHtE= X-Received: by 2002:aca:e80c:: with SMTP id f12-v6mr21327566oih.38.1534196659077; Mon, 13 Aug 2018 14:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:4a43:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 14:44:17 -0700 (PDT) In-Reply-To: References: <153418872923.25024.16784643673174920377.idtracker@ietfa.amsl.com> <451ADADC-1315-4227-A144-7CF7C1E1E666@vpnc.org> From: Patrick McManus Date: Mon, 13 Aug 2018 17:44:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Paul Hoffman , The IESG , draft-ietf-doh-dns-over-https@ietf.org, DoH WG , doh-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000e14b0a057357fe3c" Archived-At: Subject: Re: [Doh] Eric Rescorla's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 13 Aug 2018 21:44:26 -0000 --000000000000e14b0a057357fe3c Content-Type: text/plain; charset="UTF-8" On Mon, Aug 13, 2018 at 4:27 PM, Eric Rescorla wrote: > > >> S 4. >>> >>>> offers an unsolicited response that appears to be a valid answer >>>> to a >>>> DNS query. This specification does not extend DNS resolution >>>> privileges to URIs that are not recognized by the DoH client as >>>> configured URIs. Such scenarios may create additional operational, >>>> tracking, and security hazards that require limitations for safe >>>> usage. A future specification may support this use case. >>>> >>> >>> I am having some trouble understanding what you are prohibiting here. >>> >> >> I send an query to https://www.ekrexample.com/ over HTTP/2. During that >> HTTP/2 session, I get a DoH request/response pair from that origin. >> https://www.ekrexample.com/ is not in the list of configured URIs >> allowed for DoH for this client. I MUST NOT do anything with that DoH >> request/response. >> > > How would you get a DoH request/response pair from that origin? Via push? > The text primarily envisions push, but I believe a application/dns-message response to a 'pull' request could create havoc if placed in a DNS cache (not an HTTP cache) automagically because of the media type (independent of the URI requested). Dns responses contain the dns question, so this isn't impossible. --000000000000e14b0a057357fe3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 13, 2018 at 4:27 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


S 4.
=C2=A0 =C2=A0 =C2=A0offers an unsolicited response that appears to be a val= id answer to a
=C2=A0 =C2=A0 =C2=A0DNS query.=C2=A0 This specification does not extend DNS= resolution
=C2=A0 =C2=A0 =C2=A0privileges to URIs that are not recognized by the DoH c= lient as
=C2=A0 =C2=A0 =C2=A0configured URIs.=C2=A0 Such scenarios may create additi= onal operational,
=C2=A0 =C2=A0 =C2=A0tracking, and security hazards that require limitations= for safe
=C2=A0 =C2=A0 =C2=A0usage.=C2=A0 A future specification may support this us= e case.

I am having some trouble understanding what you are prohibiting here.

 I send an query to https://www.ekrexample.com/ over HTTP/2. During th= at HTTP/2 session, I get a DoH request/response pair from that origin. ht= tps://www.ekrexample.com/ is not in the list of configured URIs allowed= for DoH for this client. I MUST NOT do anything with that DoH request/resp= onse.
<= /span>

How would you get a DoH reque= st/response pair from that origin? Via push?

The text primarily envisions push, but I believe = a application/dns-message response to a 'pull' request could create= havoc if placed in a DNS cache (not an HTTP cache) automagically because o= f the media type (independent of the URI requested). Dns responses contain = the dns question, so this isn't impossible.


--000000000000e14b0a057357fe3c-- From nobody Mon Aug 13 17:08: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 C720A130E5D for ; Mon, 13 Aug 2018 17:08:15 -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 Rd6aYT1Eb3bg for ; Mon, 13 Aug 2018 17:08:14 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007030.outbound.protection.outlook.com [40.92.7.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37914130E37 for ; Mon, 13 Aug 2018 17:08:14 -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=Lwi39aAUdpW4QnXxd7bPFSN5MrOh8DDxZ/famcIgPVA=; b=cMYtLy4cta8CZ/7gHBBxnKEIaQAkUYIRSoTTCdSO2DfO3x0hZBxv8T+Ite5Ln7w6pClo+8LswPTr7eWLcevgdd4Yj4edJT2DTunYD9QGVRjn7q7skLHs4yIleWChWIXtA42P7XGgyP2E+49kiyxjPd0B/lPbud3RzaDRUqEyJ1u6FXhgsXpcUY+uPgFO2VT0VkZc+vSXdfpm8veerosxhRaTdANISeQGuGMP5SbvQxu5XVsatb7lzlSZbT1OLz0Vu9WAra0reBD+AAcuOQgkNqsOSrmQ+gpUxzwW4MiEfEPAJcHc5oiYqoT6TCkewJcHqBCVEghrg6scAEio4DDvSw== Received: from CO1NAM03FT054.eop-NAM03.prod.protection.outlook.com (10.152.80.56) by CO1NAM03HT091.eop-NAM03.prod.protection.outlook.com (10.152.81.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14; Tue, 14 Aug 2018 00:08:13 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.80.58) by CO1NAM03FT054.mail.protection.outlook.com (10.152.81.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14 via Frontend Transport; Tue, 14 Aug 2018 00:08:13 +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.1017.022; Tue, 14 Aug 2018 00:08:13 +0000 From: Star Brilliant To: "doh@ietf.org" CC: Daniel Stenberg Thread-Topic: [Doh] Public endpoints to draft-13 please? Thread-Index: AQHUMwTSqsinU1W9MUStrbFFHbf9E6S+X353 Date: Tue, 14 Aug 2018 00:08:13 +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:FE45F66D0E2DB749A2FECBA4DC659B86EBCDAEBF8B853118254B2E15E7A4FBB1; UpperCasedChecksum:98FCD7204D13694E447F2BD9A97C5749199F866F800A84EB340164DCE4BE1086; SizeAsReceived:7160; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [XZGPjzIgKi8AyG7XH2JiFj31/qPWW71yv0R81/oo38TMwEZ7LE2itB/JCI1Y7Gmd] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM03HT091; 6:keyf16U8HXzSy59Z89FIEYRksFPPq0UWGXn6MYv/xLLhx/Cr5KLIzG25+T5t6qDNqw2nVhFX6TC/jz56MmXFAE8gslXZaF/+ZbPkRimMHIO1Dbhh3XbGqQiHdQMof7FeULWELQeBtYOobitepdiXgfKbz2LzDQFQa6CNFhsKueEYeWYANHKzuXe+X1yc9ahJxHSurLR0e14HXhaEwuH2yOgUAU85NrW60VaD6Gnipr8kvOvBrV+dsow6ma9F1bZbTXyjt8DhHNWUb9h2ttYqpzKaOGyzQ5Kchab8S7YaDHebmmgYgf3V4PR3kdiyc10qsYb8d+GEsuOB6dBJ1yCi1OfVFNCRX8Sy+BoT/DreimMtlashNstzDi4JqdxNbWOn2h3ILcbiByIUZX2JLuc5DIkxzDniDRIefE404G6De+a8aocmiWz+JT0Az5q8n6tInAMnVkKTUNcSzuBInrT4Qw==; 5:hfyQx5B7PxDKIZ+HXaANtFTFURuTiK0q727h+PEAMt38aNlRcWZzwWeCL0otnuEF/2zlxSwBwcfrfzg+VW4k5eWhzMSQP77IGsXMRhCFaZUy+dzusJ36ltu4dFx8KCgvN0rgFwUm0mvmnYvrcSK+ku0+MaSYx6Iy3S4BWggIC1E=; 7:wU0/hxLRloOqJGAMvIP4++EkvDlc8y3rFlYAEcvVbCdm0F0Ss1CF/g/1Ye+bFXki5rrP59YyWH71N5oFjU6KZg/LuuppOlmm9yBVgctiKpwsRvciI4dT3yH6o9rzPHWr3QKhS09ZUR4QVzCI6L8SXZWgPD3xLWK7WeEoC7WXGXx9oEpG9KZSbjU+Tg5BzAcXTaap5PV1tPI0+BuIdJz9BXAEl9pD94XdCJkJcRqq+awLnqPTLe6fxUodcr4k/5k7 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:CO1NAM03HT091; x-ms-traffictypediagnostic: CO1NAM03HT091: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM03HT091; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT091; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(6436002)(446003)(11346002)(5660300001)(83332001)(4326008)(102836004)(6916009)(14454004)(966005)(2351001)(6506007)(46003)(87572001)(2900100001)(229853002)(73972006)(5640700003)(53546011)(14444005)(256004)(82202002)(6346003)(2501003)(7696005)(8936002)(76176011)(104016004)(25786009)(99286004)(5250100002)(56003)(6246003)(86362001)(74316002)(106356001)(305945005)(476003)(9686003)(6306002)(486006)(1730700003)(97736004)(33656002)(81156014)(20460500001)(8676002)(68736007)(55016002)(105586002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM03HT091; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: zVt3y3qHuY8tPhw4bE5vs/1ME6cGxAl/G3pqeNe7gg2Wn8AkGbuBffccgDhYUsJ7Crsid4quLomrW5iqVlx4sgO1GsCPKM080GfzbQu6ZHCqeOIoDzPoLIg5AUDH4piN2q1yQ6eq0+0UcqSSrEuKh1LHZCTZr4CPtE/CIijylMztP3wfq91zeN3tILLZbCptTVdZd9rD2oGoUwnvWiotZ7WZogyXlRI3cyJbklecbgY= 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: c949a26b-9256-4b01-45e2-08d6017a06dc X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2018 00:08:13.1660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT091 Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 14 Aug 2018 00:08:16 -0000 On Mon, Aug 13, 2018 at 10:54 PM Daniel Stenberg wrote: > > Hi, > > I'm keeping a little list of public DoH servers [1]. Today I tried them a= ll > with my draft-13 compliant client and noticed that three out of seven ser= vers > in the list don't like "application/dns-message" as Content-Type, even th= ough > it's been documented since about the draft-07 time frame or so. > > This isn't ideal for interop. > > This email is just to highlight the situation and for me to beg that if y= ou > run such a server you update it soon so that we all play by the same book= ! > > Thanks, > > [1] =3D > https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-serve= rs It seems that Firefox 61 is rejecting "application/dns-message" Content-Typ= e. It fails silently unless you set verbosity to max and watch the terminal= for error log. Related issue: https://github.com/m13253/dns-over-https/issues/15 (I have n= ot forwarded this issue to Mozilla upstream.) Does anyone know if Firefox has fixed it now?= From nobody Mon Aug 13 17:22: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 EB0461310FD for ; Mon, 13 Aug 2018 17:22:25 -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 Xh5jobhlwDTd for ; Mon, 13 Aug 2018 17:22:23 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2C866130E90 for ; Mon, 13 Aug 2018 17:22:23 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by linode64.ducksong.com (Postfix) with ESMTPSA id 801E13A03B for ; Mon, 13 Aug 2018 20:22:19 -0400 (EDT) Received: by mail-oi0-f53.google.com with SMTP id k12-v6so30550934oiw.8 for ; Mon, 13 Aug 2018 17:22:19 -0700 (PDT) X-Gm-Message-State: AOUpUlEdseORBmjmXgrIbLrT0moNZsJkSliIsobyeqHH4PQWpKphTHaC BviylimQ8IcBIZvU+YiJY0+lfnNo+hX03t8kv2U= X-Google-Smtp-Source: AA+uWPxui5y64lxgP4FBopTSiRYgUNTxkBV+K7ClYuoBfd1Izq3ra9OyhryooMssNLl/Brl0OYXcpgX+g7mhcBvb4nk= X-Received: by 2002:aca:2e86:: with SMTP id u128-v6mr18888722oiu.132.1534206139210; Mon, 13 Aug 2018 17:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:4a43:0:0:0:0:0 with HTTP; Mon, 13 Aug 2018 17:22:18 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Mon, 13 Aug 2018 20:22:18 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Star Brilliant Cc: "doh@ietf.org" , Daniel Stenberg Content-Type: multipart/alternative; boundary="000000000000f0a24a05735a33cf" Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 14 Aug 2018 00:22:26 -0000 --000000000000f0a24a05735a33cf Content-Type: text/plain; charset="UTF-8" 63 has the update. it might get backported to 62. I presume the RFC will bring everyone to the same level. On Mon, Aug 13, 2018 at 8:08 PM, Star Brilliant wrote: > On Mon, Aug 13, 2018 at 10:54 PM Daniel Stenberg wrote: > > > > Hi, > > > > I'm keeping a little list of public DoH servers [1]. Today I tried them > all > > with my draft-13 compliant client and noticed that three out of seven > servers > > in the list don't like "application/dns-message" as Content-Type, even > though > > it's been documented since about the draft-07 time frame or so. > > > > This isn't ideal for interop. > > > > This email is just to highlight the situation and for me to beg that if > you > > run such a server you update it soon so that we all play by the same > book! > > > > Thanks, > > > > [1] = > > https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly- > available-servers > > > It seems that Firefox 61 is rejecting "application/dns-message" > Content-Type. It fails silently unless you set verbosity to max and watch > the terminal for error log. > > Related issue: https://github.com/m13253/dns-over-https/issues/15 (I have > not forwarded this issue to Mozilla upstream.) > > Does anyone know if Firefox has fixed it now? > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000f0a24a05735a33cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
63 has the update. it might get backported to 62. I p= resume the RFC will bring everyone to the same level.



On Mon, Aug 13, 2018 at 8:08 PM, Star Brilliant &l= t;m13253@hotmail.co= m> wrote:
= On Mon, Aug 13, 2018 at 10:54 PM Daniel Stenberg <daniel@haxx.se> wrote:
>
> Hi,
>
> I'm keeping a little list of public DoH servers [1]. Today I tried= them all
> with my draft-13 compliant client and noticed that three out of seven = servers
> in the list don't like "application/dns-message" as Cont= ent-Type, even though
> it's been documented since about the draft-07 time frame or so. >
> This isn't ideal for interop.
>
> This email is just to highlight the situation and for me to beg that i= f you
> run such a server you update it soon so that we all play by the same b= ook!
>
> Thanks,
>
> [1] =3D
> https://github.com/c= url/curl/wiki/DNS-over-HTTPS#publicly-available-servers


It seems that Firefox 61 is rejecting "application/dns-message&= quot; Content-Type. It fails silently unless you set verbosity to max and w= atch the terminal for error log.

Related issue: https://github.com/m13253/dns-= over-https/issues/15 (I have not forwarded this issue to Mozilla upstre= am.)

Does anyone know if Firefox has fixed it now?
______________________________= _________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--000000000000f0a24a05735a33cf-- From nobody Mon Aug 13 17:33: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 0BCB71310CC for ; Mon, 13 Aug 2018 17:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 vVsQ34e2wvYK for ; Mon, 13 Aug 2018 17:33:32 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-oln040092007085.outbound.protection.outlook.com [40.92.7.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB94128CF2 for ; Mon, 13 Aug 2018 17:33:32 -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=7iccWq+MTL1yUJZKleO/FtD3InHkGl9UIpMcL2Sr01k=; b=S4sW+wkgd3GyMfgN44o5pLvof0GvhVZ07ePTx3WNhyzWg6dyZPR95EfArWIYtROSQ1hMiNoJdyi/nHDrSQ+57vJbUyzLRMNMX3TleOg23tPE2y7Uzt3VUj+jQ0lwQhUjHfwoKIABEZ5+LoucchRXwxKEqHs09YDu5WBicsX7mYZorV/jYJORP9ZGDomXVQ7Mkqss334IJ+IsS4jHawYth/cOk7sweLj/WIvTxRysHM0tVc7tynQLsjvfi6Bix+45iALr6vZUEFWhwFtnNEkC0geD7eorVRTgJqD+q4Ldby80rsTBdE064xinRS7/5CdyCBXxjSccilqrapvGXkcXag== Received: from CO1NAM03FT052.eop-NAM03.prod.protection.outlook.com (10.152.80.58) by CO1NAM03HT089.eop-NAM03.prod.protection.outlook.com (10.152.81.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14; Tue, 14 Aug 2018 00:33:31 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.80.57) by CO1NAM03FT052.mail.protection.outlook.com (10.152.81.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14 via Frontend Transport; Tue, 14 Aug 2018 00:33:31 +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.1017.022; Tue, 14 Aug 2018 00:33:31 +0000 From: Star Brilliant To: "doh@ietf.org" CC: Daniel Stenberg , Patrick McManus Thread-Topic: [Doh] Public endpoints to draft-13 please? Thread-Index: AQHUMwTSqsinU1W9MUStrbFFHbf9E6S+X353gAAEMACAAADJwg== Date: Tue, 14 Aug 2018 00:33:31 +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:7026245145DCAA4C2ED99C0DBABAAE2B6B3AA6574E70CF0DB00E909A241E729B; UpperCasedChecksum:2979E58430BDA508A2421E391D42CE38F68C7314E43F21B4128708EA74AC752A; SizeAsReceived:7401; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [tZ3RM2jifilmIB5h29CZYgqMvQ5lRm1HO9mZ70K3xgyHLuQAJV020QLLsDpSALPz] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1NAM03HT089; 6:mfR7REt8rWor7Aeelot3NpZYXsfw6VcJT6YuVyNZj8Qm/gcnx3eqj5+nysZf9WliLlr/uQ6zEKj6flVJ1xWO8Ls0B7cIY+TsXBENcHxKFiMEDOukDPOB3CoAqZbha7VYnTakgCWWiJHJr+E9wlYTAza+E9Cnbqpbmrr5LSZhQOXnqJcoId1mwvH6U/5BvAVhvoCK1M80rzY81MHMpbWcINNcqlYuykUPL9qOXW5/sdjChStstsp5rI+DZakuK4F/f9KwhJJmZYEbaCbP4ivsPuwjmXJC+s3xs17B7UUQB86bjaKq2F4eFlEq4Ia9mNSrSsZaaDA6p4FYR4h/GMGDKDPFsRmJ07EKv037K+DbMM0T3VqQyKMESG9/AJLflQhBMrVFSUwTNzryCNMCT39nDo/Nwc1vhzP6U+kn/WdUaZ0H2Al11TH7QG5OP8glR20ghHkzflyBIwwaKtaLZJZByA==; 5:nEVIytWK6Pg0G1H28/Pnf/P7so3pPUWh/z3ArPRYlH0ABo2gsiOkHagdZ8Xm8grWxDE/0ThcEE5/h47GAMKxztysXrQKGt34/z10yxUozzDJQmjXorzH6cM3Cm4wDYxuwuIG9eyKlxf5JnKrlp68VUHopAKzu8xUqiq3idRja2Y=; 7:WoJKmZecI1c7XqgjJ7ceROqbJcn8kEBLBEtMZrftyHnPm6caoMeLjk5Epen0A+zL00BWJKCNh5+/H1vQ7qe3dSkyDLbIUopS4+cUBYtdVWU9Jxtz0sxbO/ljvjgIfGIDtJRJOlavBNUItOsU0lI5S5gqF7SSz3sn/Zfcszd0fwJH/GgIV7aax43GwhbHlSmD+SdL2H4a35sVWOSctTCNXwH8A7xBdbUmGwQREalL7iRtuSWOP3uN/65s1Y/AJQD2 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:CO1NAM03HT089; x-ms-traffictypediagnostic: CO1NAM03HT089: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:CO1NAM03HT089; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM03HT089; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(979002)(189003)(199004)(6346003)(102836004)(9686003)(256004)(54906003)(105586002)(14444005)(106356001)(55016002)(46003)(2351001)(1730700003)(6436002)(14454004)(6916009)(5640700003)(558084003)(5250100002)(2501003)(82202002)(8676002)(7696005)(4326008)(5660300001)(8936002)(87572001)(33656002)(83332001)(73972006)(229853002)(486006)(86362001)(104016004)(305945005)(68736007)(2900100001)(53546011)(6506007)(6246003)(25786009)(11346002)(97736004)(81156014)(446003)(56003)(99286004)(76176011)(20460500001)(74316002)(476003)(15852004)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1901; SCL:1; SRVR:CO1NAM03HT089; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: UX1yoMB6Q/f5PtSSfLBSZ22hy5Tict6Bl7UqH9E3eGfHVX5iNmzfWc6PDw8Xv+jBX/Hzia6Za0sC60kJdr+gFi8w39cT1g3JhOl97pFkO/PXEVIhohutPIKCoYFC0nfNUsRpkwSyXq0XnACBxiuOJ3vkQyLaaOvFhnOz8SH2EAznrZBEMOxplIUyh+CXi4jAw8HuNbrKlZP6ykWuXkbgHWnmuoZjCdct48s8QwvQlzU= 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: 2fb49f41-6dad-4411-1533-08d6017d8fd0 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2018 00:33:31.4282 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM03HT089 Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 14 Aug 2018 00:33:34 -0000 On Tue, Aug 14, 2018 at 10:22 AM Patrick McManus wro= te: > > 63 has the update. it might get backported to 62. I presume the RFC will = bring everyone to the same level. > That's absolutely great! A simple User-Agent check would be able to deal with Firefox 60-62 then.= From nobody Tue Aug 14 04:19:14 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 25CCC130E8E; Tue, 14 Aug 2018 04:19:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stewart Bryant To: Cc: draft-ietf-doh-dns-over-https.all@ietf.org, doh@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153424554611.17939.5084093858433586564@ietfa.amsl.com> Date: Tue, 14 Aug 2018 04:19:06 -0700 Archived-At: Subject: [Doh] Genart telechat review of draft-ietf-doh-dns-over-https-13 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: Tue, 14 Aug 2018 11:19:06 -0000 Reviewer: Stewart Bryant Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-doh-dns-over-https-13 Reviewer: Stewart Bryant Review Date: 2018-08-14 IETF LC End Date: 2018-08-08 IESG Telechat date: 2018-08-16 Summary: This is useful work, it is well written and is ready for publication Major issues: None Minor issues: None Nits/editorial comments: I accept that I am going to be in the rough, but I do not like the term "on the wire". My recollection from my hardware days is that the output shift register sends the data in such a way that if I were to put an oscilloscope on the wire, the bit patterns would not match those shown in this text. What I think are presented in the text are raw RFC1035 messages in network byte order. From nobody Tue Aug 14 07:25:27 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 2B59112426A; Tue, 14 Aug 2018 07:25:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Alvaro Retana To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153425672116.27168.9826412963586619561.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 07:25:21 -0700 Archived-At: Subject: [Doh] Alvaro Retana's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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: Tue, 14 Aug 2018 14:25:21 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-doh-dns-over-https-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is there a request to remove §3 (Protocol Requirements)? I think it provides good background. [BTW, excellent Shepherd writeup!!] From nobody Tue Aug 14 08:00:47 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69B130EDA; Tue, 14 Aug 2018 08:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.436 X-Spam-Level: X-Spam-Status: No, score=-0.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, 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 B_pwgQMWxTz3; Tue, 14 Aug 2018 08:00:30 -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 A3837130EDB; Tue, 14 Aug 2018 08:00:23 -0700 (PDT) Received: from mail-oi0-f51.google.com (mail-oi0-f51.google.com [209.85.218.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0DA5C3A03B; Tue, 14 Aug 2018 11:00:23 -0400 (EDT) Received: by mail-oi0-f51.google.com with SMTP id b16-v6so34076393oic.9; Tue, 14 Aug 2018 08:00:23 -0700 (PDT) X-Gm-Message-State: AOUpUlEnyLTclv5KuubVsWO+FVEQl4YrqsrZKjJUgsNHj9f80yRgmXZm O9r2UaaITInWJle/C2QX2eDGHPVwTnbYYfwleMs= X-Google-Smtp-Source: AA+uWPwqjUe4achfq5H5j3Lkq1Rmb9W8Ut/DShPOq0Bh/mKsJpMxnmdVKz/RlB7naQq/S3/kLjIdDduNLW9HIvfuUNU= X-Received: by 2002:aca:e80c:: with SMTP id f12-v6mr24548134oih.38.1534258822795; Tue, 14 Aug 2018 08:00:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 14 Aug 2018 08:00:22 -0700 (PDT) In-Reply-To: <153425672116.27168.9826412963586619561.idtracker@ietfa.amsl.com> References: <153425672116.27168.9826412963586619561.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Tue, 14 Aug 2018 11:00:22 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Alvaro Retana Cc: The IESG , draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, DoH WG Content-Type: multipart/alternative; boundary="0000000000002059430573667875" Archived-At: Subject: Re: [Doh] Alvaro Retana's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 14 Aug 2018 15:00:39 -0000 --0000000000002059430573667875 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alvaro - thanks for the review! I believe your comment also just popped up in Magnus's review in another thread that I responded to - so I'll avoid crossing the streams and refer you to that. On Tue, Aug 14, 2018 at 10:25 AM, Alvaro Retana wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-doh-dns-over-https-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Why is there a request to remove =C2=A73 (Protocol Requirements)? I thin= k it > provides good background. > > [BTW, excellent Shepherd writeup!!] > > > --0000000000002059430573667875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alvaro - thanks for the review!

<= div>I believe your comment also just popped up in Magnus's review in an= other thread that I responded to - so I'll avoid crossing the streams a= nd refer you to that.

On Tue, Aug 14, 2018 at 10:25 AM, Alvaro Retana <= aretana.ietf@gmail.com> wrote:
Alvaro Retana has entered the following ballot position for
draft-ietf-doh-dns-over-https-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-doh-dns-over-https/



-----------------------------------------------------------------= -----
COMMENT:
-----------------------------------------------------------------= -----

Why is there a request to remove =C2=A73 (Protocol Requirements)?=C2=A0 I t= hink it provides good background.

[BTW, excellent Shepherd writeup!!]



--0000000000002059430573667875-- From nobody Tue Aug 14 08:41:33 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 DCC49130DC8; Tue, 14 Aug 2018 08:41:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153426129189.27071.38667971889611003.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2018 08:41:31 -0700 Archived-At: Subject: [Doh] Benjamin Kaduk's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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: Tue, 14 Aug 2018 15:41:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-doh-dns-over-https-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'll try to trim comments that were already mentioned, but will make an exception for my surprise to see the (non-)requirements sections slated for removal. Would it be better to move them to an Appendix with disclaimer that "the following goals were used by the WG during the design process but do not represent an exhaustive list"? It's a little unclear how much of the requirements on future work (e.g., media type/formats) needs to be done now vs. can be done when such work appears. [section-by-section comments follow] Section 5.1 Future specifications for new media types MUST define the variables used for URI Template processing with this protocol. This is scoped to just future DNS-over-HTTP media types, right? In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message. The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. It's probably clear enough as implicit (especially given two paragraphs prior), but do you want to mention that this HTTP-layer caching? DoH clients can use HTTP/2 padding and compression in the same way that other HTTP/2 clients use (or don't use) them. Probably need the 7540 cite here as well. Section 5.1.1 In this example, the 33 bytes are the DNS message in DNS wire format. Cite for "DNS wire format" (1035)? Also, adding something like "starting with the DNS header" might forestall questions about "is the UDP header or DNS/TCP length prefix included?". Section 5.2.1 [...] This might mean that the DoH client retries the query with the same DoH server, such as authorization failures (HTTP status code 401 [RFC7235] Section 3.1). Is there a word or three missing here? Section 6.1 [...] (POST requests are not cacheable unless specific response header fields are sent; this is not widely implemented, and not advised for DoH). I do not claim to be an HTTP expert, but are "request" and "response" swapped in the above? [...] This requirement helps assure that none of the RRsets contained in a DNS response are served stale from an HTTP cache. Is this better as "unintentionally served stale"? The stale-while-revalidate and stale-if-error Cache-Control directives ([RFC5861]) could be well-suited to a DoH implementation when allowed by server policy. Those mechanisms allow a client, at the server's discretion, to reuse a cache entry that is no longer fresh. In such a case, the client reuses all of a cached entry, or none of it. Given that we're talking about the interaction between HTTP caching and DNS caching, it seems reasonable to specify which layer of cache's cached entry we're talking about. (Probably other instances later in the section, too.) Other types of DNS data, such as zone transfers, may be larger and benefit more from revalidation. Just to check my recollection: the current DoH document is incompatible with zone transfers (by virtue of being single request/response)? Section 8.1 It's unclear that the security considerations for application/dns-message exactly match those of "pure" DNS. For example, DNS messages expect to interact with DNS-layer caching, and messages wrapped in an application/dns media type may also have to interact with additional cache layers (e.g., all of Section 6.1 of this document's considerations), and mis-caching can have security consequences. Section 9.2 DNS implementations that use one TCP connection for multiple DNS requests directly group those requests. Long-lived connections have better performance behaviors than short-lived connections, but group more requests. [...] I think the consequence of "group more requests" should probably be spelled out, e.g., "which exposes more information to correlation and consolidation". Section 11 The HTTPS channel used by this specification establishes secure two- party communication between the DoH client and the DoH server. What does "secure" mean? [...] For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using [RFC6066] Section 8 for TLS version 1.2. [...] TLS 1.3 is final (RFC 8446) if you feel like using the most-current reference. From nobody Tue Aug 14 09:49: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 A5653130DD3; Tue, 14 Aug 2018 09:49:57 -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 fLx_rj-RrixE; Tue, 14 Aug 2018 09:49:55 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4989130DDB; Tue, 14 Aug 2018 09:49:55 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 14 Aug 2018 09:49:53 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Tue, 14 Aug 2018 09:49:53 -0700 From: Paul Hoffman To: Benjamin Kaduk CC: The IESG , "draft-ietf-doh-dns-over-https@ietf.org" , Benjamin Schwartz , "doh-chairs@ietf.org" , "doh@ietf.org" Thread-Topic: [Ext] Benjamin Kaduk's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) Thread-Index: AQHUM+VHS4ZBPFj3y0+tec3XX1AlvqS/6zIA Date: Tue, 14 Aug 2018 16:49:53 +0000 Message-ID: References: <153426129189.27071.38667971889611003.idtracker@ietfa.amsl.com> In-Reply-To: <153426129189.27071.38667971889611003.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Benjamin Kaduk's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 14 Aug 2018 16:49:58 -0000 Thanks for the review! > Section 5.1 >=20 > Future specifications for new media types MUST define the variables > used for URI Template processing with this protocol. >=20 > This is scoped to just future DNS-over-HTTP media types, right? Yes, we'll clarify that. >=20 > In order to maximize cache friendliness, DoH clients using media > formats that include DNS ID, such as application/dns-message, SHOULD > use a DNS ID of 0 in every DNS request. HTTP correlates the request > and response, thus eliminating the need for the ID in a media type > such as application/dns-message. The use of a varying DNS ID can > cause semantically equivalent DNS queries to be cached separately. >=20 > It's probably clear enough as implicit (especially given two paragraphs > prior), but do you want to mention that this HTTP-layer caching? Yep, will fix. > DoH clients can use HTTP/2 padding and compression in the same way > that other HTTP/2 clients use (or don't use) them. >=20 > Probably need the 7540 cite here as well. Sure. > Section 5.1.1 >=20 > In this example, the 33 bytes are the DNS message in DNS wire format. >=20 > Cite for "DNS wire format" (1035)? Sure. > Also, adding something like "starting with the DNS header" might forestal= l > questions about "is the UDP header or DNS/TCP length prefix included?". OK. >=20 > Section 5.2.1 >=20 > [...] This might mean that the > DoH client retries the query with the same DoH server, such as > authorization failures (HTTP status code 401 [RFC7235] Section 3.1). >=20 > Is there a word or three missing here? Yep; fixed. >=20 > Section 6.1 >=20 > [...] (POST requests are not > cacheable unless specific response header fields are sent; this is > not widely implemented, and not advised for DoH). >=20 > I do not claim to be an HTTP expert, but are "request" and "response" > swapped in the above? Not swapped, but our current wording is not right either. Fixing. >=20 > [...] This requirement helps assure that > none of the RRsets contained in a DNS response are served stale from > an HTTP cache. >=20 > Is this better as "unintentionally served stale"? Sure. >=20 > The stale-while-revalidate and stale-if-error Cache-Control > directives ([RFC5861]) could be well-suited to a DoH implementation > when allowed by server policy. Those mechanisms allow a client, at > the server's discretion, to reuse a cache entry that is no longer > fresh. In such a case, the client reuses all of a cached entry, or > none of it. >=20 > Given that we're talking about the interaction between HTTP caching and D= NS > caching, it seems reasonable to specify which layer of cache's cached ent= ry > we're talking about. (Probably other instances later in the section, too= .) Agree, and added "HTTP" in a few other places near here. > Other types of DNS data, such as zone transfers, may be larger and > benefit more from revalidation. >=20 > Just to check my recollection: the current DoH document is incompatible > with zone transfers (by virtue of being single request/response)? Not completely. Some AXFRs can be done in a single response. This document = does not prohibit trying AXFR. >=20 > Section 8.1 >=20 > It's unclear that the security considerations for application/dns-message > exactly match those of "pure" DNS. For example, DNS messages expect to > interact with DNS-layer caching, and messages wrapped in an application/d= ns > media type may also have to interact with additional cache layers (e.g., > all of Section 6.1 of this document's considerations), and mis-caching ca= n > have security consequences. Good point. We'll just repoint the IANA registration security consideration= s to the more inclusive ones in this document. >=20 > Section 9.2 >=20 > DNS implementations that use one TCP connection for multiple DNS > requests directly group those requests. Long-lived connections have > better performance behaviors than short-lived connections, but group > more requests. [...] >=20 > I think the consequence of "group more requests" should probably be spell= ed > out, e.g., "which exposes more information to correlation and > consolidation". Added. >=20 > Section 11 >=20 > The HTTPS channel used by this specification establishes secure two- > party communication between the DoH client and the DoH server. >=20 > What does "secure" mean? The same thing as the "S" in "TLS". Explaining this again at this point mig= ht not bring much understanding to the reader, however. >=20 > [...] For OCSP, the > server can bundle the certificate status as part of the handshake > using a mechanism appropriate to the version of TLS, such as using > [RFC6066] Section 8 for TLS version 1.2. [...] >=20 > TLS 1.3 is final (RFC 8446) if you feel like using the most-current > reference. We do!=20 --Paul Hoffman= From nobody Tue Aug 14 09:56: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 B0B06128CFD; Tue, 14 Aug 2018 09:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 c4_yTRD7jOIC; Tue, 14 Aug 2018 09:56:19 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 E5D35130934; Tue, 14 Aug 2018 09:56:18 -0700 (PDT) X-AuditID: 1209190f-1f9ff7000000252f-5c-5b7309b0f741 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 35.14.09519.1B9037B5; Tue, 14 Aug 2018 12:56:17 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w7EGuCbK000777; Tue, 14 Aug 2018 12:56:13 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w7EGu7BI016269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Aug 2018 12:56:09 -0400 Date: Tue, 14 Aug 2018 11:56:07 -0500 From: Benjamin Kaduk To: Paul Hoffman Cc: The IESG , "draft-ietf-doh-dns-over-https@ietf.org" , Benjamin Schwartz , "doh-chairs@ietf.org" , "doh@ietf.org" Message-ID: <20180814165606.GD40887@kduck.kaduk.org> References: <153426129189.27071.38667971889611003.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsUixG6noruRszjaYP0TFYu/D+ayWjxuf8hi ce3uRTaL/7uuMlrM+DOR2aJ30hNGBzaPBZtKPQ5fuM/isWTJT6YA5igum5TUnMyy1CJ9uwSu jOZdE5kKfmtVvHp0nLGB8ZVCFyMnh4SAiUT/4XWMILaQwGImiUOHfLoYuYDsjYwSd54/ZIJw rgIllvSyglSxCKhKvJi3mwXEZhNQkWjovswMYosIaEp8OAgS5+JgFmhjkng35SxQgoNDWCBN 4swXH5AaXqBt57resUFsq5N4+fwFC0RcUOLkzCdgNrOAlsSNfy+ZQFqZBaQllv/jAAlzCthK XNjdC9YqKqAssbfvEPsERoFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6J Xm5miV5qSukmRlBQc0ry72Cc0+B9iFGAg1GJhzfgUlG0EGtiWXFl7iFGSQ4mJVHedLbiaCG+ pPyUyozE4oz4otKc1OJDjBIczEoivDKMQDnelMTKqtSifJiUNAeLkjjvvZrwaCGB9MSS1OzU 1ILUIpisDAeHkgTvFg6gRsGi1PTUirTMnBKENBMHJ8hwHqDhm0BqeIsLEnOLM9Mh8qcYjTn+ vJ86iZljX/e0ScxCLHn5ealS4rxRIKUCIKUZpXlw00CJSSJ7f80rRnGg54R51YBpSogHmNTg 5r0CWsUEtCpZpBBkVUkiQkqqgVHRZ02QnNyhrQouL0UXGk4vKSkRSWzYdfuk/w8ej6sTtdWm LGYN3715q3bZD4OXPz//T5VdctZPNi1MiseouS59d/POX1f1Zr2MWyK2hTdh279bn4762xyb klcWJr+Caw7Xhv6DDyST5s4J3+46VTbN8NsmwTUm5WHcIV90TTIXsFivOi23VFCJpTgj0VCL uag4EQAeAhNtJwMAAA== Archived-At: Subject: Re: [Doh] [Ext] Benjamin Kaduk's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 14 Aug 2018 16:56:22 -0000 On Tue, Aug 14, 2018 at 04:49:53PM +0000, Paul Hoffman wrote: > Thanks for the review! Thanks for the fixes! Just one note inline... > > Section 5.1 > > > > Future specifications for new media types MUST define the variables > > used for URI Template processing with this protocol. > > > > This is scoped to just future DNS-over-HTTP media types, right? > > Yes, we'll clarify that. > > > > > In order to maximize cache friendliness, DoH clients using media > > formats that include DNS ID, such as application/dns-message, SHOULD > > use a DNS ID of 0 in every DNS request. HTTP correlates the request > > and response, thus eliminating the need for the ID in a media type > > such as application/dns-message. The use of a varying DNS ID can > > cause semantically equivalent DNS queries to be cached separately. > > > > It's probably clear enough as implicit (especially given two paragraphs > > prior), but do you want to mention that this HTTP-layer caching? > > Yep, will fix. > > > DoH clients can use HTTP/2 padding and compression in the same way > > that other HTTP/2 clients use (or don't use) them. > > > > Probably need the 7540 cite here as well. > > Sure. > > > Section 5.1.1 > > > > In this example, the 33 bytes are the DNS message in DNS wire format. > > > > Cite for "DNS wire format" (1035)? > > Sure. > > > Also, adding something like "starting with the DNS header" might forestall > > questions about "is the UDP header or DNS/TCP length prefix included?". > > OK. > > > > > Section 5.2.1 > > > > [...] This might mean that the > > DoH client retries the query with the same DoH server, such as > > authorization failures (HTTP status code 401 [RFC7235] Section 3.1). > > > > Is there a word or three missing here? > > Yep; fixed. > > > > > Section 6.1 > > > > [...] (POST requests are not > > cacheable unless specific response header fields are sent; this is > > not widely implemented, and not advised for DoH). > > > > I do not claim to be an HTTP expert, but are "request" and "response" > > swapped in the above? > > Not swapped, but our current wording is not right either. Fixing. > > > > > [...] This requirement helps assure that > > none of the RRsets contained in a DNS response are served stale from > > an HTTP cache. > > > > Is this better as "unintentionally served stale"? > > Sure. > > > > > The stale-while-revalidate and stale-if-error Cache-Control > > directives ([RFC5861]) could be well-suited to a DoH implementation > > when allowed by server policy. Those mechanisms allow a client, at > > the server's discretion, to reuse a cache entry that is no longer > > fresh. In such a case, the client reuses all of a cached entry, or > > none of it. > > > > Given that we're talking about the interaction between HTTP caching and DNS > > caching, it seems reasonable to specify which layer of cache's cached entry > > we're talking about. (Probably other instances later in the section, too.) > > Agree, and added "HTTP" in a few other places near here. > > > Other types of DNS data, such as zone transfers, may be larger and > > benefit more from revalidation. > > > > Just to check my recollection: the current DoH document is incompatible > > with zone transfers (by virtue of being single request/response)? > > Not completely. Some AXFRs can be done in a single response. This document does not prohibit trying AXFR. > > > > > Section 8.1 > > > > It's unclear that the security considerations for application/dns-message > > exactly match those of "pure" DNS. For example, DNS messages expect to > > interact with DNS-layer caching, and messages wrapped in an application/dns > > media type may also have to interact with additional cache layers (e.g., > > all of Section 6.1 of this document's considerations), and mis-caching can > > have security consequences. > > Good point. We'll just repoint the IANA registration security considerations to the more inclusive ones in this document. > > > > > Section 9.2 > > > > DNS implementations that use one TCP connection for multiple DNS > > requests directly group those requests. Long-lived connections have > > better performance behaviors than short-lived connections, but group > > more requests. [...] > > > > I think the consequence of "group more requests" should probably be spelled > > out, e.g., "which exposes more information to correlation and > > consolidation". > > Added. > > > > > Section 11 > > > > The HTTPS channel used by this specification establishes secure two- > > party communication between the DoH client and the DoH server. > > > > What does "secure" mean? > > The same thing as the "S" in "TLS". Explaining this again at this point might not bring much understanding to the reader, however. Could you say something like "due to the confidentiality and integrity protection provided by TLS" at the end of the subsequent sentence? -Benjamin > > [...] For OCSP, the > > server can bundle the certificate status as part of the handshake > > using a mechanism appropriate to the version of TLS, such as using > > [RFC6066] Section 8 for TLS version 1.2. [...] > > > > TLS 1.3 is final (RFC 8446) if you feel like using the most-current > > reference. > > We do! > > --Paul Hoffman From nobody Tue Aug 14 10:00: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 90540130DDB; Tue, 14 Aug 2018 10:00:36 -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=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 ufMgSg0SmcgL; Tue, 14 Aug 2018 10:00:35 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) by ietfa.amsl.com (Postfix) with ESMTP id B9C38130934; Tue, 14 Aug 2018 10:00:35 -0700 (PDT) Received: from [169.254.254.12] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w7EGxkTe062598 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Aug 2018 09:59:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [169.254.254.12] From: "Paul Hoffman" To: "Benjamin Kaduk" Cc: "Paul Hoffman" , "The IESG" , draft-ietf-doh-dns-over-https@ietf.org, "Benjamin Schwartz" , doh-chairs@ietf.org, doh@ietf.org Date: Tue, 14 Aug 2018 10:00:07 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <7B076945-C58B-4FBE-B8EC-BD98DDF9015B@vpnc.org> In-Reply-To: <20180814165606.GD40887@kduck.kaduk.org> References: <153426129189.27071.38667971889611003.idtracker@ietfa.amsl.com> <20180814165606.GD40887@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Doh] [Ext] Benjamin Kaduk's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 14 Aug 2018 17:00:37 -0000 On 14 Aug 2018, at 9:56, Benjamin Kaduk wrote: >>> Section 11 >>> >>> The HTTPS channel used by this specification establishes secure >>> two- >>> party communication between the DoH client and the DoH server. >>> >>> What does "secure" mean? >> >> The same thing as the "S" in "TLS". Explaining this again at this >> point might not bring much understanding to the reader, however. > > Could you say something like "due to the confidentiality and integrity > protection provided by TLS" at the end of the subsequent sentence? Sure. --Paul Hoffman From nobody Wed Aug 15 08:23:29 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 B1FAC130FEE; Wed, 15 Aug 2018 08:23:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153434660571.14501.81494673201051792.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 08:23:25 -0700 Archived-At: Subject: [Doh] Alissa Cooper's Yes on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 15 Aug 2018 15:23:26 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-doh-dns-over-https-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for your work on this protocol and for the comprehensive privacy considerations. COMMENTS S 5.1. > The DoH client SHOULD include an HTTP "Accept" request header field > to indicate what type of content can be understood in response. > Irrespective of the value of the Accept request header field, the > client MUST be prepared to process "application/dns-message" (as > described in Section 7) responses but MAY also process any other type > it receives. I read this before seeing the other email discussion about it and thought it meant that the client might be processing other types for non-DNS HTTP requests, which obviously was the wrong interpretation. I think this text requires some clarification. From nobody Wed Aug 15 09: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 82417130FF9; Wed, 15 Aug 2018 09:06:33 -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=cooperw.in header.b=VQiJChQl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pn0gCXgO 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 Ov2NA9ghQV6F; Wed, 15 Aug 2018 09:06:31 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8245F130FED; Wed, 15 Aug 2018 09:06:31 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 7A5B429C; Wed, 15 Aug 2018 12:06:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 15 Aug 2018 12:06:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; 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=7e5oUfayWhZAJx/Bv2l+EOXUQLKis FEnWFHmuPznaJw=; b=VQiJChQl1p4+5h79YDiYR6+cLI1OoGJ6Pj2GtoPdVu5US v1GWHODoOANyCqb7wc3jU5lCwLrkflVlDA3W0tIH0HGvvD/Aq2HirCdg/jKy1yzh /b9gTIsJQlZEza/VuDqYSQidj1lyf07lZ2IPLU/ti9ZPxqYLkYfDubwN+gzFuHv/ JdNzJ/gYHJyk5lsBwDlZ7HwIuBDmDnCWm6J6DeFMRb2K6WlzTmHlAypBeMG/YiZC n8EuaRZUPDAlsKP1YOmMPYTlsx23PmMw7FYzeG+Fq8euIcPdN6iUNxjsyDlsdrP2 qJTp88hspJMXTiozoIrRiuVuylnHewtVKppW2f2cw== 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=7e5oUf ayWhZAJx/Bv2l+EOXUQLKisFEnWFHmuPznaJw=; b=pn0gCXgOMsYLkGhpzG1hcv uZXgrtRQyiMrRKjeUGnRxw87H7P0AA8VnYj1ZG9YBsMv3Piq3UVSIOxNbs3wyxTj AYBqdfE3pxhDwFJOr8aekmLZH0vgqRsFJjMqcxv0Br3TnrGEoB2X9RyMzGKQDHhQ lIa2G/adPTdmxXC92edePl1f4elnyM8GbyMgI9nK8zXflcOL8LdiMq8JARj1IXDd XVNwUxRxvGBjYAbfYVB7Mksoh9mpzTv4+ZJVlKR4xVo+b5XaxFUIpO6A5/GBSFUe MFMUeZ9l1tWVlWZU/DM/kU42qSYrGSI6SUYJ5blTB6DnncmPfx7FpA/gC/Lhsvsg == X-ME-Proxy: X-ME-Sender: Received: from dhcp-10-150-9-145.cisco.com (unknown [173.38.117.87]) by mail.messagingengine.com (Postfix) with ESMTPA id 6203CE4621; Wed, 15 Aug 2018 12:06:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <153337279710.31560.12854746020010274260@ietfa.amsl.com> Date: Wed, 15 Aug 2018 12:06:27 -0400 Cc: gen-art , draft-ietf-doh-dns-over-https.all@ietf.org, doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <048C13B8-5E0A-4B4F-841F-E0517F106F57@cooperw.in> References: <153337279710.31560.12854746020010274260@ietfa.amsl.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Doh] [Gen-art] Genart last call review of 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, 15 Aug 2018 16:06:34 -0000 Stewart, thanks for your reviews. Paul, thanks for your responses. I = have entered a Yes ballot. Alissa > On Aug 4, 2018, at 4:53 AM, Stewart Bryant = wrote: >=20 > Reviewer: Stewart Bryant > Review result: On the Right Track >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-doh-dns-over-https-12 > Reviewer: Stewart Bryant > Review Date: 2018-08-04 > IETF LC End Date: 2018-08-08 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: >=20 > ID-Nits picks up a downref, but the appropriate warning was included = in the IETF LC email. >=20 > Major issues: >=20 > 4. Selection of DoH Server >=20 > SB> I am surprised that there is no discussion of the need to specify > SB> the raw IP address of the sever as part of the URI, and that there > SB> is no discussion of the server address IP address family in the = document. > SB> I would have thought that there should at least be a reference to > SB> "happy eyeballs" and and discussion of an optimization strategy = of=20 > SB> what to do if there was a response on Ipv4 and not IPv6 etc etc. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The same DNS query for www.example.com, using the POST method would > be: >=20 > :method =3D POST > :scheme =3D https > :authority =3D dnsserver.example.net > :path =3D /dns-query > accept =3D application/dns-message > content-type =3D application/dns-message > content-length =3D 33 >=20 > <33 bytes represented by the following hex encoding> > 00 00 01 00 00 01 00 00 00 00 00 00 03 77 77 77 > 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 > 01 >=20 > SB> At this point in the text am at a loss to understand the 33 = bytes.=20 > SB> Having read to the end of the text, I assume that this is a binary = encoded > SB> DNS query in "one the wire format" but this point needs to be made = clear, > SB> as does the explicit encoding. It would be really useful if there = was an > SB> example of both formats side by side. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > The DNS query is 94 bytes represented by the following hex encoding > SB> Again in what format? >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D > :method =3D GET > :scheme =3D https > :authority =3D dnsserver.example.net > :path =3D /dns-query? (no space or CR) > dns=3DAAABAAABAAAAAAAAAWE-NjJjaGFyYWN0ZXJsYWJl (no space or = CR) > bC1tYWtlcy1iYXNlNjR1cmwtZGlzdGluY3QtZnJvbS1z (no space or = CR) > dGFuZGFyZC1iYXNlNjQHZXhhbXBsZQNjb20AAAEAAQ > accept =3D application/dns-message >=20 > SB> I am not a DNS or HTTP specialist, so please help me understand > SB> what the string starting "dns=3D" is. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 5.2.2. HTTP Response Example >=20 > SB> Nits says: >=20 > -- The document has examples using IPv4 documentation addresses = according > to RFC6890, but does not use any IPv6 documentation addresses. = Maybe > there should be IPv6 examples, too? >=20 > SB> I am not sure if there are any IPv4 vs IPv6 issues but it would be = helpful to > SB> clarify the point. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > <64 bytes represented by the following hex encoding> > 00 00 81 80 00 01 00 01 00 00 00 00 03 77 77 77 > 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 > 01 03 77 77 77 07 65 78 61 6d 70 6c 65 03 63 6f > 6d 00 00 01 00 01 00 00 00 80 00 04 C0 00 02 01 >=20 > SB> At this point in the text I am still wondering what this encoding = means, I assume that > SB> it is a hex representation of the payload received > SB> back from a normal DNS query. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > 7. Definition of the application/dns-message media type >=20 > The data payload for the application/dns-message media type is a > single message of the DNS on-the-wire format defined in Section = 4.2.1 > of [RFC1035].=20 >=20 > SB> That would have been useful to have known earlier > SB> However 4.2.1 just talks about UDP and not the message syntax. > SB> Also presumably we are talking about the payload of the UDP > SB> message excluding the UDP header. >=20 > SB> "on-the-wire" is a potentially confusing term, since it gets us > SB> into network byte order etc. > SB> I think the whole thing would be clearer is you said that your > SB> message was identical to the payload of the UDP payload of an > SB> RFC1035 as seen by a server (and then add some specification=20 > SB> about the payload to hex method you are using) > SB> It would also be helpful to the reader to note whether > SB> any of the 25 updates to RFC1035 impact any of the specification > SB> described in this memo. >=20 > =3D=3D=3D=3D=3D=3D=3D >=20 > The format was originally for DNS over UDP. Although > [RFC1035] says "Messages carried by UDP are restricted to 512 = bytes", > that was later updated by [RFC6891]. This media type restricts the > maximum size of the DNS message to 65535 bytes. Note that the wire > format used in this media type is different than the wire format = used > in [RFC7858] (which uses the format defined in Section 4.2.2 of > [RFC1035]). >=20 > SB> 4.2.2 does not seem to describe a format, unless you are = implicitly > SB> saying that 4.2.1 does not have a length 4.2.2 does and you > SB> are encoding the length another way and hence use 4.2.1 format. > SB> Either way neither of these sections of RFC1035 really specify the > SB> format, that is provided earlier in the RFC. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Encoding considerations: This is a binary format. The contents are a > DNS message as defined in RFC 1035. The format used here is for DNS > over UDP, which is the format defined in the diagrams in RFC 1035. >=20 > SB> With or without the UDP header? >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Minor issues: >=20 > Abstract >=20 > This document describes how to make DNS queries over HTTPS. >=20 > SB> This is the shortest abstract I have seen in a long while, if > SB> not forever. It would be helpful to the undecided reader if > SB> a little more context from the Introduction was included in the > SB> abstract. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Nits/editorial comments:=20 >=20 > These caches may exist beteen the > SB> s/beteen/between/ >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Aug 15 09:14: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 2A43113106F; Wed, 15 Aug 2018 09:14:24 -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 DPOH8PpeEmuu; Wed, 15 Aug 2018 09:14:22 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9CA7131058; Wed, 15 Aug 2018 09:14:22 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 15 Aug 2018 09:14:21 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Wed, 15 Aug 2018 09:14:21 -0700 From: Paul Hoffman To: Alissa Cooper CC: The IESG , "draft-ietf-doh-dns-over-https@ietf.org" , "doh-chairs@ietf.org" , DoH WG Thread-Topic: [Ext] Alissa Cooper's Yes on draft-ietf-doh-dns-over-https-13: (with COMMENT) Thread-Index: AQHUNKvrO4GPG1t04kecKWVdQdTyWaTBcgkA Date: Wed, 15 Aug 2018 16:14:20 +0000 Message-ID: <83CCDDF5-9E1B-4C30-A225-3A743BA0AFBB@icann.org> References: <153434660571.14501.81494673201051792.idtracker@ietfa.amsl.com> In-Reply-To: <153434660571.14501.81494673201051792.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A73FCE784B2BE4B846757791636E7E3@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Alissa Cooper's Yes on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 15 Aug 2018 16:14:25 -0000 On Aug 15, 2018, at 8:23 AM, Alissa Cooper wrote: > Thanks for your work on this protocol and for the comprehensive > privacy considerations. The WG contributed most of that. >=20 > COMMENTS > S 5.1. >> The DoH client SHOULD include an HTTP "Accept" request header field >> to indicate what type of content can be understood in response. >> Irrespective of the value of the Accept request header field, the >> client MUST be prepared to process "application/dns-message" (as >> described in Section 7) responses but MAY also process any other typ= e >> it receives. >=20 > I read this before seeing the other email discussion about it and > thought it meant that the client might be processing other types for > non-DNS HTTP requests, which obviously was the wrong interpretation. I > think this text requires some clarification. We'll fix this to be clear that the other media types are DNS-related. --Paul Hoffman From nobody Wed Aug 15 09:24:48 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 196AC130FF8; Wed, 15 Aug 2018 09:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153435028609.14458.3744003304771066071.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 09:24:46 -0700 Archived-At: Subject: [Doh] Warren Kumari's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 15 Aug 2018 16:24:46 -0000 Warren Kumari has entered the following ballot position for draft-ietf-doh-dns-over-https-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you -- I've been following this work, and so only have a few minor comments at this point... Section 3. Protocol Requirements I really think that this section should remain - it is helpful to people new to the technology to understand how and why design decisions were made. If you are not comfortable with it in the body of the document, perhaps it could be made an Appendix. Section 5.1. The HTTP Request " In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request." While this should be obvious, as this document is talking about both DNS and HTTP it would be helpful to clarify **which** cache. Section 6.1. Cache Interaction "This requirement helps assure that none of the RRsets contained in a DNS response are served stale from an HTTP cache." The wording of this feels a little "clunky", but I don't really have a suggested fix. I also think that it would be helpful if the "served stale" term could be changed, but this might just be because I think of draft-ietf-dnsop-serve-stale when I see that. General: You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure. From nobody Wed Aug 15 09:47: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 D8026130E68; Wed, 15 Aug 2018 09:47:18 -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 E0WlqQbLaJcD; Wed, 15 Aug 2018 09:47:17 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D44C130DC8; Wed, 15 Aug 2018 09:47:17 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 15 Aug 2018 09:47:15 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Wed, 15 Aug 2018 09:47:15 -0700 From: Paul Hoffman To: Warren Kumari CC: The IESG , "draft-ietf-doh-dns-over-https@ietf.org" , "doh-chairs@ietf.org" , DoH WG Thread-Topic: [Ext] Warren Kumari's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) Thread-Index: AQHUNLR9c2LKZrGOCU+EIZwTmqypNKTBeywA Date: Wed, 15 Aug 2018 16:47:15 +0000 Message-ID: <041E52A4-E854-4D06-A25D-5C50762DCFCF@icann.org> References: <153435028609.14458.3744003304771066071.idtracker@ietfa.amsl.com> In-Reply-To: <153435028609.14458.3744003304771066071.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D7723963EBBEF45A19425A62899B7BF@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Warren Kumari's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 15 Aug 2018 16:47:19 -0000 On Aug 15, 2018, at 9:24 AM, Warren Kumari wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thank you -- I've been following this work, and so only have a few minor > comments at this point... >=20 > Section 3. Protocol Requirements > I really think that this section should remain - it is helpful to people = new to > the technology to understand how and why design decisions were made. If y= ou are > not comfortable with it in the body of the document, perhaps it could be = made > an Appendix. We've now heard this from a bunch of the IETF-wide reviewers. Patrick point= ed out earlier that the WG has seen this section as "will be removed" durin= g the later part of the WG process, and that it was not meant to limit futu= re work on DoH. Having said that, making it an appendix with some wording t= o not limit future work could be nearly harmless. We'll look at that. > Section 5.1. The HTTP Request > " In order to maximize cache friendliness, DoH clients using media format= s that > include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0= in > every DNS request." While this should be obvious, as this document is tal= king > about both DNS and HTTP it would be helpful to clarify **which** cache. This was already caught by earlier reviewers. Our working copy now says whi= ch cache is being discussed in a more places, including here. > Section 6.1. Cache Interaction > "This requirement helps assure that none of the RRsets contained in a DNS > response are served stale from an HTTP cache." The wording of this feels = a > little "clunky", but I don't really have a suggested fix. I also think th= at it > would be helpful if the "served stale" term could be changed, but this mi= ght > just be because I think of draft-ietf-dnsop-serve-stale when I see that. Based on an earlier comment, we made it clear that this was about unintenti= onally serving stale. I agree that "stale" is not really the right word her= e; RFC 1035 uses "expired", so we can use it here. > General: > You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure. Yes, definitely. --Paul Hoffman From nobody Wed Aug 15 09:55: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 40074131016 for ; Wed, 15 Aug 2018 09:55:10 -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=kumari-net.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 Qh4fUGlKDVqH for ; Wed, 15 Aug 2018 09:55:08 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 DD451131001 for ; Wed, 15 Aug 2018 09:55:05 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id h14-v6so1674137wrw.13 for ; Wed, 15 Aug 2018 09:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4ImMZQ0ldn7Qptx2Gwt/JTveVhM21ZNWByQUZLyeGbY=; b=vrU777lNqneWwVQmeCa78j8x449feQ6cNFfE/217lscxjchIM+uPEi8swd1wBO7JGD Vs9+LHMTkgquBKDosTnSYwpmGN1THa5f132gnUA7h2EGFJpwST/2f8DijWPbK/nrUuGH MKGoxJHMwln8qFjc9gC3sAtd5Mk7wGNPKF2uAA2oPd5xzEolAm9rb/2o89o4c24VzH6G 0fnzSoGJUIASBVoVo1JIxr8mhtgXXMVwQz+ss8g6owjXVKGa63Q0UG2KgEN+rVEkqd6i JKa4UvCfrWvHiqrzFZ/oKJJ1UzH3NXLrXfDrY1NIpoZ4ozorCIc16MC7mBs0+JaJ1OIn lojw== 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=4ImMZQ0ldn7Qptx2Gwt/JTveVhM21ZNWByQUZLyeGbY=; b=fsWLdGxc3+xxDJD/OmvxzHSA4dZ70B5vLPGEIigmI+u0lVpLRviwDXvacdoERzJOPX DyyKZBOUcS+kD1pGP4l5h0ZmVzBGEOvVQa54VdQwIL2Iy/jYNbMHXaUemnm/xvxFxxyx qFjlK6ROniIEYihuefdV+zyRBw08PU9wQWtuSNwyJS1m08YaPtVAIzQDzovewCtL5NrK LXKtZWktRsM73BzE04hYB7ayf38xIshUgZQtDwr/zgLhoPbGD0hOMpPXi/VktHRptfYb IHzOqepZSMMZ3T2Q6h3E6CsZdvIlrIFJQzjS3GKmNhnCuDfnPsQRlgDLusg8ST3t6hk3 cxMw== X-Gm-Message-State: AOUpUlGpaw3Ygp5SyCvJZKpi1tQ30JCsWeVCUVhpwBpZVMEz1hCE6iNJ YWqzriDh8HbJ/jjQOe72fujxF3CUu/GaBDpGoboE/A== X-Google-Smtp-Source: AA+uWPxTQaAUrYTKByQZdSEYhxB1T/MDsctf3vE40Uz8bmwYrtX8Mo5Rkq9aqcMsmlwvNtNICiU9fbpnWGSpfMsG04c= X-Received: by 2002:adf:c44c:: with SMTP id a12-v6mr16791988wrg.20.1534352104033; Wed, 15 Aug 2018 09:55:04 -0700 (PDT) MIME-Version: 1.0 References: <153435028609.14458.3744003304771066071.idtracker@ietfa.amsl.com> <041E52A4-E854-4D06-A25D-5C50762DCFCF@icann.org> In-Reply-To: <041E52A4-E854-4D06-A25D-5C50762DCFCF@icann.org> From: Warren Kumari Date: Wed, 15 Aug 2018 12:54:27 -0400 Message-ID: To: Paul Hoffman Cc: The IESG , draft-ietf-doh-dns-over-https@ietf.org, doh-chairs@ietf.org, DoH WG Content-Type: multipart/alternative; boundary="0000000000001f1fad05737c3040" Archived-At: Subject: Re: [Doh] [Ext] Warren Kumari's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 15 Aug 2018 16:55:10 -0000 --0000000000001f1fad05737c3040 Content-Type: text/plain; charset="UTF-8" Woot. Thanks, W On Wed, Aug 15, 2018 at 12:47 PM Paul Hoffman wrote: > On Aug 15, 2018, at 9:24 AM, Warren Kumari wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you -- I've been following this work, and so only have a few minor > > comments at this point... > > > > Section 3. Protocol Requirements > > I really think that this section should remain - it is helpful to people > new to > > the technology to understand how and why design decisions were made. If > you are > > not comfortable with it in the body of the document, perhaps it could be > made > > an Appendix. > > We've now heard this from a bunch of the IETF-wide reviewers. Patrick > pointed out earlier that the WG has seen this section as "will be removed" > during the later part of the WG process, and that it was not meant to limit > future work on DoH. Having said that, making it an appendix with some > wording to not limit future work could be nearly harmless. We'll look at > that. > > > Section 5.1. The HTTP Request > > " In order to maximize cache friendliness, DoH clients using media > formats that > > include DNS ID, such as application/dns-message, SHOULD use a DNS ID of > 0 in > > every DNS request." While this should be obvious, as this document is > talking > > about both DNS and HTTP it would be helpful to clarify **which** cache. > > This was already caught by earlier reviewers. Our working copy now says > which cache is being discussed in a more places, including here. > > > Section 6.1. Cache Interaction > > "This requirement helps assure that none of the RRsets contained in a DNS > > response are served stale from an HTTP cache." The wording of this feels > a > > little "clunky", but I don't really have a suggested fix. I also think > that it > > would be helpful if the "served stale" term could be changed, but this > might > > just be because I think of draft-ietf-dnsop-serve-stale when I see that. > > Based on an earlier comment, we made it clear that this was about > unintentionally serving stale. I agree that "stale" is not really the right > word here; RFC 1035 uses "expired", so we can use it here. > > > General: > > You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure. > > Yes, definitely. > > --Paul Hoffman > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --0000000000001f1fad05737c3040 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Woot.

Thanks,
W

On Wed, Aug 15, 2018 at 12:47 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
=
On Aug 15, 2018, at 9:24 AM, Warren Kumari &= lt;warren@kumari.net= > wrote:
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thank you -- I've been following this work, and so only have a few= minor
> comments at this point...
>
> Section 3. Protocol Requirements
> I really think that this section should remain - it is helpful to peop= le new to
> the technology to understand how and why design decisions were made. I= f you are
> not comfortable with it in the body of the document, perhaps it could = be made
> an Appendix.

We've now heard this from a bunch of the IETF-wide reviewers. Patrick p= ointed out earlier that the WG has seen this section as "will be remov= ed" during the later part of the WG process, and that it was not meant= to limit future work on DoH. Having said that, making it an appendix with = some wording to not limit future work could be nearly harmless. We'll l= ook at that.

> Section 5.1.=C2=A0 The HTTP Request
> " In order to maximize cache friendliness, DoH clients using medi= a formats that
> include DNS ID, such as application/dns-message, SHOULD use a DNS ID o= f 0 in
> every DNS request." While this should be obvious, as this documen= t is talking
> about both DNS and HTTP it would be helpful to clarify **which** cache= .

This was already caught by earlier reviewers. Our working copy now says whi= ch cache is being discussed in a more places, including here.

> Section 6.1.=C2=A0 Cache Interaction
> "This requirement helps assure that none of the RRsets contained = in a DNS
> response are served stale from an HTTP cache." The wording of thi= s feels a
> little "clunky", but I don't really have a suggested fix= . I also think that it
> would be helpful if the "served stale" term could be changed= , but this might
> just be because I think of draft-ietf-dnsop-serve-stale when I see tha= t.

Based on an earlier comment, we made it clear that this was about unintenti= onally serving stale. I agree that "stale" is not really the righ= t word here; RFC 1035 uses "expired", so we can use it here.

> General:
> You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure.=

Yes, definitely.

--Paul Hoffman



--
I don't t= hink the execution is relevant when it was obviously a bad idea in the firs= t place.
This is like putting rabid weasels in your pants, and later exp= ressing regret at having chosen those particular rabid weasels and that pai= r of pants.
=C2=A0 =C2=A0---maf
--0000000000001f1fad05737c3040-- From nobody Wed Aug 15 13:18:15 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 6EA54124BE5; Wed, 15 Aug 2018 13:18:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153436429344.3044.9025081602522286143.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 13:18:13 -0700 Archived-At: Subject: [Doh] Ben Campbell's Yes on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 15 Aug 2018 20:18:13 -0000 Ben Campbell has entered the following ballot position for draft-ietf-doh-dns-over-https-13: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes", but have some minor comments: §4: I'd like to see a bit more clarity on what it means for the URL to be selected based on "configuration". Does this mean "local" configuration? In particular, the client does _not_ select a DoH server based on something in the HTML or JS served by a web server? §5.1: Would it make sense to offer some more explicit guidance on when to choose GET vs POST? I see comments that GET is more cache friendly but that POST might be more efficient. Is there any reasonable guidance on how to apply when making implementation decisions? §6.2, first sentence: That's a slightly odd use of the RECOMMENDED keyword. Does it mean the same thing as "SHOULD NOT" use earlier versions? From nobody Wed Aug 15 17:01: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 53E0E130DE0; Wed, 15 Aug 2018 17:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZeeBcBRHGJG6; Wed, 15 Aug 2018 17:01:30 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0507130DD0; Wed, 15 Aug 2018 17:01:30 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 15 Aug 2018 17:01:29 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Wed, 15 Aug 2018 17:01:29 -0700 From: Paul Hoffman To: Ben Campbell CC: The IESG , "draft-ietf-doh-dns-over-https@ietf.org" , "doh-chairs@ietf.org" , DoH WG Thread-Topic: [Ext] Ben Campbell's Yes on draft-ietf-doh-dns-over-https-13: (with COMMENT) Thread-Index: AQHUNNUZWeukzhmDZ0qmvUjFutF/cKTB9D0A Date: Thu, 16 Aug 2018 00:01:28 +0000 Message-ID: <778CC6E1-BB1B-4E7D-A4C2-289CF4BDAD03@icann.org> References: <153436429344.3044.9025081602522286143.idtracker@ietfa.amsl.com> In-Reply-To: <153436429344.3044.9025081602522286143.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Ben Campbell's Yes on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 16 Aug 2018 00:01:34 -0000 T24gQXVnIDE1LCAyMDE4LCBhdCAxOjE4IFBNLCBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNv bT4gd3JvdGU6DQo+IMKnNDogSSdkIGxpa2UgdG8gc2VlIGEgYml0IG1vcmUgY2xhcml0eSBvbiB3 aGF0IGl0IG1lYW5zIGZvciB0aGUgVVJMIHRvIGJlDQo+IHNlbGVjdGVkIGJhc2VkIG9uICJjb25m aWd1cmF0aW9uIi4gRG9lcyB0aGlzIG1lYW4gImxvY2FsIiBjb25maWd1cmF0aW9uPw0KDQpZZXMs IHRoYXQuIFdlJ2xsIG1ha2UgdGhhdCBjbGVhcmVyLg0KDQo+IEluDQo+IHBhcnRpY3VsYXIsIHRo ZSBjbGllbnQgZG9lcyBfbm90XyBzZWxlY3QgYSBEb0ggc2VydmVyIGJhc2VkIG9uIHNvbWV0aGlu ZyBpbiB0aGUNCj4gSFRNTCBvciBKUyBzZXJ2ZWQgYnkgYSB3ZWIgc2VydmVyPw0KDQpDb3JyZWN0 Lg0KDQo+IMKnNS4xOiBXb3VsZCBpdCBtYWtlIHNlbnNlIHRvIG9mZmVyIHNvbWUgbW9yZSBleHBs aWNpdCBndWlkYW5jZSBvbiB3aGVuIHRvDQo+IGNob29zZSBHRVQgdnMgUE9TVD8gSSBzZWUgY29t bWVudHMgdGhhdCBHRVQgaXMgbW9yZSBjYWNoZSBmcmllbmRseSBidXQgdGhhdA0KPiBQT1NUIG1p Z2h0IGJlIG1vcmUgZWZmaWNpZW50LiBJcyB0aGVyZSBhbnkgcmVhc29uYWJsZSBndWlkYW5jZSBv biBob3cgdG8gYXBwbHkNCj4gd2hlbiBtYWtpbmcgaW1wbGVtZW50YXRpb24gZGVjaXNpb25zPw0K DQpVbmZvcnR1bmF0ZWx5LCBuby4gVGhlIFdHIHdvcmtlZCBsb25nIGFuZCBoYXJkIG9uIHRoaXMg b25lLCBidXQgY29tcGFyaW5nIGFwcGxlcyBhbmQgb3Jhbmd1dGFucyBsZWQgdG8gdGhlIGN1cnJl bnQgd29yZGluZy4NCg0KPiDCpzYuMiwgZmlyc3Qgc2VudGVuY2U6IFRoYXQncyBhIHNsaWdodGx5 IG9kZCB1c2Ugb2YgdGhlIFJFQ09NTUVOREVEIGtleXdvcmQuDQo+IERvZXMgaXQgbWVhbiB0aGUg c2FtZSB0aGluZyBhcyAiU0hPVUxEIE5PVCIgdXNlIGVhcmxpZXIgdmVyc2lvbnM/DQoNCiAgIEhU VFAvMiBbUkZDNzU0MF0gaXMgdGhlIG1pbmltdW0gUkVDT01NRU5ERUQgdmVyc2lvbiBvZiBIVFRQ IGZvciB1c2UNCiAgIHdpdGggRG9ILg0KdnMuDQogICBEb0ggU0hPVUxEIE5PVCBiZSB1c2VkIHdp dGggdmVyc2lvbnMgb2YgSFRUUCBiZWZvcmUgSFRUUC8yDQogICBbUkZDNzU0MF0uDQpRdWl0ZSBm cmFua2x5LCBJIHRoaW5rIG91ciBjdXJyZW50IHdvcmRpbmcgaXMgcmVhZHMgYmV0dGVyLg0KDQot LVBhdWwgSG9mZm1hbg== From nobody Thu Aug 16 00: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 152E51277CC for ; Thu, 16 Aug 2018 00:14:16 -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 (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 3IX8EVc50SWW for ; Thu, 16 Aug 2018 00:14:12 -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 84A5B130EF5 for ; Thu, 16 Aug 2018 00:14:12 -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:From:To:Subject:content-disposition; bh=X5swEYz02CPnjgnMQ+yqdUOro3T3Fg1DeZTqjOEDr94=; b=KmBgmOpUNTrftjWQ1PWBqln/9X p3YGPnSsIqWsdjgyQOV3k2yHk1PC7LcB3jmECwAQcQY3iQIRiEk+s4NkBLuoscRrdivxAEI60fY/b eFtNmnazeGLFw5wcFSFyD3T4lhscPuY5V3PYv29AmYOa5Yqn5fINs0an5pvnwLh+5AsqWU5idFwJP s/1aPdjyemu6HsozHa8OrVH9RUusCSWBKzTZI+skQd/22l3EXFnmPYVjPgkwCTR7cRJuGkqkaCS0n oALGeFFC0bk8aNEbAfKqDRBxx909QDFnBP4bmtQuv3nSyYzwxHbVDQ2cO60DLkBK6GunL5bZSOiGv uAD+qkmZaADrbAzff6M5h+ZObRektQRzgvU6lzxvg7fwianBNcrXq0k6NfWQapRy+ojD6/fiZsxyV zafz894yvFtMHc32x6Mokd+oitQUGe0C1kpxd3HyZZxkwSNJ13VfCd4+7/iER6QmwsmQR7m2pvm9O sbxhL/f12AAfTZPavKqr2hgvOzjDkfCjkCKuEex+UYqaaKIMkUjHJQVLtYNByurJrToaNUBhUpC9A gXLcPC1+HVmwXu+2yt0Bw4cl1eC7NIjCNmwid/yHRn2rFFPpwgauXK1sk6QcT8OD5ty1RqUxVLRiH oD4xwuFf73JxgZ/8YuhlmIQqnswt3RNm7Chtl62qE=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqCTw-0008QU-4v with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 09:14:09 +0200 To: doh@ietf.org References: <153435028609.14458.3744003304771066071.idtracker@ietfa.amsl.com> <041E52A4-E854-4D06-A25D-5C50762DCFCF@icann.org> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Thu, 16 Aug 2018 09:14:07 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] [Ext] Warren Kumari's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 16 Aug 2018 07:14:16 -0000 Am 15.08.2018 um 18:54 schrieb Warren Kumari: > > General: > > You *might* want RFC 8446 instead of 5077, 5246, but I'm not sure. > > Yes, definitely. > > --Paul Hoffman > I recommend to use "RFC 8446", too. Renne From nobody Thu Aug 16 00:26: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 B0B96130EC2 for ; Thu, 16 Aug 2018 00:26:09 -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 (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 c5c2dViwKdhZ for ; Thu, 16 Aug 2018 00:26:08 -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 9DC4D130E74 for ; Thu, 16 Aug 2018 00:26:08 -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:From:To:Subject:content-disposition; bh=pM3Xhe7aeWV7OFxwJiH+BL7+qfA0NkMMd/rICfAepm4=; b=RJvVPrRL9tc8IS9toi9JIeGmlL KRiNg/2WC7IY2AzIUYT3pTEHQwXV6KN0SAc0D4UbIDrcewyHqC4txkuvB1igG9bk1l2RDPz8180WS ormZ50b32DgDsJN/ntWrmdDiMaJVRlf7RzW1VXHhWpBFSpYC+wyk9SMA7NS6x9A+lNnPrinw27Lt5 gIuIb0h01WS07l4SQEvhRo9rr5VvsGgela9CLzJ2HKgYCVfRs/k8MrOAppIT8OGuYW7BEJrVdVxyv Ar5NXXunuw22AbIjqosEppNBU97QwAVMmFe4Zvfa+i3PUoqTR7Jz+49ZX1noF+/NCg8RFSyEL/tg4 GTxlD+ruOc+E7dYHhlP2Wlc6sA6yTGK7p8NISXSzcszo/mSfp9gCbEwQuFHet412i6+FApuCubU2s kWSt1fNaN9NQe+x7QCFLFi6Nkadf7XOdMoe1zzcbgGWB8LptgbfMaILohRa6tVMHXsqif94MVTOW4 09BkndniqV9hJo9ZZ5jv8Ws2291s+pr/hVS5F1e047HxwMbHuG54eOEXos2YfCYLAVOIK5sjKSeVC Da9VVaqMsssikza25OTnvI2cFzPzwxtLDtHiB86uunAWe6/6E8OFlclC1SlXuajp9pwkYpse0aPJo Ldn77NgKdijxvkZMouyb/+2aU+mHNZfimp3RSOno0=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqCfV-0000l8-VM with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 09:26:07 +0200 To: doh@ietf.org References: <153426129189.27071.38667971889611003.idtracker@ietfa.amsl.com> <20180814165606.GD40887@kduck.kaduk.org> <7B076945-C58B-4FBE-B8EC-BD98DDF9015B@vpnc.org> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <3daea335-ebdd-bea2-6f1b-aa63726b2cff@bartschnet.de> Date: Thu, 16 Aug 2018 09:26:05 +0200 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: <7B076945-C58B-4FBE-B8EC-BD98DDF9015B@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] [Ext] Benjamin Kaduk's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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, 16 Aug 2018 07:26:10 -0000 Am 14.08.2018 um 19:00 schrieb Paul Hoffman: > On 14 Aug 2018, at 9:56, Benjamin Kaduk wrote: > >>>> Section 11 >>>> >>>>   The HTTPS channel used by this specification establishes secure two- >>>>   party communication between the DoH client and the DoH server. >>>> >>>> What does "secure" mean? >>> >>> The same thing as the "S" in "TLS". Explaining this again at this point might not bring much understanding to the reader, however. >> >> Could you say something like "due to the confidentiality and integrity >> protection provided by TLS" at the end of the subsequent sentence? > I suggest to use "encrypted" instead of "secure" as DoH lacks reliable authentication (e.g. forged TLS certificates). Renne From nobody Thu Aug 16 00:33: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 7C937130EF5 for ; Thu, 16 Aug 2018 00:33:44 -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 (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 oqfD314_u6vU for ; Thu, 16 Aug 2018 00:33: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 D65DE130EED for ; Thu, 16 Aug 2018 00:33: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:From:To:Subject:content-disposition; bh=T/iJGcCWCAjC0DMzUW7JiKN8iTJ9NvqrynTz5YDQZd0=; b=j611HJNM9XB1wuSk9GZTXZY1Dm Ft4l0i3DEwgOiIP2a012wTdFcBeJ8oYomgamx5Cq4hS9WnNoU4wx7XMbuRd1v1qC695AfItNPVBvp zpdRzxta+DW73IBlODXpSD+Aa/DM5ZsQZo/teVeOilCYPJujNftfOg7p2zUfekWzjAoVB3cI8xtFZ 6i/hi8r1nYtm5jNSKqbUQBzpxIfIwJqj1+cyZ5U4ukCUX/gbljOhQHAENqDx5ef+YAXenTflpWdwv 6ueOxQxrALnS0EDyX+1IfiwOippl9WoFygknhREmWoE/SJG+VqeT7fmNSMablrgiizltPLyQ0q5Eq LHtO3NHzk+w8f3qA8ia2eRkHy1EqhNymUdYmIeNZkeFHc5U3xyvrad1HFHPn7K+E5gGrUARHDOnE7 zBRGANTsqpBgQML2leNq86cJKP9x/8Q9hoU9CBMSsV91FuLOU5XQ95I+rocoidkkxYwCBInd0FWBw Chah5Srz75Zv86NwFmIIo79yLu+1uCHODq0Ko9pRlawc0BRuQPHbY8WxKQkWzfRpJ/YCVBD27xsax qqujSs3vu4FmUgxIysUiYDOI1wfevHRCGoSqBIbBr850AYBeFXOytBIEEFeQKUcxMmaf2PXvL9ZKf 0BHY3tvdzdlov25DD9qt2TrtlgvkyRfHyeCIU6wZ4=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqCmq-00018R-70 with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 09:33:41 +0200 To: doh@ietf.org References: <153417233866.25070.3751592720564238859.idtracker@ietfa.amsl.com> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Thu, 16 Aug 2018 09:33:39 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Doh] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-doh-dns-over-https-13=3A_=28with_COMMENT=29?= 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, 16 Aug 2018 07:33:44 -0000 Am 13.08.2018 um 19:06 schrieb Patrick McManus: > Thanks Mirja. > > On Mon, Aug 13, 2018 at 10:58 AM, Mirja Kühlewind > wrote: > > > One question: > In case DoH doesn't work for some reason, is this supposed to fallback to DNS > over TLS? I guess if the selected host name would allow detection of DNS and > SNI is used, it wouldn't be too hard to block DoH requests....? Is that a > concern? > > > DoH doesn't proscribe any particular path to choosing servers and protocols (even for choosing the DoH server) - each protocol has different properties and particular servers might have properties only the configurer can understand (e.g. trust in the service, not just authentication) in the context of the endpoints it knows about. So whether fallback is suitable is something DoH can only really comment on by describing its properties (encrypted and authenticated transport). I suggest to address downgrade attacks. > > There is no expectation that the same server run DNS service using more than one protocol (i.e. there is no expectation that you use the same host and ratchet down from doh, to dot, to plaintext tcp, to dns.) > > Also one smallish comment: > As already brought up in the TSV-ART review (Thanks Ferando!) I would recommend > to further clarify this sentence in section 5.1: "Using the GET method is > friendlier to many HTTP cache implementations." What does "friendlier" mean...? > Or at least maybe provide a forward reference to sec 6.1 > > > roughly it means more likely to work for a variety of reasons... I'm not sure delving into those reasons really is helpful to the DoH reader - the important property is that HTTP caching works-well with GET and not-so-well with POST. Is friendly a bad word for that? its commonly used in the http and application space around caching afaict. > I suggest something like "better caching performance". Renne From nobody Thu Aug 16 00:44: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 E64C4130EF7 for ; Thu, 16 Aug 2018 00:44:34 -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 (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 3_t_JvBwfT7B for ; Thu, 16 Aug 2018 00:44:31 -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 E07ED130E7E for ; Thu, 16 Aug 2018 00:44:30 -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:From:To:Subject:content-disposition; bh=M9ks4aKqPtSJ8x2VMoNj3YlZWgPLNCTkrQAtwYt1bsA=; b=Sg4r9og/fiiylwCdu9A/nru0d9 nMroRgb2+/WeSaGULMkb1DzeF413+8JZkOktTHRYPFA0+wPADMaRXFZETQeahvyOg0yoYSAEiE7GX Ex771gzSHkESjVz2Xbo1nln9kYBC8jF7fvKZ3EI6Wj0jBPwEZa0PLuOBBheMfYTQetd79G2YTIFbp 5NDfFTZTtJ/+UsIDFCb01129aX1U9sv29ulLiBrwb7V5OZllSxufHwgvIbnH4f1gYvnEf6pRIP/xz P70XCN9tlRivhHI8thdY86Dh7UMFnOYdnbci/8tckhqr7s9OGtJzcxWH4VnCM4DxEjYZzdpYU5BT4 XqetAoVN3SGnmntviAi2O5tQ1OUqb2yz1t98blup93upuYtFYnTDg17lC3XHi26KQVYP83IoRf1L6 gjqdDluMAUna7veMeNYV2ErFxUtIanUZYWMyesjlFYM7RnsYDuCtJU+V9g/VSEDXuIlHXxxZM6w9H 5HZNe3HQ1UwbKMceTMQgoya/eZOCJyDGPAY0ckKjkYiTQbqwrNRCJraM0kGqvOr3IHfY25Gp2qTPP iFHmuFEpbiLjruzyQldhzQevJ0H8w71uDEBAkZZtzRhPl+QKlP+1z6wPcDi4FPYyE/mxBplCt+hfD Zdr6ItkQFuvHI7MyB/Ylpz++d0pvRj4tjL3fUKOPs=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqCxH-0001oF-WC with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 09:44:29 +0200 To: doh@ietf.org References: <153397442482.20828.13036371457377811227@ietfa.amsl.com> <508cc0f8-4826-ac8c-f52f-704a02f0bb9a@si6networks.com> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: Date: Thu, 16 Aug 2018 09:44:26 +0200 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: <508cc0f8-4826-ac8c-f52f-704a02f0bb9a@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Tsvart last call review of draft-ietf-doh-dns-over-https-13 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, 16 Aug 2018 07:44:35 -0000 Am 12.08.2018 um 01:34 schrieb Fernando Gont: > Hello, > > Thanks for the response. Inline.... > > On 08/12/2018 12:58 AM, Star Brilliant wrote: >>> * Page 15: >>>> It is the choice of a client to either >>>> perform full DNSSEC validation of answers or to trust the DoH server >>>> to do DNSSEC validation and inspect the AD (Authentic Data) bit in >>>> the returned message to determine whether an answer was authentic or >>>> not. >>> >>> Relying on the DoH server for DNSsec validation does not seem like a good idea. >>> You want DNSsec to be end-to-end. >> >> We discussed about this paragraph before. The problem depends on how you deploy DoH services. >> >> 1) For most people's needs, the users grab a list of DoH servers from the Internet and configure their systems to use the DoH servers. These public servers are untrustworthy. So the users need to validate DNSSEC at their end. > > This is the scenario I was assuming, for which it seemed a bad idea to > ahve the DOH server do DNSsec validation. Anyway to clarify this so that > others do't fall into the same assumption? I suggest to add something like "the AD-bit MUST NOT be used if the upstream resolver is not under control of the client operator" (please, find some better wording). Renne From nobody Thu Aug 16 01:13: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 C3933130EBF for ; Thu, 16 Aug 2018 01:13:26 -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 (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 ECS0FNQZdrIv for ; Thu, 16 Aug 2018 01:13:24 -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 32293130EB2 for ; Thu, 16 Aug 2018 01:13:24 -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=w9MXp0VmoNGQODFsgZrXzH8w2ctVtVlpKmFm3uFB36o=; b=lpqzxGJ3dphPntiMxM/sP0dZXV JjffBgmJdTTG1mv5dywNmXg8bPxyx7B4V/tQ/bwQgmQA5//8rYuKGiUlfK0NB9rpBwDb+hW0HsHbo IQFpv+ptjiUaIT/8nbKx89OoETJ3+KSE0eVtwOqzbja6thjzFBikQRuGNxfjEALoQUTKlYHUFeD7J eJT1wi9GzPwC+IL8+reXNFngdOXYEj3khJT750duACGwALZJ9iqROVFYjOPDsYl1Fo3175VNHoggL 1ryksHGp+rJnWGY05HXdYnwyJdMh91eIdrpHq1mjZmYXiHEjqpvR+geZH3VE0k6b9AJTv65kKXHOz m21lHTKj4gejnbyx9QwMxxvH2LCIbssVR40xO4HoQDU5kdRUxGN9Hu7lN3Ak3RjJOsfAH6fhIjz9I rk20a1OhYogGFDGs+c17kZGMc8ZUueZBecHbq4sVNV3mj9F2tmNyJgf+I1ugJDGaSX0nFid+eh0uo Sz1yZYNi3ZIETg9DLw3XSJptVrASkVPHnb7p+dm1Ns60m2G7ryfboSgNRX6iBD1JOKIv02rZxCOcM jZc+fBUBN6ePhi6ohZ5b5HQD7cvtREW9p93fnADr2zObARsz95ASosW49JxLQR4hgpmBQ2IKlKzwJ yDUfP6lJFTshbs+UwEtBFsIuQ1Dgr/9aZazasvIwg=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqDPF-0003ZO-Ep with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 10:13:22 +0200 To: doh@ietf.org From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> Date: Thu, 16 Aug 2018 10:13:20 +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: en-US-large Content-Transfer-Encoding: 7bit Archived-At: Subject: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 08:13:27 -0000 Hi, as TLS-certificates forged or obtained by devious means have become common in MITM-attacks by intelligence and criminals I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security considerations). Renne From nobody Thu Aug 16 02:01: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 DFF73130EF8 for ; Thu, 16 Aug 2018 02:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 x5Rs3DW0Y2dS for ; Thu, 16 Aug 2018 02:01:52 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000037.outbound.protection.outlook.com [40.92.0.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB44130EE2 for ; Thu, 16 Aug 2018 02:01:49 -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=vqXJ9mR5mloJwuroW5qAhwL4aiV1ClLvvz/VEvW41bk=; b=mFjyEFtZK+5VUqq3urtgAJ0LlbQ9vMEPf5KypO/aLSXdKgV+5jv6ETSXcDjg/+RUEITLWholZ4EQcYWeBIHV3vzeUyf3rv7ZfZq+/mcxNl3uoAHWQgw7V9A2n/QruHgJVqXpRFQnVSzSbhdu7gHLGrCfI+Cq5US6fdDsAqZt9vE2ajoHxnd6cLiWvcMTl3StpPW4cThfuMgv2QsC0cMa4X1MllfjSk26mRgwVNED5IL/aivc+qkWm6YJB8ic1an1J2Fwu7vjeNXFhhTYexE2vQBzWh87RTupQzhluWbHiRgF4Cgq0VIrwpz3xV6JgapE/HOUtuMekRya3OqPZLOjIQ== Received: from BN3NAM01FT060.eop-nam01.prod.protection.outlook.com (10.152.66.58) by BN3NAM01HT032.eop-nam01.prod.protection.outlook.com (10.152.66.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14; Thu, 16 Aug 2018 09:01:47 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.66.54) by BN3NAM01FT060.mail.protection.outlook.com (10.152.66.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1059.14 via Frontend Transport; Thu, 16 Aug 2018 09:01:47 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1%3]) with mapi id 15.20.1059.017; Thu, 16 Aug 2018 09:01:47 +0000 From: Star Brilliant To: "doh@ietf.org" CC: "Rene 'Renne' Bartsch, B.Sc. Informatics" Thread-Topic: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate Thread-Index: AQHUNTkH7tX1FPWMfkWU1/q7LTu0kKTCFPPE Date: Thu, 16 Aug 2018 09:01:47 +0000 Message-ID: References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> In-Reply-To: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:51EF87A56E991E3929FB255772E3001527B8763372726B7B0C3F3A8C0C506AEC; UpperCasedChecksum:87846B3674BD7C6304FCDA5410C79C66C79E692E20001BECA60C0D36DD55E29E; SizeAsReceived:7218; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [wVbW/fUAdNh2RyoOr+uPVlwvvGcoZCjH] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT032; 6:1g96h1N2auTsu6L+i6Ifq9Q7dUTp7cswZQ3T6tqyl6Y7C6aMWzHuKG+0MINtSf6wwvl8sDmNOMXyv7m/sHb1U3oUFcz6EDgzsLgZqZk6TfeIJKVut+LfP4Axx5LT1ZFaIDxPUXZCzOFLIK0W/l7DVa4f3naSxvD2o9m7CPiqipFimdWqMe9lBNetyv4puMkJagAVQM8yglXmuNl/uGxVReOIAhFazChdmQKLX5vLCNu5KEtlp/DpF87TTg8gD65uzcaGbxnw48jL7TjgzczuCKdIXmMPn9aHZV+7nd133xjp3001zjQwW6fWAG3vrjJk4HESt0SEkBA8Q0ZimVxty7bXH2hyMcl/pKAjK2TBVHagvckElYdHTNTYunFTyqR3g6WiH5nlFApBupSsL92YhvBJ4Zcb8hfNg8TKFM5QoWso6lMWP9Au060f+Xrqo1mX7Fqdd49vCALuh9RBTCsFcA==; 5:RlWFLYYJ+3nK997R96N+1S2nRqD3HCu1UhioZ9ZDH+d75jLnWftp1WvkJudMtxAbL3VIWk+bF4TQ+CrD4wkifJY87j0sSJ9dKitoV0TnCDd4qb1+AR0s+Sa6QSRnFU2OsTl+k6PsoBs/tw1/yZVAZgY+5JaYqGqYitFBlspGwNs=; 7:bede+8oGs3Qg4S3pfXyqPWO9qP8TXyYj5Oim7K8EBWxhR3cJSEQSRazSvJpc1ARQ1pwWTuhbZoaVqk2XxenHev13uwrxUza1YUn+x4L7MMFtwcR0U+Gcmk+Vx2ZMTKkJIuQnSiNv78q2Nnj4toMOSvewunI+g8cQ+odMnfef9ItdNVd1WaBn1ddTagRuqhjTiC0fnz23LPdqPmwtJ2rcWuksHkr5M+IydIZzKFlpVdl0Eungih0YBpM6qk1FS9gY x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:BN3NAM01HT032; x-ms-traffictypediagnostic: BN3NAM01HT032: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:BN3NAM01HT032; BCL:0; PCL:0; RULEID:; SRVR:BN3NAM01HT032; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(104016004)(6346003)(5640700003)(20460500001)(9686003)(26005)(53546011)(102836004)(229853002)(6436002)(6506007)(55016002)(2351001)(99286004)(2501003)(74316002)(305945005)(7696005)(81156014)(1730700003)(8676002)(83332001)(82202002)(73972006)(5250100002)(76176011)(476003)(4326008)(8936002)(86362001)(106356001)(87572001)(5660300001)(6916009)(105586002)(68736007)(25786009)(446003)(11346002)(6246003)(97736004)(486006)(14444005)(2900100001)(14454004)(256004)(56003)(33656002)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT032; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: y+vxI/JpDMhsg/26xOslHM0EZSjRTEjYqmWQmC4IJJNC/NqLSrTyKz3Ha9ZpX8pcBLutnb0Dxkoehjvx8p3ksC5GNMXfVCklWyjQ5JufoNL3/uCVCV1KMeJEEzNXYbW2HYGpYR/+yQk/uLWktuxgbWx+DM+2rQBiE1SjO2bvoZJmtEirCC0SOib0jEMbojZ+MoPfOKX3l+skJ4t0E0okQLnO7JOZ4xRTngB69Npd4Wc= 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: 6af5060a-9aab-4304-d70d-08d60356e5d9 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 09:01:47.3927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT032 Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 09:01:54 -0000 On Thu, Aug 16, 2018 at 6:13 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > > Hi, > > as TLS-certificates forged or obtained by devious means have become commo= n in MITM-attacks by intelligence and criminals > I suggest to RECOMMEND authentication of the DoH-server TLS-certificate v= ia DANE-TLS (RFC 6698) in section 10 (Security considerations). Hi Renne, I am sorry I could not get your point. How could it be possible to forge TLS certificates without being detected t= hrough our current PKI systems? But I agree that we need OCSP-Stapling indeed to prevent a recursive bootst= rapping problem.= From nobody Thu Aug 16 02:09: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 4482F130EEF for ; Thu, 16 Aug 2018 02:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 ZuL64NeebfdS for ; Thu, 16 Aug 2018 02:09:54 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-oln040092002087.outbound.protection.outlook.com [40.92.2.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8164B130E6A for ; Thu, 16 Aug 2018 02:09:54 -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=J7oX6Ht3XN6TIEWZWGKV8/DSs91XMnUsl/6vTPsP/4c=; b=GGdvX2NxA64RHO0nlcwONEKEsM4OXF8yb5jW1gsizhYMtMe7pC0ATj6CxNhaQ/K27w9KxAvR9Ue+FwLHmgVyEtpzLyVTENdUDK4EGCCc0rARQIdHkKA3L8XuGOVddhKWuWv04hoZ1Bxa0d/S2mwD3/6ADdNrvEEuZk7LnkOQQ68bou2wiU0gyMSguHPPY90Nw6FA3wDg5kMm1HotN0d0Ax2tYssNq6RnRM+o28LQNF/e4PHOAP7kM0gsvHuxApQRAmSC/ZptbDRFjio0DRdMvzS/OYyzE4uFz5Fz0/DKYWk9DYUOI+b8kd0oIrT65JWG8JuwVNLbD+FMs0hKU4ngUQ== Received: from SN1NAM01FT026.eop-nam01.prod.protection.outlook.com (10.152.64.56) by SN1NAM01HT021.eop-nam01.prod.protection.outlook.com (10.152.64.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1059.14; Thu, 16 Aug 2018 09:09:53 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.64.59) by SN1NAM01FT026.mail.protection.outlook.com (10.152.65.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1059.14 via Frontend Transport; Thu, 16 Aug 2018 09:09:53 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1%3]) with mapi id 15.20.1059.017; Thu, 16 Aug 2018 09:09:53 +0000 From: Star Brilliant To: "doh@ietf.org" CC: "Rene 'Renne' Bartsch, B.Sc. Informatics" Thread-Topic: =?iso-8859-1?Q?[Doh]__Mirja_K=FChlewind's_No_Objection_on_draft-ietf-doh-?= =?iso-8859-1?Q?dns-over-https-13:_(with_COMMENT)?= Thread-Index: AQHUMygHfuKJslyntkuBLED3NTNkeqTCAJWAgAAan9A= Date: Thu, 16 Aug 2018 09:09:53 +0000 Message-ID: References: <153417233866.25070.3751592720564238859.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:4A055B1A43FFF5A6454138173E6609EF5D9E37EAC52A265CED1C09FE95C6B051; UpperCasedChecksum:A12C10B3CFA18D8DEA54E539B39A614832A914132B9F68BB5C26EBA6FBAB8CD9; SizeAsReceived:7397; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [B2VIrD6pNhDxrEjJAJ/2ACxMfBqMmzw6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM01HT021; 6:JLLXl8E4H43xBXwdKV2bBB6Zv6OlL7970Thn5N7cXvdwGnNK1/Fjph0p+RY6+5TC2za3L210rDMngEu82u4oOiB6RBiCYSkpO1hNZniX8whmLTJPoiQ7zL5hSGfArS+FlZaGpFtZBtA8Onxg1PQJs4DNihyRWxUvlu4c1ejJ8TqqUmM7lyhW8Wdyk/KKs93NIBRLWeGETnI1pwyEeks51wnzwguIwdE/yMGcW+lZlpiw11nf6NQq6SgqZy24wrZ+nDIQaNo135dVahi8VueRRdt1I3EIXgaMgUYlw8tWndYu3SnBiWgUUFAwug774L1vRZSxi37vp5oQIX32Y5iyMYHCAwe7jlCQVZfYQLmhYOpXir4ltCyWRUDSU6zpATFcZ5WBIb+cVk24JGcoMPJcfwOc0d0oYw821Xqv2WkcM0ZwEJzJKzj8zQ4/+EV4NdD0WbQ6++WAuiJun+UebIfGcw==; 5:EH7XOtrPY9wDCgVT9sWH6kgPNdMq54NJTW7HPDxYDfxxwTFOs8GSmTgyZ8vVhB0OuWwjeCMEK0fMLuwSKF1bFs1H4RZOgMC50+/h9yTU3IEitnV9HvDCwyCvgA9zm1HNBi79Uh2udpEWqfs0xphgpnKyvy6MVoKteHo0GZ8o4qI=; 7:4phPECy9VwoR7HYDOQ0l/DoHr9YrMl02HmrREfKrkYRrs5pOOdpW01+WvxZYxCVxKfaGCld+NPiSkbtvmrVN7tp2cL10v5pkf75nK8W0uEDC4aQ/4PuAMs1TYr589CWOelRtdSx/bIx6Bcuif+cTQXJqyXkPU3aFsq2hMKgXrr+Tfn5EHZVoRh//Nz72VnhdSDaUhP6g3tw4mkV74aUTpoVkRzZyWhZGSMhQByzO2wBooAMjKOgLkPB2/qbD7BuF x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:SN1NAM01HT021; x-ms-traffictypediagnostic: SN1NAM01HT021: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM01HT021; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT021; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(224313004)(87572001)(224303003)(106356001)(105586002)(2900100001)(14444005)(68736007)(256004)(102836004)(26005)(86362001)(6346003)(83332001)(476003)(56003)(2351001)(14454004)(486006)(33656002)(8936002)(73972006)(446003)(11346002)(6916009)(82202002)(5660300001)(97736004)(99286004)(25786009)(4326008)(104016004)(7696005)(305945005)(74316002)(81156014)(76176011)(53546011)(6506007)(5640700003)(1730700003)(20460500001)(9686003)(55016002)(6436002)(5250100002)(229853002)(2501003)(6246003)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM01HT021; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: Nh8Y4ATrtvhZSgf5DrF6RvFq+AoZ9CT54Tf8dImQZX7LqESwh0FmmNOe8PbdnZRGgruTs1IZc0rsSRsLXVOtNK13EYj3fROpti/tPU1hqMHrSy4+3uIqw9BRu788qoME8l/gB88Ij8cPn4fW7ji4EgvWXPM4BAQvQdTDLVxt4c2ABUbsprb3C3QSnHXV7nXjJwftZgFuQnlMmU5wW8PS74gNLvYbs+Xgom1Enm2OBok= 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: 85e43da5-d946-408d-bbc2-08d603580743 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 09:09:53.2607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT021 Archived-At: Subject: Re: [Doh] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-doh-dns-over-https-13=3A_=28with_COMMENT=29?= 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, 16 Aug 2018 09:09:56 -0000 On Thu, Aug 16, 2018 at 5:33 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > > Am 13.08.2018 um 19:06 schrieb Patrick McManus: > > Thanks Mirja. > > > > On Mon, Aug 13, 2018 at 10:58 AM, Mirja K=FChlewind > wrote: > > > > > > One question: > > In case DoH doesn't work for some reason, is this supposed to fallb= ack to DNS > > over TLS? I guess if the selected host name would allow detection o= f DNS and > > SNI is used, it wouldn't be too hard to block DoH requests....? Is = that a > > concern? > > > > > > DoH doesn't proscribe any particular path to choosing servers and proto= cols (even for choosing the DoH server) - each protocol has different prope= rties and particular servers might have properties only the configurer can = understand (e.g. trust in the service, not just authentication) in the cont= ext of the endpoints it knows about. So whether fallback is suitable is som= ething DoH can only really comment on by describing its properties (encrypt= ed and authenticated transport). > > I suggest to address downgrade attacks. > > > > > There is no expectation that the same server run DNS service using more= than one protocol (i.e. there is no expectation that you use the same host= and ratchet down from doh, to dot, to plaintext tcp, to dns.) > > > > Also one smallish comment: > > As already brought up in the TSV-ART review (Thanks Ferando!) I wou= ld recommend > > to further clarify this sentence in section 5.1: "Using the GET met= hod is > > friendlier to many HTTP cache implementations." What does "friendli= er" mean...? > > Or at least maybe provide a forward reference to sec 6.1 > > > > > > roughly it means more likely to work for a variety of reasons... I'm no= t sure delving into those reasons really is helpful to the DoH reader - the= important property is that HTTP caching works-well with GET and not-so-wel= l with POST. Is friendly a bad word for that? its commonly used in the http= and application space around caching afaict. > > > > I suggest something like "better caching performance". > Agree. Here are my personal opinions: GET: - Better caching POST: - No base64 overhead? (We have gzip so they are same) - Not logged by default? (An evil server operator can deploy logging at bot= h DNS level and HTTP level) - Support longer requests than GET. Usually I personally prefer GET unless the URL is potentially longer than 2= 048 bytes. Because I could not come up with any more benefits of using POST= .= From nobody Thu Aug 16 02:15: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 C27D6130E6A for ; Thu, 16 Aug 2018 02:15:46 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net 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 Tp_gx2wuf-aP for ; Thu, 16 Aug 2018 02:15:46 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85E7130D7A for ; Thu, 16 Aug 2018 02:15:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=LvNBmOP2/G2P5WN+zC2E4oy5FsGTwRrfrjdXlRH3ybJ9C+e/1L9j7obJcHwyQPJ2CnezvSxSClJ91yCl+eMfgadWDdCg7EQVoWbUachJwLUElhRJ22P5j26oZqMJxawbq7ApWkbEXyWhKZzUeTaFB8uQetiAozda79+EIqV01TA=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 30944 invoked from network); 16 Aug 2018 11:09:02 +0200 Received: from mue-88-130-61-168.dsl.tropolys.de (HELO ?192.168.178.24?) (88.130.61.168) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 16 Aug 2018 11:09:02 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Thu, 16 Aug 2018 11:09:01 +0200 Cc: Benjamin Schwartz , draft-ietf-doh-dns-over-https@ietf.org, DoH WG , The IESG , doh-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4FB2E0CA-CB88-4600-9931-562FC5C5F1A6@kuehlewind.net> References: <153417233866.25070.3751592720564238859.idtracker@ietfa.amsl.com> To: Patrick McManus X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180816090902.30935.65931@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [Doh] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-doh-dns-over-https-13=3A_=28with_COMMENT=29?= 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, 16 Aug 2018 09:15:47 -0000 Hi Patrick, > Am 13.08.2018 um 19:06 schrieb Patrick McManus : >=20 > Thanks Mirja. >=20 > On Mon, Aug 13, 2018 at 10:58 AM, Mirja K=C3=BChlewind = wrote: >=20 > One question: > In case DoH doesn't work for some reason, is this supposed to fallback = to DNS > over TLS? I guess if the selected host name would allow detection of = DNS and > SNI is used, it wouldn't be too hard to block DoH requests....? Is = that a > concern? >=20 >=20 > DoH doesn't proscribe any particular path to choosing servers and = protocols (even for choosing the DoH server) - each protocol has = different properties and particular servers might have properties only = the configurer can understand (e.g. trust in the service, not just = authentication) in the context of the endpoints it knows about. So = whether fallback is suitable is something DoH can only really comment on = by describing its properties (encrypted and authenticated transport). >=20 > There is no expectation that the same server run DNS service using = more than one protocol (i.e. there is no expectation that you use the = same host and ratchet down from doh, to dot, to plaintext tcp, to dns.) Okay thanks for the explanation. I guess it is somewhere =E2=80=9Ehidden=E2= =80=9C in doc that DoH-only servers might be a likely deployment = scenario. Is that something worth mention explicitly? >=20 > =20 > Also one smallish comment: > As already brought up in the TSV-ART review (Thanks Ferando!) I would = recommend > to further clarify this sentence in section 5.1: "Using the GET method = is > friendlier to many HTTP cache implementations." What does "friendlier" = mean...? > Or at least maybe provide a forward reference to sec 6.1 >=20 > roughly it means more likely to work for a variety of reasons... I'm = not sure delving into those reasons really is helpful to the DoH reader = - the important property is that HTTP caching works-well with GET and = not-so-well with POST. Is friendly a bad word for that? its commonly = used in the http and application space around caching afaict. For me =E2=80=9Efriendly=E2=80=9C was just kind of a meaningless word in = this context (and I respectively wasn=E2=80=99t aware that this word is = commonly used). I don=E2=80=99t think you need to give any reasons but = maybe it=E2=80=99s simply more clear to say =E2=80=9EGET is more likely = to be supported by many HTTP caches=E2=80=9C? Mirja >=20 > -P >=20 >=20 >=20 > =20 From nobody Thu Aug 16 02:37: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 1ED69129619 for ; Thu, 16 Aug 2018 02:37: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 (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 JklUmWXbWylV for ; Thu, 16 Aug 2018 02:37:07 -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 DA4C41286E3 for ; Thu, 16 Aug 2018 02:37:06 -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:From:To:Subject:content-disposition; bh=eNouvmqxKtbCIPfJ1QdQKMx0Tt6DOsvXCxeDmMTQeGw=; b=X7207cK/yZizvMYr/PIxE3r+C2 kfg2uV7/b/hkF2V2Vb4R/ayXFOWqLEf+ntucTwTGLL2FMM6QSMxks5n8vAfC9ut7OsWwxSOAheCAJ xLyZH6j5b91ynOiGhpU1LkbPB8uxS8lgk6/JMBfbNrwaegmJNx6bS3gizd3TH/rxFx/9Wmq90LqmY gOP0sPiizzgR23a8fct7myxrz3On+/BETjmRQSt9HRiDLKAK7DaA4ibtLC7GVlqslqEqPmVLxFUs0 OVjWC+9LZ3STji2M3Y13UKFTRq13Jm9Wzofc1X5awB1p6vUvSQi2An73WrAJ+AXYiQ0QCOckIev+U 9I9bS//rjxc2qaVe4t52FF7U9i+2uWWUhlo8C72AEqqXz9N8cLvpunuqe/tUoinSGzi11JvGxFfQY uSU1Zwcte81TsP/zgOIZe4zDEfo1Wa41Hf8KQnHVciC8/TkTZXjVlXeMcOF1WmFjQOutA3zHFvER2 pF1S/XOUXnUnQQd8lDI2/PtNhdxobbcEldE6Uovd4ghFjUO3FYvolkfET6rJtA4w7xcNQDZPkgK9q EaoClLNU2II0HWDh9hhd40qq5GP4+vnApj/UzCFnHHtRG++h3440DlIU5trkLMsTTbwYuLD2j2E7J /22cV7wMwOcPnyNjs1GAVPOkQeLTMBvGwNDHqBceY=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqEiF-0008Jm-8V with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 11:37:05 +0200 To: doh@ietf.org References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <74018a91-eecb-bb35-d5c4-e72487a0719a@bartschnet.de> Date: Thu, 16 Aug 2018 11:37:01 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 09:37:10 -0000 Am 16.08.2018 um 11:01 schrieb Star Brilliant: > On Thu, Aug 16, 2018 at 6:13 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >> >> Hi, >> >> as TLS-certificates forged or obtained by devious means have become common in MITM-attacks by intelligence and criminals >> I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security considerations). > > Hi Renne, > > I am sorry I could not get your point. > > How could it be possible to forge TLS certificates without being detected through our current PKI systems? - Stolen CA keys/hacked CA (https://en.wikipedia.org/wiki/DigiNotar -> Issuance of fraudulent certificates) - Malicious CA - CA forced by malicious law - Abuse of intermediate certificates (https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html) - Fraudulent certificate requests - Broken revocation system (https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3) What if the client doesn't get the CRL/OCSP informtation? Bottom line: Don't trust a CA. Renne From nobody Thu Aug 16 03:10: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 E797D130E7E for ; Thu, 16 Aug 2018 03:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 7WeLqpUKCC1O for ; Thu, 16 Aug 2018 03:10:28 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-oln040092011040.outbound.protection.outlook.com [40.92.11.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C776112D7F8 for ; Thu, 16 Aug 2018 03:10:28 -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=dhnhdsKgb+zUsB8MwC3Uc7zk5XRJsK0/goYFf/Mq1Ok=; b=a8ns7ftMPkrFYQu5wzlteM1KDgA+jQKMFiSsLF9fHMy9AR1b2xGTfi2ZOJ4GrockXyIgdRd2t6Khpd+RnuM9AS/lANK024VOD0yG4mBP017FStreLOxo2TIIDA4/HfyalDEx/Ga0zmSVFpVCuphBXneToTeE20l7PIc2o3EjdHTQc2MTmRXBFo5Fc2Bpp7V3NzqNHhW0Dg10Je9BF/RYI9mb5FEVA4nbOQhiMpCPPnNlF0yBGVMjWjZvroA0MA3Z/OLj4haJ512bQ2ISBdfDR/ajLEdYiDpY+rwhbNpqaMp/WVyMZ60MgCVsy51mKbkvso6WpOfbmK1rx8yBgrTDVg== Received: from SN1NAM04FT062.eop-NAM04.prod.protection.outlook.com (10.152.88.52) by SN1NAM04HT129.eop-NAM04.prod.protection.outlook.com (10.152.88.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14; Thu, 16 Aug 2018 10:10:27 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.88.55) by SN1NAM04FT062.mail.protection.outlook.com (10.152.89.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.14 via Frontend Transport; Thu, 16 Aug 2018 10:10:27 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1%3]) with mapi id 15.20.1059.017; Thu, 16 Aug 2018 10:10:27 +0000 From: Star Brilliant To: "doh@ietf.org" CC: "Rene 'Renne' Bartsch, B.Sc. Informatics" Thread-Topic: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate Thread-Index: AQHUNTkH7tX1FPWMfkWU1/q7LTu0kKTCFPPEgAAJ+ICAAAkvLw== Date: Thu, 16 Aug 2018 10:10:27 +0000 Message-ID: References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> , <74018a91-eecb-bb35-d5c4-e72487a0719a@bartschnet.de> In-Reply-To: <74018a91-eecb-bb35-d5c4-e72487a0719a@bartschnet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:5FCDCA98F1E3241937BD406351113633325F5193E04D1F6F62825C685DF530C8; UpperCasedChecksum:8244B64C0DB8237AECF13BDAE868685A135933D8B87EAE4E67BB70896A22B4B2; SizeAsReceived:7363; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [yvtPZDOKaAvfl4khrr1IK0/SIQ3MyeNR] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT129; 6:FBYWa205AnlocKlp5QxbCLHdtIoWpWBc2GLYFFa9+zfm9DIEEbdO5E2ldxq1CmBvSMo53aBDxUQv5flmb7VAaogZ+ZV0yxxGgowCDlJyer8rmuxbTE9hcmvWdLGr4pQYt0qk3M2npGyducrw/HKqrHnQqMtD82Bt39b2ZA8jLv+ZFJG0S4VSoWPCCTDwfkEb0Zq58LsAP1d2Z2S7X3ySH+lO24jed2ToKhAot4bJIdfZnMyQfcxQiiGym/cq8HhJr6ryirtRIhFATiLo4dKC1jqyMRKTbP7eMYpQH10uY4Gpn5Z0epXIvaavVNlZkG8L0/HsPh7k+3S8z9oY5jPU5ebBmvPYbB9khVZ63PCnXz1RS9FCmTyk8WqTHUXCtRyf2C6lrQP8m/Y+wKb+M1Xt36W7pzf3mpKK2sgH1186GbcSQHd4DiwtG0RezBKcOdYdl4cwnFoy11GH9YIm39ryaA==; 5:7QNWyigoUGRN2+ANF/tyH7L+dTRTvWd/ZqdUUzzBMMWYXEeh0c3HkZYT1N1W5beOIwCd5TMQ7XMQ9xYnFVDEaSrqj8VDyYo67mpFJqgkDYqH+zi+wk8kmXEieBcs+iM0+PcbOA93lFAPkB9q1XaEPqh+oLDLQ4Cobgp2g6U11ys=; 7:iplad5bBeLhh9Fo7at1zfyk0X8mhnKnXBvE84C+MfZlfNz14i2GUvf7WeSLsbipx3Fko/9grTjGg9we8hvmK9x9bWG+ppvrrbwoMS4EyFO553cawphU4tkvCH/Ysjbdfqvzr/W5sEqb6Ja8UMbhE7NFeaPYv9DAt1GaViIJTREuUF8A/rRWvKZlKh5/bVtPK63InOM70t1QA8Gw74fIBX+MsS6L8a4qAfuuDe1qkYENOZKMUulI8F+PRGBAyGEal x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:SN1NAM04HT129; x-ms-traffictypediagnostic: SN1NAM04HT129: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM04HT129; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT129; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(486006)(4326008)(87572001)(6306002)(5640700003)(26005)(33656002)(6436002)(446003)(104016004)(11346002)(476003)(6346003)(97736004)(6246003)(73972006)(6506007)(99286004)(25786009)(102836004)(9686003)(55016002)(2501003)(53546011)(106356001)(105586002)(8676002)(2351001)(74316002)(76176011)(5250100002)(81156014)(1730700003)(2900100001)(86362001)(305945005)(20460500001)(7696005)(229853002)(68736007)(8936002)(14444005)(14454004)(56003)(6916009)(82202002)(256004)(83332001)(5660300001)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT129; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: rJJ4koMNF03NEBphQfmaMORGbCwMHY7xo93sKWqrSKuswQpEq1sR/wjQT3CY1oUns20yTyGFlSwQoo5wSeik9A9oOsMIX+uR6qjDFGe1MkJBYDaRqHnoQPsz+GjK2jUOa3u4ObpW1VwmdkfJAG4mQ2UfADvOSjhiWpVWF3pF7vAKYo2hhH1ql7tGEAq4U/JvvrFux/ggbsFHxDZRtwCoYsqGL5Sg0fNei19ZM8CpRUw= 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: 523a566a-1f7f-45bf-0a70-08d603607d53 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 10:10:27.3373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT129 Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 10:10:31 -0000 On Thu, Aug 16, 2018 at 7:37 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > > Am 16.08.2018 um 11:01 schrieb Star Brilliant: > > On Thu, Aug 16, 2018 at 6:13 PM Rene 'Renne' Bartsch, B.Sc. Informatics= wrote: > >> > >> Hi, > >> > >> as TLS-certificates forged or obtained by devious means have become co= mmon in MITM-attacks by intelligence and criminals > >> I suggest to RECOMMEND authentication of the DoH-server TLS-certificat= e via DANE-TLS (RFC 6698) in section 10 (Security considerations). > > > > Hi Renne, > > > > I am sorry I could not get your point. > > > > How could it be possible to forge TLS certificates without being detect= ed through our current PKI systems? The security level is the same with either PKI and DANE. Let me explain. > - Stolen CA keys/hacked CA (https://en.wikipedia.org/wiki/DigiNotar -> Is= suance of fraudulent certificates) Stolen/hacked KSK and ZSK. And currently it is nearly impossible to revoke and rotate the root-anchor = key in case anything bad happens. > - Malicious CA Malicious domain registrar that modifies NS records combined with GeoDNS to= prevent being detected. > - CA forced by malicious law We have certificate transparency records and CAA records to protect them. But nothing similar in DANE world. > - Abuse of intermediate certificates (https://security.googleblog.com/201= 7/09/chromes-plan-to-distrust-symantec.html) Yes it is detected! (I said "... forge TLS certificates without being detected ...") > - Fraudulent certificate requests I could not get your point. Any examples? > - Broken revocation system (https://medium.com/@alexeysamoshkin/how-ssl-c= ertificate-revocation-is-broken-in-practice-af3b63b9cb3) Therefore OCSP-Stapling is necessary. Not only for security, but also for bootstrap to work. > What if the client doesn't get the CRL/OCSP informtation? If unable to get OCSP information, the client will probably query itself in= a loop, and may crash finally. If you run DoH server by yourself you will know this problem. > Bottom line: Don't trust a CA. No offence, but do you trust ICANN? That is single authority, compared with multiple CAs. Conclusion: I do not think DANE should be preferred than PKI (or "MORE RECO= MMENDED" than PKI). At most they have the same level of security. (Actually DANE is worse, e.g.= nearly impossible to rotate the root-anchor.) From nobody Thu Aug 16 04:22: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 8F89112D7F8 for ; Thu, 16 Aug 2018 04:22:17 -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 (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 xiOFAl9f7aWb for ; Thu, 16 Aug 2018 04:22:15 -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 032D9128B14 for ; Thu, 16 Aug 2018 04:22:14 -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:To:From:Subject:content-disposition; bh=UcNnnyEBhRLJYhZWGgplgUeTFSGeCflQjFyspwetLOY=; b=hKY4h6rMrIJONR2yfu/kpMTXpY QOnrKj9QBJmyZy12UdsR5HmoXWjXYuXDEnNThMAXmtudyAO3rguh+qRyEhRGSGsWfe1HU131Z9tyI NAdaNWoKYPPSoxbmU5chacMcdx2I2I5CnmmhAqaIshlc1WK7RvqUTxW7JVdWGegztHQxXTYp0BoUy p6W5NfihYuVFgBrqZLTXQ5DrHQSTyZNxleZV7y8PMWu/70dhrJnvbkhbLZBYZHOSBQa/4g60+PlwS EvbNC9m6DG0FMhGzo+7M7ejWMjyQ+kxdA6GUrEg7pU0i8k8zALQN7dsx2/0/DvqKRAxrxZ86o438Q Sxu67Bmp8M11dtZkW5MSv0WWoNp6EaXivnnoztq2s1+F0kB54G70mo9tncP5QYzIpQF3KVgguU1J1 PqNHlz3Ol7TbxWqm06eaHYEcCFK8rtXgL9to9VQHpi4yW0ZdAIHPNLlkhK+B4rixcx05XKYNWPQIa cryz2hHlPJMebZFyZnqofgmhjm4R7oU2pZRIrnQ96EVWM+H13KqIlvZcTzgR9nc6Uab9bJftqY7pn IXZwrxNtontJZMgh2CNIj/z/LXyZlhOZxpHHnSO9iTLh1lyw4AxlI7gpHYUjaY5adVaPBSt+9Mlrk AOxWa6dGs3QMDcRF8BmPEwZfXl7s9Efj8SMCERuOo=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqGLz-0006Eu-0Q with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 13:22:13 +0200 References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> <74018a91-eecb-bb35-d5c4-e72487a0719a@bartschnet.de> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" To: doh@ietf.org Message-ID: Date: Thu, 16 Aug 2018 13:22:10 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 11:22:17 -0000 Am 16.08.2018 um 12:10 schrieb Star Brilliant: > On Thu, Aug 16, 2018 at 7:37 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >> >> Am 16.08.2018 um 11:01 schrieb Star Brilliant: >>> On Thu, Aug 16, 2018 at 6:13 PM Rene 'Renne' Bartsch, B.Sc. Informatics wrote: >>>> >>>> Hi, >>>> >>>> as TLS-certificates forged or obtained by devious means have become common in MITM-attacks by intelligence and criminals >>>> I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security considerations). >>> >>> Hi Renne, >>> >>> I am sorry I could not get your point. >>> >>> How could it be possible to forge TLS certificates without being detected through our current PKI systems? > > The security level is the same with either PKI and DANE. > > Let me explain. >> - Fraudulent certificate requests > > I could not get your point. Any examples? https://arstechnica.com/information-technology/2013/01/turkish-government-agency-spoofed-google-certificate-accidentally/ https://nakedsecurity.sophos.com/2013/12/09/serious-security-google-finds-fake-but-trusted-ssl-certificates-for-its-domains-made-in-france/ >> - Broken revocation system (https://medium.com/@alexeysamoshkin/how-ssl-certificate-revocation-is-broken-in-practice-af3b63b9cb3) > > Therefore OCSP-Stapling is necessary. > Not only for security, but also for bootstrap to work. > >> What if the client doesn't get the CRL/OCSP informtation? > > If unable to get OCSP information, the client will probably query itself in a loop, and may crash finally. If the OSCP server is down the (sub-) domain is not reachable any more? The DNS is much more robust than an OCSP-server. >> Bottom line: Don't trust a CA. > > No offence, but do you trust ICANN? > That is single authority, compared with multiple CAs. I definitely do not trust the ICANN. The benefits I see in DANE is you only have two parties involved: ICANN and registry. Neither of them can change the signature without being detected because of the tree structure. Checking hundreds of CAs is quite complicated and error-prone. A lot of certificates are not revoked as CAs demand a revokation fee. DANE also allows to use free self-signed certificates and revoke them by changing the TLSA resource record. DNS is more robust than a few OCSP servers. It is common usage to create fake TLS certificates via intermediate certificates on firewall appliances. This is not possible with DANE. > Conclusion: I do not think DANE should be preferred than PKI (or "MORE RECOMMENDED" than PKI). My opinion: PKI gives CAs the possibility to handle security according to their will. DANE is too static to be tampered with in such a magnitude. > At most they have the same level of security. (Actually DANE is worse, e.g. nearly impossible to rotate the root-anchor.) This should be solved now and will happen on 10/11/2018. Renne From nobody Thu Aug 16 04:39:33 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 4B44A12D7F8; Thu, 16 Aug 2018 04:39:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-doh-dns-over-https@ietf.org, Benjamin Schwartz , doh-chairs@ietf.org, bemasc@google.com, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153441957130.8078.10398621847559233803.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2018 04:39:31 -0700 Archived-At: Subject: [Doh] Alexey Melnikov's No Objection on draft-ietf-doh-dns-over-https-13: (with COMMENT) 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: Thu, 16 Aug 2018 11:39:31 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-doh-dns-over-https-13: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is an important piece of work, so thank you for doing this work. The document is well written. I am looking forward to seeing answers to Ben's questions/comments (I agree with them). I also have some comments of my own: 1) I think you should keep Section 3. Maybe make it an Appendix. It would be important to have it if the document gets extended in incompatible ways and some of the requirement/assumptions states in your document are violated. 2) Related to section 3: is there any desire in the WG to work on an extension which would allow for cases when a single request might result in multiple responses? 3) In 3.1: o Supporting other network-specific inferences from plaintext DNS queries Can you please decode this for me, as I don't understand what this is trying to say. Maybe provide an example? 4) In 5.1, next to the last para: In order to maximize cache friendliness, DoH clients using media formats that include DNS ID, such as application/dns-message, SHOULD use a DNS ID of 0 in every DNS request. HTTP correlates the request and response, thus eliminating the need for the ID in a media type such as application/dns-message. The use of a varying DNS ID can cause semantically equivalent DNS queries to be cached separately. Not being that familiar with DNS (and not having read the whole document at this point) I didn't know whether this was talking about some kind of DNS specific thing or whether it was talking about something specific to DoH. At some point I was wondering if DNS ID was supposed to be included in some kind of URL. So maybe you should add a reference where you mention "DNS ID" for the first time. 5) In Section 8.1: Security considerations: The security considerations for carrying this data are the same for carrying DNS without encryption. I think you should do much better then this. This field is supposed to give a quick hint whether there is any active content(*) (e.g. executable code) in the described media type, so that people implementing firewalls and antispam can decide whether anything special needs to be done to process the media type. But what you did is effectively sent me to read all DNS related RFCs on the topic. So please also state whether active content is allowed here. (*) - among other things 6) In Section 11, 3rd para: Some HTTPS client implementations perform real time third-party checks of the revocation status of the certificates being used by TLS. If this check is done as part of the DoH server connection procedure and the check itself requires DNS resolution to connect to the third party a deadlock can occur. The use of OCSP [RFC6960] servers or AIA for CRL fetching ([RFC5280] Section 4.2.2.1) are examples of how this deadlock can happen. To mitigate the possibility of deadlock, DoH servers SHOULD NOT rely on DNS-based I might be confused here, but I thought the most typical is for a DoH *client* to validate DoH *server's* certificate for being revoked. So did you mean "DoH client" instead of "DoH server" above? If not, then I think you lost me and this text needs to be rewritten to be more specific about what the problem is. references to external resources in the TLS handshake. For OCSP, the server can bundle the certificate status as part of the handshake using a mechanism appropriate to the version of TLS, such as using [RFC6066] Section 8 for TLS version 1.2. AIA deadlocks can be avoided by providing intermediate certificates that might otherwise be obtained through additional requests. Note that these deadlocks also need to be considered for server that a DoH server might redirect to. From nobody Thu Aug 16 06:39:05 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6284130F5E for ; Thu, 16 Aug 2018 06:38:56 -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, 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=rtfm-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 cDON-ikDILJu for ; Thu, 16 Aug 2018 06:38:54 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 F2CFA131062 for ; Thu, 16 Aug 2018 06:38:50 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id v22-v6so3418461lfe.8 for ; Thu, 16 Aug 2018 06:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WBs9M7cd5JYAqwZvT5ks4co1xxwmhZcREmJixYrRB6c=; b=rh5tsvljRhT/cyVu4FAqJkffxECjCaFLESAYWekSCyzZUAa34RIpqjbtcn7rnPxtHb 55kvOUg0x98bGJFfEp0MeYmzY+sx43oViagB1extwZpyRk7HgOBVaA7dxd1oKlcp1LeK nKqNBKp/5tTbQS1Np1zydKSqKYTw+vRBxVorM94Uzx4PGFI9Vj7ICuoUzpEAUOlKoWpn tcLt/MqFt2J32LTJ/i1mjp9299Jb6icnW+Qyfohoyjn99OZZroAndArY8WPkLyvUyj72 +G3eFmZyO9/j9qACAMJo0Fhz6aWQvl6IC5P40ZvWB7pV8F+9eXHU8StYXIoAoSJIESIe 9YWQ== 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=WBs9M7cd5JYAqwZvT5ks4co1xxwmhZcREmJixYrRB6c=; b=Xgnjh8SgvZbJrtwdgs7H2562UhVCOuT8l31ClkhsEUw6hSoxZCqi/VgDJ7IeeRJVeH zPtuzee2EQeNd9N0szb6JHL9BGPfiybEMA5r/xoMqWzHixhMgBlib01ImMSa9l4Aq/NO cHh1gOy3sYxMoHwAMjX7lWBlK12522sVU5iI4EowATT5WVc3a0Cn8ac0rZ0i49w5AWn1 002bT+1jJWyAMkYYAONjIk7qkkdh/maHsy6c8O4IBvnUGvmp2QzJmYzQ8UMYJAjcNXMO zFn2f4PqexP5IVXbl19VIs0WCFSxfBLW0/+B5eLg3yam8mee6nK0LaU+wBH2it7EZni4 7+ag== X-Gm-Message-State: AOUpUlFKZ47t54XWaiQrPCM+T1mny7iplY8tpMbW1uU2SCRAkvf7lLnm gAayjeBFk9gVOgwrfvooMwaJaWjE/TiXqbnI6qH4aWU3 X-Google-Smtp-Source: AA+uWPx89nUc1hwSIcwWDgZ9QdpUzl2JU9o9Gu1IFA+9Q+BymskXfwfhmpXH0WdSijBPGgME2kCaPkFrAcckUtVfPfI= X-Received: by 2002:a19:cb93:: with SMTP id b141-v6mr1537824lfg.119.1534426728971; Thu, 16 Aug 2018 06:38:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 06:38:08 -0700 (PDT) In-Reply-To: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> From: Eric Rescorla Date: Thu, 16 Aug 2018 06:38:08 -0700 Message-ID: To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000001d531a05738d904c" Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 13:39:03 -0000 --0000000000001d531a05738d904c Content-Type: text/plain; charset="UTF-8" On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Informatics < ietf=40bartschnet.de@dmarc.ietf.org> wrote: > Hi, > > as TLS-certificates forged or obtained by devious means have become common > in MITM-attacks by intelligence and criminals > I suggest to RECOMMEND authentication of the DoH-server TLS-certificate > via DANE-TLS (RFC 6698) in section 10 (Security considerations). > I don't think we should make this change. Much of the value proposition of DoH is that it's straightforward to run on top of existing HTTPS infrastructure, and as a practical matter nearly all of that infrastructure depends on WebPKI certs and does not do DANE. For that reason, this recommendation would be more aspirational than practical. -Ekr --0000000000001d531a05738d904c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. In= formatics <ietf=3D40bartschnet.de@dmarc.ietf.org&g= t; wrote:
Hi,

as TLS-certificates forged or obtained by devious means have become common = in MITM-attacks by intelligence and criminals
I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via= DANE-TLS (RFC 6698) in section 10 (Security considerations).

I don't think = we should make this change. Much of the value proposition of DoH is that it= 's straightforward to run on top of existing HTTPS infrastructure, and = as a practical matter nearly all of that infrastructure depends on WebPKI c= erts and does not do DANE. For that reason, this recommendation would be mo= re aspirational than practical.

-Ekr

--0000000000001d531a05738d904c-- From nobody Thu Aug 16 08:42: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 4DEA7130EA7 for ; Thu, 16 Aug 2018 08:42:31 -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 (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 bf3NRap91ZQV for ; Thu, 16 Aug 2018 08:42:28 -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 AF72A130DCA for ; Thu, 16 Aug 2018 08:42:27 -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:From:To:Subject:content-disposition; bh=8KlusN1yrE3IjWfVSY0dUM7Kmm0bwOxkt+V0U5xq8Vw=; b=ZG9DLCOlvc6/ck9ciwAJOhFrMy iIZW0pXE69ux8/ltLI8u8f6P/5r+hvwP5MjqkSJi3H9BGd0XnLfT4Hl4N8HpCz8NtLGF0agfn92Ll QNozb4eBSIq0FKvpKILr/BF4RXXj6IHFTq1EouKBQAscRFt5FTCYsOj3b7v9SE1Nd7G6SY12tizNs k8V5+4eQ5LlrlN4qVz0tDj99YZpq/agTbLTg1IocK0qMoLm44Y5xLuDJdYMwEiQoaPp/JLAbNIBdN Y/vmFl/j1+22h+OxniyrduxA+g0cO4XaVtWGtRx8VjWoUxV4Uo0lDgGqn1PBAnmOzduHcpdMZJ5SW simxWfmHtgh0kfabHCeUR6+c2L2b41EgtP/g+836WhHazaqig2ZFttoJVNILsoy0E76qhsohcEWzx g/CsO1hD8WqKlxT9waZcF4k1mvt1ZbDB6x5J/YvHcRREHlr6hY/10WlPpQzXLHx6YqZBueJO/9d3S YUdFPzn4TggysB4GJdRAzAnxEoO84IGv4ieHGgRFRupThzlaMhg4xdbft8LrGmOeii1Oak08ubs0T bZS2V032ucg7lNBP3mpgtGfH8EcBI5Sw0acaoow+p6hWF9VkUwReHbDGG8hYtO0MYwmmQWHWagZ2w 2wI5e4XScOkoHAS+prk5XKEHJXH4oX/991Ypqk66s=; Received: from localhost (localhost [127.0.0.1]) by mail.core-networks.de id 1fqKPo-0004Pk-HJ with ESMTPSA (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) for doh@ietf.org; Thu, 16 Aug 2018 17:42:25 +0200 To: doh@ietf.org References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> From: "Rene 'Renne' Bartsch, B.Sc. Informatics" Message-ID: <57f33ab2-4af1-8760-5d0b-7f85612aea56@bartschnet.de> Date: Thu, 16 Aug 2018 17:42:22 +0200 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US-large Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 15:42:31 -0000 Am 16.08.2018 um 15:38 schrieb Eric Rescorla: > > > On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Informatics > wrote: > > Hi, > > as TLS-certificates forged or obtained by devious means have become common in MITM-attacks by intelligence and criminals > I suggest to RECOMMEND authentication of the DoH-server TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security considerations). > > > I don't think we should make this change. Much of the value proposition of DoH is that it's straightforward to run on top of existing HTTPS infrastructure, and as a practical matter nearly all of that infrastructure depends on WebPKI certs and does not do DANE. For that reason, this recommendation would be more aspirational than practical. The problem I see is that e.g. firewall appliances with fake certificates by intermediate certificates can break privacy and manipulate the DNS records. Without proper authentication of the DoH-server certificate DoH only protects from script-kiddies. Renne From nobody Thu Aug 16 09:16: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 486AE130DE2 for ; Thu, 16 Aug 2018 09:16:41 -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, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 oHOWGXeRiIPc for ; Thu, 16 Aug 2018 09:16:37 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 34FA51252B7 for ; Thu, 16 Aug 2018 09:16:37 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id f135-v6so3802104lfg.10 for ; Thu, 16 Aug 2018 09:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5aAruh7kpAF0L5XYomh+HqdPJRv9jsxKBMo7ntvG5oI=; b=byB2PCMUHZyCxs+jaNpoIv7I/kYTaGHEALFQRK5c0dx6xvaNp7ecy+obak5uHG8ZkG or5x5UBJohAPL1Le5md7VlEqE0o6qp3qHiYu13BEn8J7W7XGBCdfwK610wOB7Gpv3Bvh /s4X4M5p3Nhmb+x0KoGIUdp4mF1kizqptKtDMvMPLY+PzEag5fdpNjr0+NiFD5uU4y4N K2nlnS3FIA9GTy3lSioK/4+vbuRUH3bc6bVtsvlMpBNaA/+D5fX+B2CpJQoiRbw73iSZ K0Knj110U6Hf8uZ4rreA3PyDG+h0AlsIeHZRW9hHCVAfyJY0ntBNOZMEzbJ2E6HS7DEy n/nA== 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=5aAruh7kpAF0L5XYomh+HqdPJRv9jsxKBMo7ntvG5oI=; b=MXB47wS8CHsXqnd6pusph7BSeAZmPOTRKWa7hH/PJ5ToS/4NnYdaH17BpQUiSoDbLT jXrUlIMzRBbx5aIrFmvaZ7r0n0BrDUhqCaYjmVQsdXzNo0N+ncVzTVtWpa9wOorG0uja 4h86z4jC2w8DzYImsXHHvjvCzVt2uKOpM7eNUM/4LzjD1ZofN8ew/akF6GNElMNeAmT6 9HSmncUS0fXfuyJzr4mWY78M0YYs+s7qNE6XiJgY2ZDDRWhCLc0BQCISjIGfEjPIHDpS sVEqc6C0Wkwb7Zct9Te+DuNKLS5iCouoRV11itQaqrYCib4coJ368QxiJyzAcb1guElm JoRg== X-Gm-Message-State: AOUpUlErwypikPGECpQO2H1hR7IP32AW3CV4i68cATPOPRBdK0NXhmNh /r9XgZk4fGIDCUgEMnyZ5C2IE0r4+TZezlndmrmWJ3xu X-Google-Smtp-Source: AA+uWPxCBB3zz+qjTZ3FcBBNik9hmruxdGwGni0n3FpsboqlLViyO7WufR+dGHh9CWYgos2kbQX65JQ3m284m7HutT8= X-Received: by 2002:a19:cb93:: with SMTP id b141-v6mr1904803lfg.119.1534436195085; Thu, 16 Aug 2018 09:16:35 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 16 Aug 2018 09:15:54 -0700 (PDT) In-Reply-To: <57f33ab2-4af1-8760-5d0b-7f85612aea56@bartschnet.de> References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> <57f33ab2-4af1-8760-5d0b-7f85612aea56@bartschnet.de> From: Eric Rescorla Date: Thu, 16 Aug 2018 09:15:54 -0700 Message-ID: To: "Rene 'Renne' Bartsch, B.Sc. Informatics" Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000056cda805738fc4b5" Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 16:16:41 -0000 --00000000000056cda805738fc4b5 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 16, 2018 at 8:42 AM, Rene 'Renne' Bartsch, B.Sc. Informatics < ietf=40bartschnet.de@dmarc.ietf.org> wrote: > > > Am 16.08.2018 um 15:38 schrieb Eric Rescorla: > >> >> >> On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Informatics >> > marc.ietf.org>> wrote: >> >> Hi, >> >> as TLS-certificates forged or obtained by devious means have become >> common in MITM-attacks by intelligence and criminals >> I suggest to RECOMMEND authentication of the DoH-server >> TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security >> considerations). >> >> >> I don't think we should make this change. Much of the value proposition >> of DoH is that it's straightforward to run on top of existing HTTPS >> infrastructure, and as a practical matter nearly all of that infrastructure >> depends on WebPKI certs and does not do DANE. For that reason, this >> recommendation would be more aspirational than practical. >> > > The problem I see is that e.g. firewall appliances with fake certificates > by intermediate certificates can break privacy and manipulate the DNS > records. > if you are behind such a firewall, you have much bigger problems than fake DNS records, given that the traffic you are sending post-resolution is almost certainly being protected with something rooted in the WebPKI. Without proper authentication of the DoH-server certificate DoH only > protects from script-kiddies. > I don't think it's accurate to characterize WebPKI as not "proper authentication". That's certainly not the position we've taken elsewhere in the IETF. If you want to make some broader argument about how we should stop trusting WebPKI and universally recommend DANE instead, you're welcome to do so, but this particular document is mostly just an other application of HTTPS, so it's really not the place for it. -Ekr > > Renne > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000056cda805738fc4b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 16, 2018 at 8:42 AM, Rene 'Renne' Bartsch, B.Sc. In= formatics <ietf=3D40bartschnet.de@dmarc.ietf.org<= /a>> wrote:


Am 16.08.2018 um 15:38 schrieb Eric Rescorla:


On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. Inform= atics <ietf=3D40bartschnet.de@dmarc.ietf.org <mailto:ietf=3D40bartschnet.de@dmarc.ietf.org&g= t;> wrote:

=C2=A0 =C2=A0 Hi,

=C2=A0 =C2=A0 as TLS-certificates forged or obtained by devious means have = become common in MITM-attacks by intelligence and criminals
=C2=A0 =C2=A0 I suggest to RECOMMEND authentication of the DoH-server TLS-c= ertificate via DANE-TLS (RFC 6698) in section 10 (Security considerations).=


I don't think we should make this change. Much of the value proposition= of DoH is that it's straightforward to run on top of existing HTTPS in= frastructure, and as a practical matter nearly all of that infrastructure d= epends on WebPKI certs and does not do DANE. For that reason, this recommen= dation would be more aspirational than practical.

The problem I see is that e.g. firewall appliances with fake certificates b= y intermediate certificates can break privacy and manipulate the DNS record= s.

if you are behind such a firewall, y= ou have much bigger problems than fake DNS records, given that the traffic = you are sending post-resolution is almost certainly being protected with so= mething rooted in the WebPKI.


Without proper authentication of the DoH-server certificate DoH only protec= ts from script-kiddies.

<= div>I don't think it's accurate to characterize WebPKI as not "= ;proper authentication". That's certainly not the position we'= ve taken elsewhere in the IETF.

If you want to mak= e some broader argument about how we should stop trusting WebPKI and univer= sally recommend DANE instead, you're welcome to do so, but this particu= lar document is mostly just an other application of HTTPS, so it's real= ly not the place for it.

-Ekr




Renne

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

--00000000000056cda805738fc4b5-- From nobody Thu Aug 16 09:29: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 7F4B712D949 for ; Thu, 16 Aug 2018 09:29: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=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 ZTAeMlXlGqGg for ; Thu, 16 Aug 2018 09:29: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 10C75130934 for ; Thu, 16 Aug 2018 09:29:48 -0700 (PDT) Received: from Orochi.local (c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w7GGTi3h033080 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 16 Aug 2018 11:29:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host c-73-206-50-7.hsd1.tx.comcast.net [73.206.50.7] claimed to be Orochi.local To: "Rene 'Renne' Bartsch, B.Sc. Informatics" , doh@ietf.org References: <6fb4a552-8d5e-494b-f934-1f97b83b0ab6@bartschnet.de> <57f33ab2-4af1-8760-5d0b-7f85612aea56@bartschnet.de> From: Adam Roach Message-ID: <102c1e5b-5ca2-db25-b6f5-8cb8ab0de6c4@nostrum.com> Date: Thu, 16 Aug 2018 11:29:43 -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: <57f33ab2-4af1-8760-5d0b-7f85612aea56@bartschnet.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Suggestion on draft-ietf-doh-dns-over-https-13: Recommend DANE-TLS to authenticate the TLS-certificate 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, 16 Aug 2018 16:29:50 -0000 On 8/16/18 10:42, Rene 'Renne' Bartsch, B.Sc. Informatics wrote: > > > Am 16.08.2018 um 15:38 schrieb Eric Rescorla: >> >> >> On Thu, Aug 16, 2018 at 1:13 AM, Rene 'Renne' Bartsch, B.Sc. >> Informatics > > wrote: >> >>     Hi, >> >>     as TLS-certificates forged or obtained by devious means have >> become common in MITM-attacks by intelligence and criminals >>     I suggest to RECOMMEND authentication of the DoH-server >> TLS-certificate via DANE-TLS (RFC 6698) in section 10 (Security >> considerations). >> >> >> I don't think we should make this change. Much of the value >> proposition of DoH is that it's straightforward to run on top of >> existing HTTPS infrastructure, and as a practical matter nearly all >> of that infrastructure depends on WebPKI certs and does not do DANE. >> For that reason, this recommendation would be more aspirational than >> practical. > > The problem I see is that e.g. firewall appliances with fake > certificates by intermediate certificates can break privacy and > manipulate the DNS records. > Without proper authentication of the DoH-server certificate DoH only > protects from script-kiddies. The document does not suggest that DoH servers are used without authentication. What DoH does -- and this is a huge part of its appeal -- is leverage the existing web security model. Because it's used on top of HTTPS in general (rather than any specific version of HTTPS), I would expect that its security model evolves in lock-step with the web security model. If that eventually includes DANE in some capacity, then DoH will naturally do the same thing. For your own uses, if you are so opposed to the web security model that you believe it will not work for your application, I encourage you to look into RFC 7858, with particular attention to section 4, as well as draft-ietf-dprive-dtls-and-tls-profiles. /a From nobody Thu Aug 16 10:23:51 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 ADAB7130DD4; Thu, 16 Aug 2018 10:23:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: doh@ietf.org Message-ID: <153444022268.12104.6689021759876721108@ietfa.amsl.com> Date: Thu, 16 Aug 2018 10:23:42 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-14.txt 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: Thu, 16 Aug 2018 17:23:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Over HTTPS WG of the IETF. Title : DNS Queries over HTTPS (DoH) Authors : Paul Hoffman Patrick McManus Filename : draft-ietf-doh-dns-over-https-14.txt Pages : 20 Date : 2018-08-16 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-14 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 16 11:22: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 19A38130F17; Thu, 16 Aug 2018 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 zJAYXm5J5SHp; Thu, 16 Aug 2018 11:22:43 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-oln040092005026.outbound.protection.outlook.com [40.92.5.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E31128CB7; Thu, 16 Aug 2018 11:22:43 -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=PTVrZCV6GpAv055qzlJ+8AqfcRlubGFhhAfpdlh1/u4=; b=RswRQ9nJRvsnHndAL2+5IM17Xf3JlvfGd3yL7Vb+frid38Bkbvbs+0cLas2i1MGEWZd3Am80OoEysC0cqPKFd3XRNzgFvyYCke5XaoZKzNmzBa0cN/3PwCxWdlYqKy8WbqdCo5BPQFyXD01oUEkVaoA2A3GtErBDLIKLQFaBXRy45YglGbRUrwIp8kTFz19rn9Wo0PbDzkbxat2A1whq5qJydNYxtWOAMjASp691OFAleOMHY8yLxeLz+/HAyn8ZbztGPr4RYsKfLBnNmFrAy6qgI3kCUi4vYzl/aJJNkSRlZkDqVKYutXYC2w1X/vMmrMg+zUt3HQsjJKGf578VDw== Received: from SN1NAM02FT005.eop-nam02.prod.protection.outlook.com (10.152.72.55) by SN1NAM02HT008.eop-nam02.prod.protection.outlook.com (10.152.72.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1059.14; Thu, 16 Aug 2018 18:22:42 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.72.55) by SN1NAM02FT005.mail.protection.outlook.com (10.152.72.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1059.14 via Frontend Transport; Thu, 16 Aug 2018 18:22:42 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1%3]) with mapi id 15.20.1059.017; Thu, 16 Aug 2018 18:22:42 +0000 From: Star Brilliant To: "doh@ietf.org" CC: "i-d-announce@ietf.org" Thread-Topic: [Doh] I-D Action: draft-ietf-doh-dns-over-https-14.txt Thread-Index: AQHUNYX6lkTMf2CBhkmitpr7FB0YnKTCsOzB Date: Thu, 16 Aug 2018 18:22:41 +0000 Message-ID: References: <153444022268.12104.6689021759876721108@ietfa.amsl.com> In-Reply-To: <153444022268.12104.6689021759876721108@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:2ACF2770BB2B9162486C293DB397630ED8E4086A3131806273532126FE39945F; UpperCasedChecksum:6BED83342F1457C7EA60AE0078C85DC32802BD011394146DAE5C76C314C589A8; SizeAsReceived:7072; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [cHARd2k2CeGiukgq3zTB08ee/JdFzGxu] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM02HT008; 6:q7v6kLST947RpwkBbuOsvR3FL9SJynVi3oRNAjGTSxbXjXDbCzIloy5GFWHfoF3SHKWcXsOE2/+fXw1psn8qHmqOy+IBSAmanrHoakDS6VaK9Ou4EoSoreH39A6GB2S7V63C83GJGPzO7YlEHb6Pfb2y2W1tiHoYfpkJpyZ319sYbmMe73NFQEuzKzz9IL4LBGN4hmlVe2sQx+3W0o5aPMGEvM+rXfanbddBFt7DP/oDjz7JWdWzEJgYlEfemRHDRpLMOpxOOb8kCDhzLz8R6tc7bQmhaYMOMKIMz1y8kmYRj4Bo99Vimc3KmmSVzpI07AK/gzNBXKdRq4ZCBZQc+jaGliwteBQ8nGZN4No8d0Vo3DXQPUd1TmfDT/fyzqHvv9cmvaxYm7bfD0/kamdW+NlMjhyqXqrfSwCmv84Q9++xiWxB+w5noXUJl9YvoTC1Y6kvJkA7D+4fjyNUtb8AkQ==; 5:yNVRnJ6VwPBwSkitZKlnfW6Ii9npGiGOl9bHbj6ooI9RoABj9Vk4WeTmLy3qZt1SDlEMarEpknJuhAi6eWmtQrnuP/tlnXCA0PQeJ7OYe1n3Y4OcroUjKgzihE/N9U8w0mSkdCyAU/F3NDXKOxaGvdkYcV/Cs3/f1TVf+f44dpg=; 7:CDY8K2pm7VCpYgVzD76HRw4+M1KvcPtDgn0a0ueEPQBMipP8DN99WV03H+jmrP3t/k0m/MjGEiyTjvESdvdr5c9DswXict3K5iQJuphjlwehDKvVyuZgBZhiVhbQ5d+U1P3gW4jdxS4+a2pIMu7GB64ywIT1zKiRy5uRhT2hLTsyvB8BTJ4g0Y/efAgJSYBwrS9jYpBd1Fs3G3OLy7wozlzZCQivOMimGciMApIn4dC54MfbR3iOQQ+G94x7vmPp x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:SN1NAM02HT008; x-ms-traffictypediagnostic: SN1NAM02HT008: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM02HT008; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT008; x-forefront-prvs: 07665BE9D1 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(446003)(4326008)(5640700003)(6306002)(450100002)(25786009)(476003)(7696005)(83332001)(9686003)(55016002)(11346002)(5660300001)(229853002)(6246003)(86362001)(14444005)(2900100001)(256004)(56003)(6436002)(14454004)(966005)(20460500001)(99286004)(1730700003)(6346003)(33656002)(102836004)(2501003)(8676002)(87572001)(82202002)(5250100002)(104016004)(106356001)(105586002)(76176011)(81156014)(68736007)(26005)(73972006)(6506007)(53546011)(6916009)(2351001)(8936002)(486006)(305945005)(74316002)(97736004)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM02HT008; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: zvKQ5lkZJmnmkBcSiOjAYBFIe/KdsG356VcKl37bgUjRAzqrVPkDEsNmsyrv7265LLpKFXU8XhsgNzS4nrhYELAZ9s3iW7BRsOwJzDS+iOy6RrL3kT/MP1TSCpHFm7CU7UC3hgJpbP4bL4GpRiciXdx8pA0CbE204REPLZvYsRQrIUHHzsE7LU3AWaZMahJKZJu6Ax3wyj9o9XrfPvls3KsSTp3xx8NPvAo63sgR5bA= 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: 9a7eb8e5-6050-496a-c2dd-08d603a54157 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2018 18:22:41.9792 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT008 Archived-At: Subject: Re: [Doh] I-D Action: draft-ietf-doh-dns-over-https-14.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, 16 Aug 2018 18:22:45 -0000 On Fri, Aug 17, 2018 at 3:24 AM wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DNS Over HTTPS WG of the IETF. > > Title : DNS Queries over HTTPS (DoH) > Authors : Paul Hoffman > Patrick McManus > Filename : draft-ietf-doh-dns-over-https-14.txt > Pages : 20 > Date : 2018-08-16 > > Abstract: > 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-14 > https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-doh-dns-over-https-14 > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh Hi, I would like to refine the document by pointing out several spelling issues= . On Page 6, Paragraph 2, Section 4.2: [...] The amount and type of information that a media type gives is solely = up to the format, and not defined in this protocol. s/is/are/ On Page 8, Paragraph 3, Section 5.1: [...] This requirement helps prevent exipred RRsets in messages in an HTTP = cache from unintentionally being served. s/exipred/expired/ On Page 4, Paragraph 5, Section 4.1: [...] When using the POST method the DNS query is included as the message b= ody [...] (Minor issue) I suggest a comma (,) followed by "method". But okay if keep = untouched. Best regards, Star Brilliant From nobody Mon Aug 20 04:40: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 03515130F5F; Mon, 20 Aug 2018 04:39:56 -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 FbEaoy_FdTRE; Mon, 20 Aug 2018 04:39:53 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 62E74130F20; Mon, 20 Aug 2018 04:39:53 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id d4-v6so15728330qtn.13; Mon, 20 Aug 2018 04:39:53 -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=jubMFbzLpk4ErCQy43s6/iS3VddULLnUULx9weIBN7k=; b=sHKuov06ubpkT+vo3TNlBpKqp2MSQEiYPrzeBKdRDINxCMbSEMJFYFJ6bcpdQIDXqg KkNqAtXuvulYhxcoEnpLh5FAWxUnhbhO7fji178LvIc5P0O+3SeKM7t/6cOn6Z1zMtHb 6BxJHvdY3UKmjAhIid3/aQUUv1EihV4qiHMxjoxpkEH9dkWaijQHotl12dtOxilR6zBH AAiPZrWepUdGN1igoAUnRPbjRRC0j7FzWHbie4MopaF4vevXWYX++N+9LLedv4M4Qfp6 e5YkSLJLGUR68A1gdxXRDSxB4NVmalhv7n+0HD5LiCWPBMJ3DGYhCKJ8+eBrOFzGPLgX efzQ== 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=jubMFbzLpk4ErCQy43s6/iS3VddULLnUULx9weIBN7k=; b=aWg3T1+QaLcM7CngAAUY+quUKQP9A0Fvvpt0YQ/W9IZ/nqYN2mfjbbaELy9GGmA50a hWIxTlO9B5XhhSXbZ9bveP6zI8QJLqfQ6uloLidjtRB+QqYXcWcBh8jPxukx9rUbwGq1 IN1Y3BMGJDGv8HByf02gcUq8ZWmU4WuhC+1f7KBSt49ta+lac/yOlBmVDpL8D3czg//A zde38rDqEG/o+lonLXB67vIx/gDZ0wpeQU9uyn+v5lIeGCaz6TAA5jnJxx8LiquUzBVU oetqMNT5YYaiy8DLqfURt9HbTlxGVA11Nx8Ic1xmqcFoFc2Py9LfB6G8LVe0H2dKGfFm s5Zw== X-Gm-Message-State: AOUpUlH4k9PJg2Nv5VYDgbZmLtbkAcEPt5V20A+TgAm2JtXN3DPRBj6O eQ93Ip73vNuAZEMNwuidDD/iHWYJgd9ECqPxhB5NkA== X-Google-Smtp-Source: AA+uWPwH+i91QyT8vFUwYJ4+qvzm6vtHHoaIfxNTllZtL/BPvPzPAoDeGSQPma+U3EGLWdtuLNgB79mZKFQ7zSKL1XY= X-Received: by 2002:ac8:3759:: with SMTP id p25-v6mr228972qtb.310.1534765192528; Mon, 20 Aug 2018 04:39:52 -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> <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> In-Reply-To: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> From: Sebastiaan Deckers Date: Mon, 20 Aug 2018 19:39:41 +0800 Message-ID: To: shane@time-travellers.org, adam@nostrum.com Cc: dnsop@ietf.org, doh@ietf.org, driu@ietf.org, ietf-http-wg@w3.org Content-Type: multipart/alternative; boundary="0000000000001d48fe0573dc5e8e" 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, 20 Aug 2018 11:39:56 -0000 --0000000000001d48fe0573dc5e8e Content-Type: text/plain; charset="UTF-8" Thank you for sharing these notes. > Action: Adam Roach will set up a mailing list. Where? (With apologies for the cross post.) On Wed, Jul 18, 2018 at 7:43 AM 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 > --0000000000001d48fe0573dc5e8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you for sharing these notes.

=
> Action: Adam Roach will set up a mailing list.

Where? (With apologies for the cross post.)

On Wed, Jul 18, 2018 at 7:43 AM Shane= Kerr <sh= ane@time-travellers.org> 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
--0000000000001d48fe0573dc5e8e-- From nobody Mon Aug 20 07:54: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 45C28130E4B for ; Mon, 20 Aug 2018 07:53:59 -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 7-rhxLRhfvXY for ; Mon, 20 Aug 2018 07:53:57 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 5B194130E37 for ; Mon, 20 Aug 2018 07:53:57 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id w11-v6so12815220iob.2 for ; Mon, 20 Aug 2018 07:53:57 -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=ODTu87rT0viu+PRvQFdXEYTuoqB+ow3+cz4mrpll23w=; b=CJKGnUO4A75taXq4MXS6uwMQ22xInjW8KU3vGoQaPJCozmGLBVDVLn3b5fG+ik46AQ UM/YEVtAUa/RjwloplYPFmNKSSz1HI3TRHAVBnEoFz9Bu/+Fp86EnCYuZDDtRBI0qyqf nZGbkTx+/uPcAt3PJqXlYKL1R9xtodpUG428hiK7YQiAsVLY19UcuN3LGE4hqvv6Jatg rgcVjswSDRl6ZVK00QQrCTszailiyHL+xL+/iXu0zfb0kVhgcHPml5mPnfRKXawvta9O 2VBaYCAE1O2+33VY7mJ0xgM5UL2uSf1XpKzqaGcd5zug7kB72NWWWDHpFjiTldpkyimk g8vg== 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=ODTu87rT0viu+PRvQFdXEYTuoqB+ow3+cz4mrpll23w=; b=gDXUnXtxyom4VXcz4qNWw93d3xbwMnxOoWHjQWVnf9G93vSO+sLnZVPZy9kSlhQygO 3LvW2JNaG28tiB8XRLuaoaAw4DZ+lxKrG3py/EWkoC2RDhLhYkvgfcXOK9R2/9wrmKEp 18W+wHdBWnHjggCU7xkkje+ruAEd7xlfx7uye97b+DZwPHuWaDqXCoVkuS9iljy8/luG bYH3AReF/qcIGyECef+ZkBxuEamS0pGXN+MP/QcMQYGXJRsHeZdwyp6U+4yJnVBvlETj LGfFl998zXO2VtkYxYTzMoWym46T9uUEvAQraoGJuLQkH8SlmwlRtNa49OS6yUfudXU6 xerw== X-Gm-Message-State: APzg51C5+5GxO+spP5kevPtl51yQLs+2QeYWKmadAbhht+5rQ4n5M2dg RGjJ+Ktm4PW5RJe3iwtjjDDl906ioW9FZmWt0Kr/P7HE X-Google-Smtp-Source: ANB0VdYKUbuL7Up0r/vmBK5lKMMJbgi0pJiEEcxjx5VrQ0eSR2aD+k2SFrGfrOgdzs1bDyEITD5hpHigT9lugNjd+ho= X-Received: by 2002:a5e:cb04:: with SMTP id p4-v6mr10309177iom.302.1534776836060; Mon, 20 Aug 2018 07:53:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Mon, 20 Aug 2018 10:53:45 -0400 Message-ID: To: Daniel Stenberg Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000029e7eb0573df14e2" Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 20 Aug 2018 14:53:59 -0000 --00000000000029e7eb0573df14e2 Content-Type: multipart/alternative; boundary="0000000000002011020573df14ed" --0000000000002011020573df14ed Content-Type: text/plain; charset="UTF-8" Our experimental service (https://dns.google.com/experimental{?dns}) should now be draft-13 compliant. Please let me know if you find any other problems with it. On Mon, Aug 13, 2018 at 8:54 AM Daniel Stenberg wrote: > Hi, > > I'm keeping a little list of public DoH servers [1]. Today I tried them > all > with my draft-13 compliant client and noticed that three out of seven > servers > in the list don't like "application/dns-message" as Content-Type, even > though > it's been documented since about the draft-07 time frame or so. > > This isn't ideal for interop. > > This email is just to highlight the situation and for me to beg that if > you > run such a server you update it soon so that we all play by the same book! > > Thanks, > > [1] = > https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers > > -- > > / daniel.haxx.se > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000002011020573df14ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Our experimental service (https://dns.google.com/experimental{?dns}) should= now be draft-13 compliant.=C2=A0 Please let me know if you find any other = problems with it.

On M= on, Aug 13, 2018 at 8:54 AM Daniel Stenberg <daniel@haxx.se> wrote:
https://github.com/curl/c= url/wiki/DNS-over-HTTPS#publicly-available-servers

--

=C2=A0 / daniel.haxx.se

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000002011020573df14ed-- --00000000000029e7eb0573df14e2 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 fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCofVkUApEnxxzqPbUlPW+i SgGdXiourtWUjlSqx+3nPTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA4MjAxNDUzNTZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAhlSkFLuIqduW3TJ5kwnrgiSXloY+b7Eb1BVYRv4l Y9KaNl+/lxWvPdulQDbOZ/BLvL4a4TzqSMOcyGB1BPSY86WJU0EKmL3jZnisZAlZ+4MnMtj/vgAc kaez2G1qs+JTA3hh+UVTDEq4ToPWU0Zdfh6yNPD66CxNCOOMN+XVSkVV0/NTSyw8lgdZ/JVMgQLs JN7RJgeTMHhtsvj4wloGaHhQ/IYTbSO0LERQBGBW84pYtlPl5EcDfh9b2TDXUrB0Xz7tMBupS6RO a+rEcKeHA43hCUuCwGNueQH+NCxKQ5wRrAKFVnudfpxERiV2SHGK88E9JcUOGY6mkETSO270Ag== --00000000000029e7eb0573df14e2-- From nobody Mon Aug 20 08:30: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 BA64F130E52 for ; Mon, 20 Aug 2018 08:30:53 -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 YpiEZYUCWFb8 for ; Mon, 20 Aug 2018 08:30:52 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 EFA90127598 for ; Mon, 20 Aug 2018 08:30:51 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id d10-v6so21132592itj.5 for ; Mon, 20 Aug 2018 08:30:51 -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=fYVrJbmKz+cl/gqptCiDUkG3+/UFQuSUvmMGY7gCM+Y=; b=bOtWjBEJEdp4LopvRjtgLMDJBhH41zIXvtb18ozwJivoHrlotO4jfOScIwhmNnllr4 wORsnltTNVCA+dLLA5VRPLwFZ5H3h6zEm3s1sPNkoRGSKydXZpTBZwvwbhvq/RrZg7sK ZUNKrAAgUZZpcnTazG50ArGdCQVZpC/siYMFoaJc5fvegHlT38GoZGbBb0xNc0YTNKyQ nSzo/EJdlZtvmP9W7bYUdOAeQHsXhXlYCyvBPUoz6Q3ERMY+wzV4dCysgbt+aNNP1kzj KAaS0PiN3A/DJ5bPzLUV4DAJ0ZGoEpEQga1Eme9nc5XqyuSev1KSmLzp7JUf45MDd5V0 mIxw== 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=fYVrJbmKz+cl/gqptCiDUkG3+/UFQuSUvmMGY7gCM+Y=; b=pqPGtK7DFXTtLRUBl/d0iIDf4wm36eT1j2QrwLl7wIua9nTsRdtB43sQ/dDgqta2zT mVGGncA43osr3m0bJN9buJ59MrTcZZpNqfI5HSn/Fi4fLh0Fz2G+e+5C/zD/Cbs+oDfz 1hV3pTfrmiky2cEjExVSS6M+RrO7Bws6UMuSG6mMLIi3KUTr3RnSOf9YPDiRNJppaDoH H/UtYaRSglzVGm2/6PZy72qzPaaZnwdnELtEi/W14QrKjLEJLnRjLxAgxcl+/ML+qiAR LEBdS29l6Cn4XK6a/RsAzpqhRPoY6O5ChT3vbB5q5PMRtu6xC+3EIG7zQgrN4hLEkV6s Pc4A== X-Gm-Message-State: AOUpUlFX7aVtplyzsXPWAng/UU7x2aYo8UI4qB/ss03Tt38Phm0FkncW L2hbyMqo5pA4RbTbuayZholuQF76MXwqYnUWli3gik1C X-Google-Smtp-Source: AA+uWPzE0ozqPqvfNnLokD5jFWXfRzBknOeM7jAJ5k82cXTfDdu/UkfiTHkCtjRDtIWrMcoAahmsnYGUyEJrDsqc/XA= X-Received: by 2002:a24:5d4a:: with SMTP id w71-v6mr35144010ita.118.1534779051144; Mon, 20 Aug 2018 08:30:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: manu tman Date: Mon, 20 Aug 2018 08:30:40 -0700 Message-ID: To: Ben Schwartz Cc: Daniel Stenberg , DoH WG Content-Type: multipart/alternative; boundary="0000000000002709260573df98e9" Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 20 Aug 2018 15:30:54 -0000 --0000000000002709260573df98e9 Content-Type: text/plain; charset="UTF-8" \o/ Thanks Ben! On Mon, Aug 20, 2018 at 7:54 AM Ben Schwartz wrote: > Our experimental service (https://dns.google.com/experimental{?dns}) > should now be draft-13 compliant. Please let me know if you find any other > problems with it. > > On Mon, Aug 13, 2018 at 8:54 AM Daniel Stenberg wrote: > >> Hi, >> >> I'm keeping a little list of public DoH servers [1]. Today I tried them >> all >> with my draft-13 compliant client and noticed that three out of seven >> servers >> in the list don't like "application/dns-message" as Content-Type, even >> though >> it's been documented since about the draft-07 time frame or so. >> >> This isn't ideal for interop. >> >> This email is just to highlight the situation and for me to beg that if >> you >> run such a server you update it soon so that we all play by the same book! >> >> Thanks, >> >> [1] = >> >> https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers >> >> -- >> >> / daniel.haxx.se >> >> _______________________________________________ >> 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 > --0000000000002709260573df98e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
\o/
Thanks Ben!

On Mon, Aug 20, 2018 at = 7:54 AM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
Our experimental service (https://dns.googl= e.com/experimental{?dns}) should now be draft-13 compliant.=C2=A0 Pleas= e let me know if you find any other problems with it.

On Mon, Aug 13, 2018 at 8:54 AM Daniel St= enberg <daniel@haxx.= se> wrote:
Hi,

I'm keeping a little list of public DoH servers [1]. Today I tried them= all
with my draft-13 compliant client and noticed that three out of seven serve= rs
in the list don't like "application/dns-message" as Content-T= ype, even though
it's been documented since about the draft-07 time frame or so.

This isn't ideal for interop.

This email is just to highlight the situation and for me to beg that if you=
run such a server you update it soon so that we all play by the same book!<= br>
Thanks,

[1] =3D
https://github.com/curl/c= url/wiki/DNS-over-HTTPS#publicly-available-servers

--

=C2=A0 / daniel.haxx.se

_______________________________________________
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
--0000000000002709260573df98e9-- From nobody Mon Aug 20 09:23: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 F4209131016; Mon, 20 Aug 2018 09:23:15 -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 c_weRTnUPu0k; Mon, 20 Aug 2018 09:23: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 8D7A9130FA3; Mon, 20 Aug 2018 09:23:14 -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 w7KGMBsc094813 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Aug 2018 11:22:20 -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: Sebastiaan Deckers , shane@time-travellers.org Cc: dnsop@ietf.org, doh@ietf.org, driu@ietf.org, ietf-http-wg@w3.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: Adam Roach Message-ID: <3cd27f5d-55d7-60f5-afc5-95a79b83a7f7@nostrum.com> Date: Mon, 20 Aug 2018 11:22:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.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] 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, 20 Aug 2018 16:23:22 -0000 On 8/20/18 6:39 AM, Sebastiaan Deckers wrote: > > > Action: Adam Roach will set up a mailing list. > > Where? (With apologies for the cross post.) Apologies -- this fell between the cracks. I have a request in to create the list now, and will respond to this message with further information when it is set up. /a From nobody Mon Aug 20 09:34:36 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 4347C1286E3; Mon, 20 Aug 2018 09:34:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , doh@ietf.org, adam@nostrum.com, Benjamin Schwartz , bemasc@google.com, doh-chairs@ietf.org, draft-ietf-doh-dns-over-https@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <153478286126.23086.9546471423320153102.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2018 09:34:21 -0700 Archived-At: Subject: [Doh] Protocol Action: 'DNS Queries over HTTPS (DoH)' to Proposed Standard (draft-ietf-doh-dns-over-https-14.txt) 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: Mon, 20 Aug 2018 16:34:22 -0000 The IESG has approved the following document: - 'DNS Queries over HTTPS (DoH)' (draft-ietf-doh-dns-over-https-14.txt) as Proposed Standard This document is the product of the DNS Over HTTPS Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ Technical Summary This document defines a protocol for performing DNS Queries over an HTTPS connection. This protocol offers similar security benefits to DNS-over-TLS (RFC 7858), and also allows integration with HTTP-based systems and services. Working Group Summary The document has been reviewed thoroughly within the working group, including extensive commentary by noted standards experts and large-scale implementors in DNS and HTTP. Document Quality Implementation has begun, with a large-scale deployment by Cloudflare, experiments by Mozilla and Google, and many independent implementations: doh-proxy (an IETF hackathon output), Go DNS, dnscrypt-proxy, doh-php-client, jDnsProxy, rust-doh, and dns-over-https. The maintainers of Stubby, CURL, and PowerDNS’s dnsdist have developed working prototypes. This draft has a single IANA consideration (defining the “application/dns-message” media type). There has been extensive review of this media type. Personnel The document shepherd is Benjamin Schwartz The responsible area director is Adam Roach From nobody Mon Aug 20 10:39: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 1042D130E6F; Mon, 20 Aug 2018 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 WCE6HqvQ5l29; Mon, 20 Aug 2018 10:38:51 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010080.outbound.protection.outlook.com [40.92.10.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F78F130E30; Mon, 20 Aug 2018 10:38:51 -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=BVlak1CgSGp4T3DUZdUfrfCbKc9ob4GrBXRbtl9ynk4=; b=CKdQWdAxP684Z++xFTOsGoMU18UzTAhCtPOuSMgY4Q1i38Tma6nALSXEK5ESxCTapbNx9+qTLZdEDkTijCPs3YexuJAPRYwm9WlgoMSNQL+2NhxoduWac8nCYiXL0iQCtTOWRoZPGbVDWBcZslVNn94SWFnxTRsqM9aVCX2WPYWtXTKO8K46W207tp9wTF0AzLdEyeEAAP2PuUrJ6JGo9eH19CSAD4/gVfbCNiZWV7JW8izosPY6gKnTKpg4MbhzndmVwjpR1rS43XGF4GjjJB9rLsc62YPupgejNv3XWWvNnT0y4LJcjUzyEyZFpspa9/OpGUnIW4cJ45r4/IZqnA== Received: from SN1NAM04FT004.eop-NAM04.prod.protection.outlook.com (10.152.88.52) by SN1NAM04HT243.eop-NAM04.prod.protection.outlook.com (10.152.89.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1080.9; Mon, 20 Aug 2018 17:38:49 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com (10.152.88.51) by SN1NAM04FT004.mail.protection.outlook.com (10.152.88.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1080.9 via Frontend Transport; Mon, 20 Aug 2018 17:38:49 +0000 Received: from BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1]) by BYAPR19MB2248.namprd19.prod.outlook.com ([fe80::7503:33f4:3a67:2cc1%3]) with mapi id 15.20.1059.023; Mon, 20 Aug 2018 17:38:49 +0000 From: Star Brilliant To: The IESG , IETF-Announce CC: "doh@ietf.org" , "adam@nostrum.com" , "bemasc@google.com" , The IESG , "doh-chairs@ietf.org" , "draft-ietf-doh-dns-over-https@ietf.org" , "rfc-editor@rfc-editor.org" Thread-Topic: [Doh] Protocol Action: 'DNS Queries over HTTPS (DoH)' to Proposed Standard (draft-ietf-doh-dns-over-https-14.txt) Thread-Index: AQHUOKPRc8OoBArTs0OQmey2w9EmOqTI5jaH Date: Mon, 20 Aug 2018 17:38:49 +0000 Message-ID: References: <153478286126.23086.9546471423320153102.idtracker@ietfa.amsl.com> In-Reply-To: <153478286126.23086.9546471423320153102.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1004787F578D0A85ECEDFA547510DBEDC981F54EC60AA2B0162C40592923D7C9; UpperCasedChecksum:13359C3E29DA41BAC2ED1BF8EB011E1DFD5A3E2A0F78AE3149A423E37B60D5BB; SizeAsReceived:7642; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [9of56xfcwNR97m/F4fAfg79cfhpZdxnE4r9RKL3b3BGFoOvQcH+JWA==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM04HT243; 6:ujB+oxdl2lFLhD6RxsdzmWS+VRlS/8e4R54iptIcLlEP8htw6NIjcS+A4ma7kHuVFOpmWUyFiQ/C1DO+CZXvSlPaD60CFpFxQE2MbVHhhnktQ/3CHQaN3FtCT0N0u+9SdeDsQhoK1fBURi+bqiA2BZgpR7DWYXyvTSxsnRo1wJXsDXotnO8VYJT0+1Vymw1Gtgjt6gODPo7oDm0C7D7Wwp7l/G3Rg2LsU09BMjuIHbp5nEVzbLeOrEiFh+bzmczq04YEPeS5kzB2+PHtqdjtWMu7xC6W5vZFgCmYUWvA65ztdaufa3/xG31LjL8Dr6P4HHQfHB7QBhw85Vg2bZdnc56aRMxQCX0PZxBxPPok8G/xhLDJrDTgILuZUWP62rzy16+aujxQTl5oK6tvc2EFEwbm5X0eMAu/oi1vGM7ZZ9xuUTkH6b9d45l5keeWg+bSTlZ3KBwjQSgwdvnzrq127w==; 5:fuEgPM69Wm2umXCMBkQ43morUsnYM/am4bztxH3ZTxsb5jBSjy8v1TKmdFS6BNw+e3UwasnCcWfLpOBu1ZVmDp+lxzH2r9szeIHRcLY0M+TF2Wof/ukr6xcHvp9+CK429Nw54tFmxWyeeyqOZ5ClC+9WSzA81dwZj1gcO5ARLQw=; 7:/7lxMlZhF+nv9mG3mUCaqx04k6auw/LJVGtiFo/p3lV+ssP6Zfe6gOhtDRA2CnfaeNQsp+KJdYuuVSL0pxAxUttZKi5ATwpnU0hfc+/SFbNXTOwo/4dwLEM+hYUYIBO3ph7XJ9Z+MDYyxJwkupvW9gLsXJXByMtNmVTzeOFexbfwS8KO7wV9LlHRGuvpSI+aiZ88JBCY53pN6xnAKxThu0y3Klp3a+QH3rabuNkcYjAYvXy19Do5PedmhEXfd+c0 x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:SN1NAM04HT243; x-ms-traffictypediagnostic: SN1NAM04HT243: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM04HT243; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT243; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(53546011)(4326008)(305945005)(8676002)(68736007)(105586002)(106356001)(81156014)(14444005)(11346002)(256004)(86362001)(446003)(56003)(486006)(110136005)(54906003)(33656002)(8936002)(6506007)(104016004)(5250100002)(102836004)(6246003)(6346003)(97736004)(14454004)(7696005)(2900100001)(76176011)(74316002)(87572001)(966005)(25786009)(5660300001)(6306002)(82202002)(55016002)(46003)(73972006)(229853002)(99286004)(6436002)(20460500001)(476003)(83332001)(9686003)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM04HT243; H:BYAPR19MB2248.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: CMr7blRzxPa7MAerqyZnnlXIAGlqzz0r4MiZBarVxSjY3c7AyAhSAu3qOynTQFR6RC0RTLLCQfTdT5vWS6QU6WbEkogFalimei3CyD5+JSl90UXweQau+lu0b1VXpg3UHQGrucu/a0/vSsaQRTzgf7/c6nYbU9nEvHeo34QN5lL/56516qZ6uTlaVvY9fimqZNRXlRQw1ri1c6rHqsIoWfd15ip8+sVrDOO8nZB+7qU= 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: fdce1c86-b428-4ceb-8dd0-08d606c3c9eb X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2018 17:38:49.5082 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT243 Archived-At: Subject: Re: [Doh] Protocol Action: 'DNS Queries over HTTPS (DoH)' to Proposed Standard (draft-ietf-doh-dns-over-https-14.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: Mon, 20 Aug 2018 17:38:54 -0000 On Tue, Aug 21, 2018 at 2:35 AM The IESG wrote: > > The IESG has approved the following document: > - 'DNS Queries over HTTPS (DoH)' > (draft-ietf-doh-dns-over-https-14.txt) as Proposed Standard > > This document is the product of the DNS Over HTTPS Working Group. > > The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell= . > > A URL of this Internet Draft is: > https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/ > Hi, Glad to hear the approval! By the way, Paul, do you plan to fix the spelling and grammatical issues th= at I mentioned in my previous mail? I am not sure if we might miss the chan= ce. Best regards, Star Brilliant On Fri, Aug 17, 2018 at 4:22 AM Star Brilliant wrote: > > > On Page 6, Paragraph 2, Section 4.2: > > [...] The amount and type of information that a media type gives is solel= y up to the format, and not defined in this protocol. > > s/is/are/ > > > > On Page 8, Paragraph 3, Section 5.1: > > [...] This requirement helps prevent exipred RRsets in messages in an HTT= P cache from unintentionally being served. > > s/exipred/expired/ > > > > On Page 4, Paragraph 5, Section 4.1: > > [...] When using the POST method the DNS query is included as the message= body [...] > > (Minor issue) I suggest a comma (,) followed by "method". But okay if kee= p untouched. From nobody Mon Aug 20 11:37: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 B8AB212872C for ; Mon, 20 Aug 2018 11:37:08 -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 UQik7GNWxIic for ; Mon, 20 Aug 2018 11:37:07 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6232512426A for ; Mon, 20 Aug 2018 11:37:07 -0700 (PDT) Received: from [10.32.60.117] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w7KIae56035493 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 20 Aug 2018 11:36:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.117] From: "Paul Hoffman" To: "Star Brilliant" Cc: doh@ietf.org Date: Mon, 20 Aug 2018 11:37:03 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: In-Reply-To: References: <153478286126.23086.9546471423320153102.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Doh] Protocol Action: 'DNS Queries over HTTPS (DoH)' to Proposed Standard (draft-ietf-doh-dns-over-https-14.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: Mon, 20 Aug 2018 18:37:09 -0000 (Removing the people who don't need to see the answer to this question) On 20 Aug 2018, at 10:38, Star Brilliant wrote: > By the way, Paul, do you plan to fix the spelling and grammatical > issues that I mentioned in my previous mail? I am not sure if we might > miss the chance. We will not "miss the chance" because the RFC Editor will fix those during their review. --Paul Hoffman From nobody Mon Aug 20 11:40: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 ABE63130E3A; Mon, 20 Aug 2018 11:29:11 -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 oQsmU1p0_XlA; Mon, 20 Aug 2018 11:29:10 -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 6A909129619; Mon, 20 Aug 2018 11:29:10 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 3235525FB6; Mon, 20 Aug 2018 14:29:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23419.2164.187917.67077@gro.dd.org> Date: Mon, 20 Aug 2018 14:29:08 -0400 From: Dave Lawrence To: Star Brilliant Cc: The IESG , IETF-Announce , "doh\@ietf.org" , "adam\@nostrum.com" , "bemasc\@google.com" , The IESG , "doh-chairs\@ietf.org" , "draft-ietf-doh-dns-over-https\@ietf.org" , "rfc-editor\@rfc-editor.org" In-Reply-To: References: <153478286126.23086.9546471423320153102.idtracker@ietfa.amsl.com> Archived-At: X-Mailman-Approved-At: Mon, 20 Aug 2018 11:40:10 -0700 Subject: Re: [Doh] Protocol Action: 'DNS Queries over HTTPS (DoH)' to Proposed Standard (draft-ietf-doh-dns-over-https-14.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: Mon, 20 Aug 2018 18:29:12 -0000 Star Brilliant writes: > By the way, Paul, do you plan to fix the spelling and grammatical > issues that I mentioned in my previous mail? I am not sure if we > might miss the chance. There's a final stage at the RFC Editor where that can be handled. From nobody Mon Aug 20 12:16: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 2C084130DC6; Mon, 20 Aug 2018 12:16:40 -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 S-24hp0Px3q5; Mon, 20 Aug 2018 12:16:38 -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 B3D44129619; Mon, 20 Aug 2018 12:16:38 -0700 (PDT) Received: from Svantevit.roach.at (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 w7KJGZIe024055 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 20 Aug 2018 14:16:36 -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.roach.at From: Adam Roach To: Sebastiaan Deckers , shane@time-travellers.org Cc: dnsop@ietf.org, doh@ietf.org, driu@ietf.org, ietf-http-wg@w3.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> <3cd27f5d-55d7-60f5-afc5-95a79b83a7f7@nostrum.com> Message-ID: Date: Mon, 20 Aug 2018 14:16:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <3cd27f5d-55d7-60f5-afc5-95a79b83a7f7@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 20 Aug 2018 19:16:40 -0000 On 8/20/18 11:22 AM, Adam Roach wrote: > On 8/20/18 6:39 AM, Sebastiaan Deckers wrote: >> >> > Action: Adam Roach will set up a mailing list. >> >> Where? (With apologies for the cross post.) > > > Apologies -- this fell between the cracks. I have a request in to > create the list now, and will respond to this message with further > information when it is set up. The list is now ready to go. Subscription information is available at https://www.ietf.org/mailman/listinfo/http-srv /a From nobody Tue Aug 21 07:09:25 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612FF130DD0 for ; Tue, 21 Aug 2018 07:09:23 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 rP0NbDsgO99M for ; Tue, 21 Aug 2018 07:09:21 -0700 (PDT) Received: from xs.powerdns.com (xs.powerdns.com [82.94.213.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D943129385 for ; Tue, 21 Aug 2018 07:09:20 -0700 (PDT) Received: from server.ds9a.nl (unknown [86.82.68.237]) by xs.powerdns.com (Postfix) with ESMTPS id 0D5B39FB55; Tue, 21 Aug 2018 14:09:17 +0000 (UTC) Received: by server.ds9a.nl (Postfix, from userid 1000) id 22825AC6B8C; Tue, 21 Aug 2018 16:09:17 +0200 (CEST) Date: Tue, 21 Aug 2018 16:09:17 +0200 From: bert hubert To: Daniel Stenberg , DoH WG Message-ID: <20180821140917.GA14352@server.ds9a.nl> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 21 Aug 2018 14:09:23 -0000 The PowerDNS dnsdist experimental DNS over HTTPS service is now also up: https://doh.powerdns.org/{?dns} It runs to the dnsdist branch that can be found on https://github.com/ahupowerdns/pdns/tree/dnsdist-doh Configuration: addDOHLocal("136.144.215.158:443", "/etc/letsencrypt/live/doh.powerdns.org/fullchain.pem", "/etc/letsencrypt/live/doh.powerdns.org/privkey.pem") It is compliant with the latest version of the draft, and interoperates with Firefox nightly. The service may be unavailable from time to time, but I use it for most of my own web browsing, so there is sort of an SLA on it ;-) If there are any problems, please let me know. Bert On Mon, Aug 20, 2018 at 10:53:45AM -0400, Ben Schwartz wrote: > Our experimental service (https://dns.google.com/experimental{?dns}) should > now be draft-13 compliant. Please let me know if you find any other > problems with it. > > On Mon, Aug 13, 2018 at 8:54 AM Daniel Stenberg wrote: > > > Hi, > > > > I'm keeping a little list of public DoH servers [1]. Today I tried them > > all > > with my draft-13 compliant client and noticed that three out of seven > > servers > > in the list don't like "application/dns-message" as Content-Type, even > > though > > it's been documented since about the draft-07 time frame or so. > > > > This isn't ideal for interop. > > > > This email is just to highlight the situation and for me to beg that if > > you > > run such a server you update it soon so that we all play by the same book! > > > > Thanks, > > > > [1] = > > https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers > > > > -- > > > > / daniel.haxx.se > > > > _______________________________________________ > > 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 Tue Aug 21 13:30: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 71ACB130DF7 for ; Tue, 21 Aug 2018 13:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 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, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elkD6D0oJwtu for ; Tue, 21 Aug 2018 13:30:51 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 87E88128CB7 for ; Tue, 21 Aug 2018 13:30:51 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id s7-v6so95289itb.4 for ; Tue, 21 Aug 2018 13:30:51 -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=sE1oAasXESYMgZ7x1G4ahXC/yR9UB+0O/hQxawszVNc=; b=f2fzyo6z2+ceQ9Y1oodSdJLmx1zLxpPWtIcPloyqmgEO3iYtVTOzXsuJPUD1xsloiP Wv/fgcIVsQGyQqVN5AkadpaUbdP7TkIDvA2bXo0904n571ycWhhU5H5F6J7VfwDP9vsf EwikK4TlpmBmcf3V92uiuzzwiexluW4p1lBoQKx4KOZFLiauxtnvb9KxLVE1bv7GoaZO PRDdqVMegvQv6TVmECdCrwJpWVBhLXEzIWDV1F+Qc5T14tNNBaCPNo5JjiVZZ6qeoQsa aaJzQkKkX2VTbmuNWLrorFYGYtgfBLC4XsxGGj/l+BZ7qc4gSB5Mlz5RdknaBd6bPtd1 YyHQ== 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=sE1oAasXESYMgZ7x1G4ahXC/yR9UB+0O/hQxawszVNc=; b=CMyOU7lqkQSbVm6FSBzWWTrKRqZ5IEeWiuuh4FNYE643kzFnVeBq9WdYd3qzaD7e+Z qUHjYANvWzKa0nrq2utPPK4yL1ePcOdUqbHfqFQ/0Pah/qG9L4DIW1eA2dr0g/Fb+nUG j3311tdm1E2B8Piw5oR4gAtp8QagV9heH9mxl0Y6Kh3h4fDTyroege5NoQIbrMmQM/pT tYPcFMySN75BPYQSgmjOT5YBhlLkgiOxB1nsHtdctLMbtW093bSUGkF5unQ7sifoBEdZ I7CYpWfNuOgKBkq4iX09QwzOBFjJqf+HXu0eiE4n0jTfYNOW0FN+7S2BUc9PLMm5sliM etMg== X-Gm-Message-State: APzg51BYIQV3/KRZp5NAOJxe+g+NQNkHFitPkzlJCGfn1THUMCDVTVjb 7f9G6B8WsyQndQfz59gAIa5Fo5P/XrQEHExmqgoMWT6A X-Google-Smtp-Source: ANB0VdaaDOwfraPW+tAB2kCjVMBD2pvJVoZ1fhy/bxYAHdCUfUC8a8I/m7Rf9uvptoW7VVo2u6cpmVQWDuGBGQUWdII= X-Received: by 2002:a24:250f:: with SMTP id g15-v6mr876881itg.108.1534883450719; Tue, 21 Aug 2018 13:30:50 -0700 (PDT) MIME-Version: 1.0 References: <20180821140917.GA14352@server.ds9a.nl> In-Reply-To: <20180821140917.GA14352@server.ds9a.nl> From: manu tman Date: Tue, 21 Aug 2018 13:30:39 -0700 Message-ID: To: bert hubert Cc: Daniel Stenberg , DoH WG Content-Type: multipart/alternative; boundary="000000000000da141d0573f7e676" Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 21 Aug 2018 20:30:55 -0000 --000000000000da141d0573f7e676 Content-Type: text/plain; charset="UTF-8" Great stuff! I have added some integration test between doh-proxy's stub code and the known servers: https://github.com/facebookexperimental/doh-proxy/commit/9bb8ef2835832d3c2f3113652e00a919486afa91 Currently, it is only failing against SecureDNS.eu (timeout) CleanBrowsing (seems to not support draft-13 yet) Otherwise, it is passing the rest of the publicly known servers from https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers Manu On Tue, Aug 21, 2018 at 7:09 AM bert hubert wrote: > The PowerDNS dnsdist experimental DNS over HTTPS service is now also up: > > https://doh.powerdns.org/{?dns} > > It runs to the dnsdist branch that can be found on > https://github.com/ahupowerdns/pdns/tree/dnsdist-doh > > Configuration: > > addDOHLocal("136.144.215.158:443", > "/etc/letsencrypt/live/doh.powerdns.org/fullchain.pem", > "/etc/letsencrypt/live/doh.powerdns.org/privkey.pem") > > It is compliant with the latest version of the draft, and interoperates > with > Firefox nightly. > > The service may be unavailable from time to time, but I use it for most of > my own web browsing, so there is sort of an SLA on it ;-) > > If there are any problems, please let me know. > > Bert > > On Mon, Aug 20, 2018 at 10:53:45AM -0400, Ben Schwartz wrote: > > Our experimental service (https://dns.google.com/experimental{?dns}) > should > > now be draft-13 compliant. Please let me know if you find any other > > problems with it. > > > > On Mon, Aug 13, 2018 at 8:54 AM Daniel Stenberg wrote: > > > > > Hi, > > > > > > I'm keeping a little list of public DoH servers [1]. Today I tried them > > > all > > > with my draft-13 compliant client and noticed that three out of seven > > > servers > > > in the list don't like "application/dns-message" as Content-Type, even > > > though > > > it's been documented since about the draft-07 time frame or so. > > > > > > This isn't ideal for interop. > > > > > > This email is just to highlight the situation and for me to beg that if > > > you > > > run such a server you update it soon so that we all play by the same > book! > > > > > > Thanks, > > > > > > [1] = > > > > https://github.com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers > > > > > > -- > > > > > > / daniel.haxx.se > > > > > > _______________________________________________ > > > 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 > --000000000000da141d0573f7e676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great stuff!

I have added some inte= gration test between doh-proxy's stub code and the known servers:
=
https://github.com/facebookexperime= ntal/doh-proxy/commit/9bb8ef2835832d3c2f3113652e00a919486afa91

Currently, it is only failing against
SecureDNS.eu = (timeout)
CleanBrowsing (seems to not support draft-13 yet)
=

Otherwise, it is passing the rest of the publicly known= servers from=C2=A0https://github.com/curl/curl/wiki/DNS-over-= HTTPS#publicly-available-servers

Manu

On Tue, Aug 21, 2018 at = 7:09 AM bert hubert <bert.hu= bert@powerdns.com> wrote:
Th= e PowerDNS dnsdist experimental DNS over HTTPS service is now also up:

https://doh.powerdns.org/{?dns}

It runs to the dnsdist branch that can be found on
https://github.com/ahupowerdns/pdns/tree/dnsdist= -doh

Configuration:

addDOHLocal("136.144.215.158:443",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "/etc/letsencrypt/live/doh.pow= erdns.org/fullchain.pem",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "/etc/letsencrypt/live/doh.power= dns.org/privkey.pem")

It is compliant with the latest version of the draft, and interoperates wit= h
Firefox nightly.

The service may be unavailable from time to time, but I use it for most of<= br> my own web browsing, so there is sort of an SLA on it ;-)

If there are any problems, please let me know.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bert

On Mon, Aug 20, 2018 at 10:53:45AM -0400, Ben Schwartz wrote:
> Our experimental service (https://dns.google.com/e= xperimental{?dns}) should
> now be draft-13 compliant.=C2=A0 Please let me know if you find any ot= her
> problems with it.
>
> On Mon, Aug 13, 2018 at 8:54 AM Daniel Stenberg <daniel@haxx.se> wrote:
>
> > Hi,
> >
> > I'm keeping a little list of public DoH servers [1]. Today I = tried them
> > all
> > with my draft-13 compliant client and noticed that three out of s= even
> > servers
> > in the list don't like "application/dns-message" as= Content-Type, even
> > though
> > it's been documented since about the draft-07 time frame or s= o.
> >
> > This isn't ideal for interop.
> >
> > This email is just to highlight the situation and for me to beg t= hat if
> > you
> > run such a server you update it soon so that we all play by the s= ame book!
> >
> > Thanks,
> >
> > [1] =3D
> > https://github.= com/curl/curl/wiki/DNS-over-HTTPS#publicly-available-servers
> >
> > --
> >
> >=C2=A0 =C2=A0/ daniel.haxx.se
> >
> > _______________________________________________
> > 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
--000000000000da141d0573f7e676-- From nobody Tue Aug 21 14:01: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 311D0130E89 for ; Tue, 21 Aug 2018 14:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tha3n9IoEt71 for ; Tue, 21 Aug 2018 14:01:32 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id D4F44130DE0 for ; Tue, 21 Aug 2018 14:01:31 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w7LL1SxL025817 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Aug 2018 23:01:28 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w7LL1Rae025812; Tue, 21 Aug 2018 23:01:27 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Tue, 21 Aug 2018 23:01:27 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: manu tman cc: bert hubert , DoH WG In-Reply-To: Message-ID: References: <20180821140917.GA14352@server.ds9a.nl> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 21 Aug 2018 21:01:35 -0000 On Tue, 21 Aug 2018, manu tman wrote: > CleanBrowsing (seems to not support draft-13 yet) This one actually "works" with my test draft-13 client but it takes 15(!) seconds to respond... -- / daniel.haxx.se From nobody Tue Aug 21 15:00: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 BB83A130E93 for ; Tue, 21 Aug 2018 15:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENLXUav503Lw for ; Tue, 21 Aug 2018 15:00:09 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254E9127332 for ; Tue, 21 Aug 2018 15:00:09 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id j81-v6so445881ite.0 for ; Tue, 21 Aug 2018 15:00:09 -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=HN0ExyxfCaLMaOnLYrd0FmRoFP2RyS51lkHNtSh/41E=; b=Ye4mDHTlpj2oVj8mECH+dAx98FROrT5TrZyl2x72oKkszu2B1MMuufF6xw6WsCHnxi aHrHm2jUZw9pepuRCIJtP7qnDJyIV26NJFWwmA5sjNzvAz+WisGsu9lf82MlUAqzTnS+ acveNgFhaG5YXqefgcPOVmNJQRSfQHH7LDWKSEGzAw5XkZmayBLarNviE7VbHneCcYgL LLmmC9chfxV5PKkNCHsVqfUe4CRQRY9gYWJOyJl6FQX7d4qCGCKwPwhBqC26fGdEV+t/ MCKyvae+mVD3MUpE7NqcAE6WQSwgwoQkH7ZzBlnZg+eu2R6QCfmX+Tl/kHlMbxbKUpdG kmJQ== 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=HN0ExyxfCaLMaOnLYrd0FmRoFP2RyS51lkHNtSh/41E=; b=ALXOZoebiSCEwo43t/yr09nKp6Fk3vV03s20DMlrDEf8zaK4ppwlnnD7crJ7ORAVNs yIAOod0D8i96Z8JK6Q7t+xEdeI4BZLl578XsEwh80t0Uou8KXG6/7Yfsk/cnYFJAiFti buJM+Je+VkOmjdYl9bEwpOS8XXIO99QKzZLhlzOYajT+I7XnQ1voQv5nemDv3e1mw2G6 C5JlfeefszAEdvlo9I7N1vLLwA72Ep/naytSaRjdcvId4LfaFYbZZG1HU2TnrgX7XHb/ LHdD99yJCEuAHdtWlvEwcT9KBFYPNt50j8hC55p4oxHHMSBKMs+p8NPoGbNBIYT1rCPT mSKA== X-Gm-Message-State: AOUpUlFBN9j6XcU8uGMyWSR1/C8fGFDfABKP1tx8DHJmLnEzTeRqceHc oP3PAAlgTfZRzI6UuOqTjFtnwIU4ptcUNoUdMkcsdFt8 X-Google-Smtp-Source: AA+uWPwVyBgm8Bnwzsos4UYpNlmH6M1F+rz0vyrKlJesoqVx3a7QhbNKhYW54W9+B7UOkXPy2Cf701f6oFVZigDHHR4= X-Received: by 2002:a02:898d:: with SMTP id p13-v6mr46821848jaj.74.1534888808321; Tue, 21 Aug 2018 15:00:08 -0700 (PDT) MIME-Version: 1.0 References: <20180821140917.GA14352@server.ds9a.nl> In-Reply-To: From: manu tman Date: Tue, 21 Aug 2018 14:59:57 -0700 Message-ID: To: Daniel Stenberg Cc: bert hubert , DoH WG Content-Type: multipart/alternative; boundary="000000000000309a680573f926f3" Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 21 Aug 2018 22:00:11 -0000 --000000000000309a680573f926f3 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 21, 2018 at 2:01 PM Daniel Stenberg wrote: > On Tue, 21 Aug 2018, manu tman wrote: > > > CleanBrowsing (seems to not support draft-13 yet) > > This one actually "works" with my test draft-13 client but it takes 15(!) > seconds to respond... > oh... my bad, I forgot the trailing `/`... https://github.com/facebookexperimental/doh-proxy/commit/5115c524b0e695abd40f08c37218fb57276cbd5e > > -- > > / daniel.haxx.se > --000000000000309a680573f926f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Aug 21, 2018 at 2:01 PM Daniel Stenberg <daniel@haxx.se> wrote:
On Tue, 21 Aug 2018, manu tman wrote:

> CleanBrowsing (seems to not support draft-13 yet)

This one actually "works" with my test draft-13 client but it tak= es 15(!)
seconds to respond...

<facepalm><= /div>
oh... my bad, I forgot the trailing `/`...=C2=A0https://github.com/facebookexperimental/doh-proxy/commit/= 5115c524b0e695abd40f08c37218fb57276cbd5e
</facepalm>=C2=A0

--

=C2=A0 / daniel.haxx.se
--000000000000309a680573f926f3-- From nobody Tue Aug 21 15:29: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 5444E130DD6 for ; Tue, 21 Aug 2018 15:29:33 -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 CqO5C7t-8N7e for ; Tue, 21 Aug 2018 15:29:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-oln040092008050.outbound.protection.outlook.com [40.92.8.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78F3130DCA for ; Tue, 21 Aug 2018 15:29:31 -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=wZRsyptPTwlOwZ/pxxOVy6xXcbdCShzzcqcyQz2peko=; b=C/SKRD1oFE+WVJTkEAod0/AlsJ1fO8Yi8AbFSEGYk5OCrRGGHJe+rh/pj2vP37BqGnt4Q20l4QYk3ZvzQZtP6ZJL8OP+F8dOH/217zqDnUlh/7wsJNf453ppmmg2ugFIQNsoZxH/DtB1TKY2uIVrFfyWFpDd9pCnHl/BMQcA+7QIsCnCvEozTGobgYcJtpVkXxj2qE+k/j+JcWC/UHbkcFs/nw1M2K8TbgoP7Yw7gT+twGWO7ab/+3EfPK0K5diX9FtlTFpZok4j1GSPItSaJiH6bPEl7d7T/kO7pIiYsuXIIw+eE9FAztMKgpE4hPQcY2q/G6SGRTknlVADVJp7jQ== Received: from DM3NAM03FT009.eop-NAM03.prod.protection.outlook.com (10.152.82.59) by DM3NAM03HT022.eop-NAM03.prod.protection.outlook.com (10.152.82.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.1080.9; Tue, 21 Aug 2018 22:29:30 +0000 Received: from DM6PR19MB2249.namprd19.prod.outlook.com (10.152.82.58) by DM3NAM03FT009.mail.protection.outlook.com (10.152.82.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.1080.9 via Frontend Transport; Tue, 21 Aug 2018 22:29:30 +0000 Received: from DM6PR19MB2249.namprd19.prod.outlook.com ([fe80::a0c9:1de1:77a6:e73a]) by DM6PR19MB2249.namprd19.prod.outlook.com ([fe80::a0c9:1de1:77a6:e73a%6]) with mapi id 15.20.1059.023; Tue, 21 Aug 2018 22:29:29 +0000 From: Star Brilliant To: DoH WG CC: bert hubert Thread-Topic: [Doh] Public endpoints to draft-13 please? Thread-Index: AQHUMwTSqsinU1W9MUStrbFFHbf9E6TIxSaAgAGF6ICAAIte4Q== Date: Tue, 21 Aug 2018 22:29:29 +0000 Message-ID: References: , <20180821140917.GA14352@server.ds9a.nl> In-Reply-To: <20180821140917.GA14352@server.ds9a.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:1AB37F155D0FD277615FF8D836647C43B87931FFAAA7FC6ED49CC0FBDB5D60B9; UpperCasedChecksum:104F54D70D4A6D800EEEDDB0FC89B073C31E757D77B912A1A45B121A6F153C59; SizeAsReceived:7142; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [ySZl34D7tdjTM7/Ha8WibhnltMNv4JQ9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM3NAM03HT022; 6:Yu8PphkbBjJS0mjXkyxHFI/LpZi6xzpq1lyJpEuclh+ATDmm335CMoQj5kdSIDoM1FUBtuzjbaM5+gXvOU3YblvPNIlXeUhWjJWJchOfDCqcIqaYA+c75bYE67HCwlecke5fR6V+7e6OCLCj/PZu55CgEy2SUkwXg59J2eObVv2C2WL/0+nYdOW+Lp1v6Kof0cPe9pkSS79khsK7+YYQSjrKXWlcrBKMXcNn5RJ+Kk+v7icKxO5K4wBdGExaTXTNnSCNXBNbD4gyOR4/9s2sic/VfQQ9y02xB+rQ4EIc86GyfkxCmXeE9Lc3Z0LtRJmIzsuXcrwu1kyKaTw4bxqB9xXEY0KAX3N0vROGE7OLJH4feXlZfCghfab0ujkvM+eU+AkEg+qk118sQxKYQIDAUkiZcqvD1/qMRPeI4XeAJOmQ2JAm/c/S2ci08in7A0SUGaXTX6zdMbYpY6qka7E9EQ==; 5:sQYtuDKTq1KWcn0x4jSyCxcHnOw+tSNtq4OcifiS5H+fHuXRH6ahpMJzg+mPXDJL/m9oaksxP6F5y8EedYdTazARe96setAM0MYG5Y9v8A4vWaEiPCSW6+232D+BfjZzW59zorXNbwu85qJnBR0aA503J3N/usGiTXahffKtxFk=; 7:0hgMslV62aPCFXaBSPqtkPIfnvbY7JbFVJ/dEau3k8toAPPdXX8c/kFN0WhyrHWfPtT66ztRfomtbQ8zzEYv7CsVwa7VlZuaaCTJzrVygeZLaMPAOh4kn4DpUssAHSdogsLppRBU9ScGUQcBVxfmb5/5pMcTr6t0jQSEjupIVGCsG8FxHxp7ZzK2Y/LsX61KukCsRPyqALsDJqA3B3/d4rldbEGsQyg6pAIzsDojrZm8yN68Ria02PAUTF7HSmBh x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:DM3NAM03HT022; x-ms-traffictypediagnostic: DM3NAM03HT022: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:DM3NAM03HT022; BCL:0; PCL:0; RULEID:; SRVR:DM3NAM03HT022; x-forefront-prvs: 0771670921 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(189003)(199004)(55016002)(6306002)(5250100002)(99286004)(14444005)(6246003)(6916009)(256004)(104016004)(5660300001)(20460500001)(14454004)(87572001)(6436002)(966005)(229853002)(4326008)(486006)(83332001)(56003)(6346003)(86362001)(106356001)(68736007)(81156014)(73972006)(446003)(575784001)(74316002)(105586002)(76176011)(82202002)(11346002)(25786009)(476003)(8676002)(2900100001)(8936002)(7696005)(33656002)(26005)(9686003)(53546011)(102836004)(6506007)(345774005)(97736004)(305945005)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:DM3NAM03HT022; H:DM6PR19MB2249.namprd19.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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: 1yqbl4eEiMB6Ku9/iaPeMEYlJ157EYZVlVxzcYAskh4Xotp04NCKZ5MyosBIjxwBpFJ7njeYVZnW3XQbXEL8FISRxwJKAchICk9RjT6TaAUsygvjcAItHp8fGiEmURYvJAsinDIbjlBoaJnKgbFqX4AT/Du5umTagshe+bLvQarN4xfAd8nXe/bQRfGAmana5yndf+2hPtYyvgLMPKquyzP50I/bESbpq1tP2I9pV4U= 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: c5a0a662-3ef5-472e-434e-08d607b58fa1 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2018 22:29:29.9220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT022 Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 21 Aug 2018 22:29:33 -0000 On Wed, Aug 22, 2018 at 12:09 AM bert hubert wro= te: > > The PowerDNS dnsdist experimental DNS over HTTPS service is now also up: > > https://doh.powerdns.org/{?dns} > > It runs to the dnsdist branch that can be found on > https://github.com/ahupowerdns/pdns/tree/dnsdist-doh Hi Bert, It's great to see DoH support in PowerDNS! Thank you for your work! I have glanced the code and find that you have builtin EDNS Client Subnet s= upport. That's really awesome. I would like to know, does it support detecting ECS by X-Forwarded-For or X= -Real-IP header? (Seems not yet, through my glance at the code.) This featu= re might be useful when DoH server is behind an HTTP load balancer; or the = user uses DoH server outside their country to avoid nationwide Internet cen= sorship. An effective method is to search in the order of "dnsMsg.getECS(), X-Forwar= ded-For.each(), X-Real-IP, socket.getRemoteAddr()" and find the first avail= able global unicast IP. [1] (Or the policy can be customized or disabled wi= th Lua.) Another issue is the cipher blacklist. [2] HTTP/2 has blacklisted a large n= umber of cipher suites. [3] And since we don't need to be compatible, is it= okay just to blacklist TLSv1.0 and TLSv1.1 with older cipher suites and en= force PFS? Notes: [1]: My simple implementation: https://github.com/m13253/dns-over-https/blo= b/ea0a769389f177fb7279cbf2b434c781cd17bb05/doh-server/server.go#L189 [2]: Server test score by SSL Labs: https://www.ssllabs.com/ssltest/analyze= .html?d=3Ddoh.powerdns.org [3]: HTTP/2 cipher blacklist: https://http2.github.io/http2-spec/#BadCipher= Suites Best regards, Star Brilliant From nobody Wed Aug 22 04:36: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 600B9130E20 for ; Wed, 22 Aug 2018 04:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mpZoP8CJ63XW for ; Wed, 22 Aug 2018 04:36:50 -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 82BF4130DDA for ; Wed, 22 Aug 2018 04:36:50 -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]:59462) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1fsRRO-000Jvm-hm (Exim 4.91) (return-path ); Wed, 22 Aug 2018 12:36:46 +0100 Date: Wed, 22 Aug 2018 12:36:46 +0100 From: Tony Finch To: manu tman cc: bert hubert , DoH WG , Daniel Stenberg In-Reply-To: Message-ID: References: <20180821140917.GA14352@server.ds9a.nl> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Doh] Public endpoints to draft-13 please? 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, 22 Aug 2018 11:36:52 -0000 I've updated https://github.com/fanf2/doh101/ so it works with Firefox Nightly TRR. It's running on https://doh101.dev.dns.cam.ac.uk/{?dns} which is only accessible over IPv6 and is likely to go away soon when I have finished fiddling around with it. Tony. -- f.anthony.n.finch http://dotat.at/ Forties: West 5 or 6, becoming variable 3 or 4, then southwest 5 or 6 later. Slight or moderate. Rain at first. Good, occasionally poor at first. From nobody Thu Aug 30 23:28: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 E06BA130E12 for ; Thu, 30 Aug 2018 23:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zbGNcHfuGEvH for ; Thu, 30 Aug 2018 23:28:26 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9865412872C for ; Thu, 30 Aug 2018 23:28:26 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w7V6SMq2026685 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 31 Aug 2018 08:28:22 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w7V6SM7h026680 for ; Fri, 31 Aug 2018 08:28:22 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 31 Aug 2018 08:28:22 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: doh@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [Doh] URI Template 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, 31 Aug 2018 06:28:29 -0000 Hey, I've written three separate client-side DoH implementations by now and I'm mentoring a 4th. I don't get the use of URI Template in the spec. A template is meant to be used to describe how the URI can be made up and the DoH spec mandates the name 'dns' to be used for the DNS packet parameter when GET is used. There's no other URL parameters. Can a service then offer any other template than with a trailing '{?dns}' ? Like 'https://example.org/path{?dns}'. If it can provide other parts in the {} section, what is a generic client supposed to do with those? I'm probably just stupid. -- / daniel.haxx.se From nobody Fri Aug 31 05:58: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 D60C6130E52 for ; Fri, 31 Aug 2018 05:58:46 -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 kbqDivfTWN6I for ; Fri, 31 Aug 2018 05:58:45 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 75BC9130E48 for ; Fri, 31 Aug 2018 05:58:45 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 8-v6so21516712oip.0 for ; Fri, 31 Aug 2018 05:58:45 -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=0x3uKvM3Uhs+8lHbDG+VtnByolUxgLi0QStbvFTJV+Y=; b=loSSImDtGoYesYWg8xBzzVzY9rWIuQSWqrf5Vy57Rq+z8wN0WkLLdUBaUTcUFLzJ0x TEjbavwltAPfGHncw8OTKXsk6IZzPreTUYzjnHzwcUq6qxYjZ0BupnS1DQAVNMg7pRj4 dA5fSI8fhdM/NNBttIrp/mP1yoMwE7cilMhgp473/+KB3EET3A8VEFjLvRWSg0cdVV4y N1cqpudvG2Qp6Nm1WAxs3HbAzW02pbBbtM1NTPcG8Cpkmf7kuSODHg2dWsYhaXlIWtu3 M/TprqvP9hK53ycAn2aohbw5odfYVoZn0rwOTar14c20NNdlFFqbYfmgJYF3Dr72amAs 2OvA== 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=0x3uKvM3Uhs+8lHbDG+VtnByolUxgLi0QStbvFTJV+Y=; b=OHAQ9JpYhYcadD+QH5iTGo3ti/T7q6E9FTRZ2iAdGrwdSyzPGYs09CA9foMLVIMJcn 65w9qHvfRfqJqG6jFvCPiEyWskNd0XiXpDNLoMI0rMVL9IzL7dYTUvljWVJVECUcIlyT Jl2ux/fzHG6irmD6rCqxjIEcwCUGSAxGGaNARVxzqM+3S/1l6jiA7ly7uLwzJGycog26 gr70jAoVcoUtgBp5deF6Bcdht5viNGkFMFDSkfpPCCBAaIRks90agaGI4dJXg2KJtJyn GJ4DJjMRDsboLPK1MpHUbYhnRFWQghbaeHCThyi1BqjArgjNCeLBEJGLHzdEltTfSraE r/8w== X-Gm-Message-State: APzg51AQXqD8EcxAF+IxVZR3wZLzEEVceTbhPAH0hj6ZkshN2BwaMJhj 49uBD/LWF+yj7jbhUnmGxD8n9kiKJpj70/gHzV0= X-Google-Smtp-Source: ANB0VdaRcgMP2+1B6OYNqBlTWIGIdZs7HqNfE8PmEFhUV0yaOjJQywO/CfWGCYA54PAcSRN84eJoYL1y08fwAVIRyyY= X-Received: by 2002:aca:b609:: with SMTP id g9-v6mr7524248oif.148.1535720324744; Fri, 31 Aug 2018 05:58:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Fri, 31 Aug 2018 22:58:36 +1000 Message-ID: To: Daniel Stenberg Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] URI Template 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, 31 Aug 2018 12:58:47 -0000 A template can have many slots with different variables. An application might know how to fill only some of them. An application that doesn't know how to fill a given slot leaves it empty. Now, that might mean that the request ends up going nowhere useful, but that's just how it goes. For instance, DoH only defines what "dns" means, so you would take "https://example.org{?dns}{?x}" and just do "https://example.org?dns=". Of course, an extension to DoH might define "x", and those clients that understand that extension could use that template with the extension. On Fri, Aug 31, 2018 at 4:28 PM Daniel Stenberg wrote: > > Hey, > > I've written three separate client-side DoH implementations by now and I'm > mentoring a 4th. I don't get the use of URI Template in the spec. > > A template is meant to be used to describe how the URI can be made up and the > DoH spec mandates the name 'dns' to be used for the DNS packet parameter when > GET is used. There's no other URL parameters. > > Can a service then offer any other template than with a trailing '{?dns}' ? > Like 'https://example.org/path{?dns}'. > > If it can provide other parts in the {} section, what is a generic client > supposed to do with those? > > I'm probably just stupid. > > -- > > / daniel.haxx.se > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Fri Aug 31 06:23: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 2F181127AC2 for ; Fri, 31 Aug 2018 06:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8C55oXESPDeJ for ; Fri, 31 Aug 2018 06:23:14 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D0130DD4 for ; Fri, 31 Aug 2018 06:23:11 -0700 (PDT) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w7VDN7MF027661 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 15:23:07 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w7VDN7jo027657; Fri, 31 Aug 2018 15:23:07 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 31 Aug 2018 15:23:07 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Martin Thomson cc: DoH WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Doh] URI Template 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, 31 Aug 2018 13:23:16 -0000 On Fri, 31 Aug 2018, Martin Thomson wrote: > For instance, DoH only defines what "dns" means, so you would take > "https://example.org{?dns}{?x}" and just do > "https://example.org?dns=". Of course, an extension to DoH > might define "x", and those clients that understand that extension > could use that template with the extension. Ok I understand. If we in the future also adds 'x' as a variable that can be used in DoH, a future template could look like "https://example.org{?dns}{?x}" so if we want the current template parser to be future-proof it needs to accept them all... Thanks! -- / daniel.haxx.se From nobody Fri Aug 31 12:10: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 DEA9C128CFD for ; Fri, 31 Aug 2018 12:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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] 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 52EEFQFftY5I for ; Fri, 31 Aug 2018 12:10:17 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-oln040092001056.outbound.protection.outlook.com [40.92.1.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16BF124C04 for ; Fri, 31 Aug 2018 12:10:17 -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=ReABgKViFRO7k6AXsuG3+X/KEW/d+3ccnTdKbeGe1IA=; b=n4xi4rZD+BJNo2IsPaerjeXvd+OlS7WgXelGKJVMC/Dq/RBHF8uHicMBLbDSyQOhRqkQML1G3ot6DX85Wah3WpWpGSsUvWrL88UCWmzXFIx4sS5PHNga1saW7qQToeThFkfeAW+hF0h/1GZYOF2g73O3LnauwtLbRAHmcaAeAVXBkfjmZDB539V8vJKq63jQOCDFr8LwOeIFaKvKWwYcL+BsTckfdljrtKHq8sMQbizBH867c4csIwibt/JhaYmXnGSfM26I8thf2hmleu2xR+mQtHu3udcmzHGeXwOuBJIoFpM7zVX0DPi660pvnIqAuh75rL/1hhccUzfqD6wCqQ== Received: from SN1NAM01FT003.eop-nam01.prod.protection.outlook.com (10.152.64.54) by SN1NAM01HT161.eop-nam01.prod.protection.outlook.com (10.152.65.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1101.10; Fri, 31 Aug 2018 19:10:16 +0000 Received: from DM6PR19MB2249.namprd19.prod.outlook.com (10.152.64.58) by SN1NAM01FT003.mail.protection.outlook.com (10.152.65.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1101.10 via Frontend Transport; Fri, 31 Aug 2018 19:10:16 +0000 Received: from DM6PR19MB2249.namprd19.prod.outlook.com ([fe80::a0c9:1de1:77a6:e73a]) by DM6PR19MB2249.namprd19.prod.outlook.com ([fe80::a0c9:1de1:77a6:e73a%7]) with mapi id 15.20.1080.019; Fri, 31 Aug 2018 19:10:16 +0000 From: Star Brilliant To: Daniel Stenberg , Martin Thomson CC: DoH WG Thread-Topic: [Doh] URI Template Thread-Index: AQHUQPPY5gDwGz9mOEqxIblp8/Wsk6TZ0sAAgAAG2oCAAGC5Lw== Date: Fri, 31 Aug 2018 19:10:16 +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:2D0CA3774F2CA7442780174493E04E454D03BE3381C820A9E7FD7629E17AD31D; UpperCasedChecksum:A382869F3E9053AC95946E9A3F4DC80FB62CDF6574E5FA96F9DED5B900D04B3D; SizeAsReceived:7235; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [SMDsEnA7iFLCrBfLXV/k4i+5afKlU7sat8igv5lzTAHa2TIwpEB6hA==] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN1NAM01HT161; 6:2RK2aOqPZT3Ihch/Ve1prd0z72oerXwiePNCVVkeHv5jsf2/EJWt6r/qcDyYUPl3E6H9Ewflh814wBYSIde1KbrLwaGsGPDj7w/GypvUvDPYC3JbjNvjWLr5wK7T4/B+KYMTe3uk0SGLd+5E0UTTvCkgM/8UhywHqiQzPBc6+44Ta80jUr80SAkMTHUk0LwEMRUhmmyAy2HEbe6gPnyOUQx0P4J2WGD8AxxKbbPiuG6mMQ2vybgMSjMf64ZfHSFWZTI2CI/AH9BtMEpmM7RthWWnaNw6qylsGRVARK18llupQelcp1+fSBpSJd8sU3dkGm3xARYIcMQCuGRePAMFViaStExPiNzVAsg3yUGzroGyjp25MoO7+ECnAat8jHDGoDWVZXAB/02vBhYt/zE4cKeStHeabqYqa73X7Zp9HUJsKh0kvFJQHUnfIxDxBKm3NBiSD9BYBTVyBJ8qsMAwwA==; 5:HmWIC45+MhrUkmUGVnVIN5Kd+831FZwH2EAmU44sWavYnsZEI2V2NmcYsIpEyKo/c3n0ojny5mya4HCBZ4Rk3js5CXJl3cWSOD5mlGsiKchk10g9mh6kUOP8aXo0vPAw5hrWPALvuoBh+I77kHPtMmh1eo78MIxw7iN2e+8TaH8=; 7:NS67qZx+wX0QceG3660Rml3J6YRhoInN7GEu0jGppNRGjMaTDwj8YZVbp78tVnBbR2FzP2v1KBzdQhxl4Ia4vQZXd/UfXFVTu+jwX1O0jos6JUQgeVnRlOwPhzjGKTshGCuzWhHjXOtlKG/Srr+UppmwCzg1pYBhUuT8e2F2P/Mu9wKp+0xnFdHFUjyRYbWfMMBUKChZFuhiLz4Mb1ifaLqyV/7HeLo7SmK+lkamOj5zEM6u2shpsIAwARZKwIYI x-incomingheadercount: 47 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101475)(1601125500)(1701031045); SRVR:SN1NAM01HT161; x-ms-traffictypediagnostic: SN1NAM01HT161: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(4566010)(82015058); SRVR:SN1NAM01HT161; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM01HT161; x-forefront-prvs: 07817FCC2D x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(199004)(189003)(305945005)(97736004)(5660300001)(9686003)(6306002)(14454004)(256004)(6436002)(5250100002)(74316002)(33656002)(8936002)(110136005)(55016002)(446003)(82202002)(68736007)(486006)(476003)(87572001)(11346002)(4326008)(6246003)(39060400002)(8676002)(81156014)(7696005)(86362001)(99286004)(46003)(20460500001)(229853002)(102836004)(25786009)(104016004)(2900100001)(73972006)(83332001)(76176011)(105586002)(56003)(106356001)(53546011)(6346003)(6506007)(15852004)(42262002); DIR:OUT; SFP:1901; SCL:1; SRVR:SN1NAM01HT161; H:DM6PR19MB2249.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: MqYQdxP1AKJ2ZXNkFxvIx5kENzXnsVpcsP9HrbCNw7KFpbmVhjih+9pa2kYHdRerPCs5kkd2uZ1CiSSozAWFzjGJNz84ys5H/kz22eoEwPHrxFKCR7L6hzrY5L/j1UniNN9uGf+hx0eg8kQX6XMN+z4NRkM5cVQWk7CwdnJMyo3YvyWuDar2zbqyL7+sRREEGvHPNqlS6jRiFYwwMfgJbyh60+iKvekvKLRhuIKFoj0= 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: 022f23b7-834b-40d4-2642-08d60f756315 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: c001924d-3e68-4f40-89c2-901a49278da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2018 19:10:16.6383 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM01HT161 Archived-At: Subject: Re: [Doh] URI Template 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, 31 Aug 2018 19:10:19 -0000 On Fri, Aug 31, 2018 at 11:23 PM Daniel Stenberg wrote: > > On Fri, 31 Aug 2018, Martin Thomson wrote: > > > For instance, DoH only defines what "dns" means, so you would take > > "https://example.org{?dns}{?x}" and just do > > "https://example.org?dns=3D". Of course, an extension to DoH > > might define "x", and those clients that understand that extension > > could use that template with the extension. > > Ok I understand. If we in the future also adds 'x' as a variable that can= be > used in DoH, a future template could look like "https://example.org{?dns}= {?x}" > so if we want the current template parser to be future-proof it needs to > accept them all... > > Thanks! Hi, By the way, I remember we once had a "ct" parameter to specify the Content-= Type, in case we will define another one in the future. But I can not find any information about "ct" in the latest draft. Is it re= moved? What should we do if we want another Content-Type in the future? (e.g. text= -based, JSON-based, or session-based XFR) Best regards, StarBrilliant= From nobody Fri Aug 31 12:16: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 8BA93130DD0 for ; Fri, 31 Aug 2018 12:16:30 -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 T6Pgr7U1f-UY for ; Fri, 31 Aug 2018 12:16:28 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 78685124C04 for ; Fri, 31 Aug 2018 12:16:28 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id D839F3A024 for ; Fri, 31 Aug 2018 15:16:23 -0400 (EDT) Received: by mail-oi0-f45.google.com with SMTP id p84-v6so23580781oic.4 for ; Fri, 31 Aug 2018 12:16:23 -0700 (PDT) X-Gm-Message-State: APzg51DR2jzmLB8H18UZIQL8bFfyVFJFuEwxy3RFAwZZfsLr456tCCiC 1tkiAVuiZxDKGmf3ctrUeSDjNAJkzPH0Fd0Af1U= X-Google-Smtp-Source: ANB0Vdbm6a75BeqIAocEiYHdkYgt5hu2iFCvCr349Q2KuwPI+JAZE1IR9EDkLz9L5LWXkXJcQ2yEwAAsu8pjjlWsHw0= X-Received: by 2002:a54:4784:: with SMTP id o4-v6mr8197745oic.101.1535742983490; Fri, 31 Aug 2018 12:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:605:0:0:0:0:0 with HTTP; Fri, 31 Aug 2018 12:16:23 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Fri, 31 Aug 2018 15:16:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Star Brilliant Cc: Daniel Stenberg , Martin Thomson , DoH WG Content-Type: multipart/alternative; boundary="000000000000ff55a60574c0067d" Archived-At: Subject: Re: [Doh] URI Template 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, 31 Aug 2018 19:16:31 -0000 --000000000000ff55a60574c0067d Content-Type: text/plain; charset="UTF-8" 4.1: Future specifications for new media types for DoH MUST define the variables used for URI Template processing with this protocol. On Fri, Aug 31, 2018 at 3:10 PM, Star Brilliant wrote: > On Fri, Aug 31, 2018 at 11:23 PM Daniel Stenberg wrote: > > > > On Fri, 31 Aug 2018, Martin Thomson wrote: > > > > > For instance, DoH only defines what "dns" means, so you would take > > > "https://example.org{?dns}{?x}" and just do > > > "https://example.org?dns=". Of course, an extension to DoH > > > might define "x", and those clients that understand that extension > > > could use that template with the extension. > > > > Ok I understand. If we in the future also adds 'x' as a variable that > can be > > used in DoH, a future template could look like "https://example.org > {?dns}{?x}" > > so if we want the current template parser to be future-proof it needs to > > accept them all... > > > > Thanks! > > Hi, > > By the way, I remember we once had a "ct" parameter to specify the > Content-Type, in case we will define another one in the future. > > But I can not find any information about "ct" in the latest draft. Is it > removed? > What should we do if we want another Content-Type in the future? (e.g. > text-based, JSON-based, or session-based XFR) > > > Best regards, > StarBrilliant > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000ff55a60574c0067d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
4.1: 
  Future specifications for new media types for =
DoH MUST define the
   variables used for URI Template processing with this protocol.


O= n Fri, Aug 31, 2018 at 3:10 PM, Star Brilliant <m13253@hotmail.com>= ; wrote:
On Fri, = Aug 31, 2018 at 11:23 PM Daniel Stenberg <daniel@haxx.se> wrote:
>
> On Fri, 31 Aug 2018, Martin Thomson wrote:
>
> > For instance, DoH only defines what "dns" means, so you= would take
> > "https://example.org{?dns}{?x}" and just do
> > "https://example.org?dns=3D<blah>".=C2= =A0 Of course, an extension to DoH
> > might define "x", and those clients that understand tha= t extension
> > could use that template with the extension.
>
> Ok I understand. If we in the future also adds 'x' as a variab= le that can be
> used in DoH, a future template could look like "https://example.org= {?dns}{?x}"
> so if we want the current template parser to be future-proof it needs = to
> accept them all...
>
> Thanks!

Hi,

By the way, I remember we once had a "ct" parameter to specify th= e Content-Type, in case we will define another one in the future.

But I can not find any information about "ct" in the latest draft= . Is it removed?
What should we do if we want another Content-Type in the future? (e.g. text= -based, JSON-based, or session-based XFR)


Best regards,
StarBrilliant
______________________________= _________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--000000000000ff55a60574c0067d--