From nobody Tue May 1 08:06: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 D573A12DA28 for ; Tue, 1 May 2018 08:06:10 -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 LAoq3xsP-6bs for ; Tue, 1 May 2018 08:06:09 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6965512DA15 for ; Tue, 1 May 2018 08:06:09 -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.1178.4; Tue, 1 May 2018 08:06:07 -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.1178.000; Tue, 1 May 2018 08:06:07 -0700 From: Paul Hoffman To: Mark Nottingham CC: DoH WG Thread-Topic: [Ext] [Doh] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT4V3uctU7JnNFnECPdRf/4BDJ6A== Date: Tue, 1 May 2018 15:06:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BD7D752A368CD4BA19DA7B45B1D262D@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 15:06:11 -0000 On Apr 30, 2018, at 10:28 PM, Mark Nottingham wrote: > "The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]." >=20 > SHOULD is too strong here, and "used by DOH" is ambiguous. Suggest: >=20 > "DNS API clients and servers should support, but not require, the use of = HTTP/2 [RFC7540]." This seems like a good clarification. --Paul= From nobody Tue May 1 08:14:19 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1812412DA2B for ; Tue, 1 May 2018 08:14:18 -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 tT2_3KZCWdip for ; Tue, 1 May 2018 08:14:16 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA66312DA15 for ; Tue, 1 May 2018 08:14:16 -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.1178.4; Tue, 1 May 2018 08:14: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.1178.000; Tue, 1 May 2018 08:14:15 -0700 From: Paul Hoffman To: Martin Thomson CC: DoH WG , Sara Dickinson Thread-Topic: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT4Qn0yK4QQL/n3k+XxEDjXnkStKQbcWUA Date: Tue, 1 May 2018 15:14:14 +0000 Message-ID: <18E8E25A-5225-48D4-B1FD-4A1B4969D3BC@icann.org> References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> 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] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 15:14:18 -0000 On Apr 30, 2018, at 10:04 PM, Martin Thomson wro= te: > Sara's request for text regarding 7828 is reasonable. Generic text might > suffice along the lines of "extensions to DNS that are specific to the > choice of transport, such as RFC 7828, are not applicable to DOH". That seems fine, and hopefully meets Sara's desire for clarity. --Paul Hoffman= From nobody Tue May 1 14:17:50 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2204A12EA95 for ; Tue, 1 May 2018 14:17: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 lHTvQlmksjDn for ; Tue, 1 May 2018 14:17:44 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4625D1201FA for ; Tue, 1 May 2018 14:17:44 -0700 (PDT) Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 582D63A05C for ; Tue, 1 May 2018 17:17:42 -0400 (EDT) Received: by mail-ot0-f172.google.com with SMTP id t1-v6so14279873ott.13 for ; Tue, 01 May 2018 14:17:42 -0700 (PDT) X-Gm-Message-State: ALQs6tDvPA3HQtcvuyFbig3VDB2PZRBtBIGOMwsjxDCveNdepp/lPmVK kruBTMKNzBWBc7nvrg6yCHhEKdXH/sSfDwYfNH0= X-Google-Smtp-Source: AB8JxZqFIBC57+v2AhLt4Wixe/QfuFUSgT+t/kYulkJZdxJ9t+QLshnhi4ErN4/PTv/ZZB489UuhQj+oT+aNrfWtdOU= X-Received: by 2002:a9d:1de4:: with SMTP id w33-v6mr12737085otw.85.1525209461999; Tue, 01 May 2018 14:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.36 with HTTP; Tue, 1 May 2018 14:17:41 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 1 May 2018 17:17:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mark Nottingham Cc: Ben Schwartz , DoH WG Content-Type: multipart/alternative; boundary="00000000000030cec7056b2b80c4" Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:17:48 -0000 --00000000000030cec7056b2b80c4 Content-Type: text/plain; charset="UTF-8" Hey Mark, et al, For those following just list mail - paul opened a corresponding github issue https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/165 The essence of your proposal is making this a non-normative SHOULD, but I think we had established this as something pretty important for the protocol to operate well. (and I say this not just as an HTTP/2 advocate, but because the light-bandwidth, high-latency nature of DoH is in particular need of HTTP/2's multiplexing). However practical considerations of not being able to control the whole protocol chain create "valid reasons in particular circumstances" (from 2119) to ignore the requirement. If you prefer, I would be happy to change to use RECOMMENDED .. when the WG had this discussion in Singapore we decided to change from MUST to RECOMMEND (or was it recommend?) instead. On Tue, May 1, 2018 at 1:28 AM, Mark Nottingham wrote: > Hi, > > Overall, this looks good. One issue: > > "The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]." > > SHOULD is too strong here, and "used by DOH" is ambiguous. Suggest: > > "DNS API clients and servers should support, but not require, the use of > HTTP/2 [RFC7540]." > > Cheers, > > > > > > On 19 Apr 2018, at 5:07 am, Ben Schwartz wrote: > > > > All, > > This message starts a two week WG Last Call on advancing: > > > > Title : DNS Queries over HTTPS > > Author : Paul Hoffman, Patrick McManus > > Filename : draft-ietf-doh-dns-over-https-07 > > Pages : 17 > > Date : 2018-04-11 > > > > as a Standards Track document. The last call will end on May 2, 2018. > > All substantive comments are to be sent to the doh@ietf.org list for > > discussions. Editorial comments can be sent to the document editor. > > > > You can find the latest version of the document here: > > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 > > > > Regards, > > Ben & tale > > _______________________________________________ > > Doh mailing list > > Doh@ietf.org > > https://www.ietf.org/mailman/listinfo/doh > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000030cec7056b2b80c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Mark, et al,

For those f= ollowing just list mail - paul opened a corresponding github issue https:= //github.com/dohwg/draft-ietf-doh-dns-over-https/pull/165
The essence of your proposal is making this a non-normative SHO= ULD, but I think we had established this as something pretty important for = the protocol to operate well. (and I say this not just as an HTTP/2 advocat= e, but because the light-bandwidth, high-latency nature of DoH is in partic= ular need of HTTP/2's multiplexing). However practical considerations o= f not being able to control the whole protocol chain create "valid rea= sons in particular circumstances" (from 2119) to ignore the requiremen= t.

If you prefer, I would be happy to change to us= e RECOMMENDED .. when the WG had this discussion in Singapore we decided to= change from MUST to RECOMMEND (or was it recommend?) instead.





On Tue, May 1, 2018 at 1:28= AM, Mark Nottingham <mnot@mnot.net> wrote:
Hi,

Overall, this looks good. One issue:

"The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540].&q= uot;

SHOULD is too strong here, and "used by DOH" is ambiguous. Sugges= t:

"DNS API clients and servers should support, but not require, the use = of HTTP/2 [RFC7540]."

Cheers,




> On 19 Apr 2018, at 5:07 am, Ben Schwartz <bemasc@google.com> wrote:
>
> All,
> This message starts a two week WG Last Call on advancing:
>
>=C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: DNS Querie= s over HTTPS
>=C2=A0 =C2=A0Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Paul Hoffman, P= atrick McManus
>=C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-doh-dns-o= ver-https-07
>=C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 17
>=C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2018-04-11=
>
> as a Standards Track document. The last call will end on May 2, 2018.<= br> > All substantive comments are to be sent to the doh@ietf.org list for
> discussions. Editorial comments can be sent to the document editor. >
> You can find the latest version of the document here:
> https://tools.ietf.org/html/dr= aft-ietf-doh-dns-over-https-07
>
> Regards,
> Ben & tale
> ____________________________________= ___________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

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

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

--00000000000030cec7056b2b80c4-- From nobody Tue May 1 14:29:14 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D190112EACF for ; Tue, 1 May 2018 14:29:13 -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 naCXvr0f8n3B for ; Tue, 1 May 2018 14:29:11 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EEA812EAD0 for ; Tue, 1 May 2018 14:29:06 -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.1178.4; Tue, 1 May 2018 14:29:04 -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.1178.000; Tue, 1 May 2018 14:29:04 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: Does the HTTP freshness lifetime need to match the TTL? Thread-Index: AQHT4ZNt6dN39/6p60GBBovM/82U6w== Date: Tue, 1 May 2018 21:29:04 +0000 Message-ID: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> 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: [Doh] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 21:29:14 -0000 There is an active discussion with lots of back-and-forth at: https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 From nobody Tue May 1 15:49:37 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0212EAE0 for ; Tue, 1 May 2018 15:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=l9pstZt3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OMrgmgyo 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 yZzFMQUjgusd for ; Tue, 1 May 2018 15:49:32 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B782E12EA67 for ; Tue, 1 May 2018 15:49:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 24F4021A9D; Tue, 1 May 2018 18:49:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 01 May 2018 18:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=0r/Duw+smfyU1gS/6RoV4d40NjVJx nW2OUDw0UtbsS0=; b=l9pstZt3OBfZBe8+gV2XA8IzIPsewVP90T95aELsXIfG8 +++0xFUgISIhKc2C0CoD7WKO79ps3LHcGAg5EDp5NU9lHFRd99fedK19rdlgwz/z 9PXG8cA+uy5wrM29lgDhWq1sTE3DcrJU4G8ak0bnkm5L0D+s1n7zrpPi6nPGdRxG 1iG1aGioP722SeqnMesji6oB9cvHsUvkB9flQwPEh/e7j2Bkeg47jcebT5jHKrd/ 0L02E8I62oL+VDOXFhPlp2EwM95yd618O1EvcMarR+PvvLBDGJ7bI0Irr+w/EzZw 3uaFF7lwT0IyblUvJ+Aa6jUnwV+7EsVUrn8mAIdOw== 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=fm2; bh=0r/Duw +smfyU1gS/6RoV4d40NjVJxnW2OUDw0UtbsS0=; b=OMrgmgyopIEF9cOupwCx9S +LZYvN1G+p7pgJNH8usp/PIO+ynFm+u+quzQIIEVL+YJ6vDJIp2bVGgO60nOtHn1 N4YJv5BnMQfD9Vp7ZRwx64rJZyjUqZfnUG3nP1KzLzL6dqh3+ow/neDScoPXaVg7 EeEUuRXoUTGSampOY7loYSgzBoWtqJguZRappfvVNB3knUUVj4aZTRk1PbOSgj7S s6s7kS1BTjvDvUb2ROukOsQvHnFlrwukOwMEQyXEKBCZg2LSJ8GoFpIJedlACtfx V0tT+4JMZZBIEs6OTWS8lh9Xd50l38G47meYJzCll+cUY6VF7CpPM+rU9SBc9wRg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 3C4A010255; Tue, 1 May 2018 18:49:29 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: Date: Wed, 2 May 2018 08:49:24 +1000 Cc: Ben Schwartz , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <073CFC7D-9016-45A0-8A15-C593029B205B@mnot.net> References: To: Patrick McManus X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 22:49:36 -0000 RECOMMENDED works for me. Cheers, > On 2 May 2018, at 7:17 am, Patrick McManus = wrote: >=20 > Hey Mark, et al, >=20 > For those following just list mail - paul opened a corresponding = github issue = https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/165 >=20 > The essence of your proposal is making this a non-normative SHOULD, = but I think we had established this as something pretty important for = the protocol to operate well. (and I say this not just as an HTTP/2 = advocate, but because the light-bandwidth, high-latency nature of DoH is = in particular need of HTTP/2's multiplexing). However practical = considerations of not being able to control the whole protocol chain = create "valid reasons in particular circumstances" (from 2119) to ignore = the requirement. >=20 > If you prefer, I would be happy to change to use RECOMMENDED .. when = the WG had this discussion in Singapore we decided to change from MUST = to RECOMMEND (or was it recommend?) instead.=20 >=20 >=20 >=20 >=20 >=20 > On Tue, May 1, 2018 at 1:28 AM, Mark Nottingham wrote: > Hi, >=20 > Overall, this looks good. One issue: >=20 > "The minimum version of HTTP used by DOH SHOULD be HTTP/2 [RFC7540]." >=20 > SHOULD is too strong here, and "used by DOH" is ambiguous. Suggest: >=20 > "DNS API clients and servers should support, but not require, the use = of HTTP/2 [RFC7540]." >=20 > Cheers, >=20 >=20 >=20 >=20 > > On 19 Apr 2018, at 5:07 am, Ben Schwartz wrote: > >=20 > > All, > > This message starts a two week WG Last Call on advancing: > >=20 > > Title : DNS Queries over HTTPS > > Author : Paul Hoffman, Patrick McManus > > Filename : draft-ietf-doh-dns-over-https-07 > > Pages : 17 > > Date : 2018-04-11 > >=20 > > as a Standards Track document. The last call will end on May 2, = 2018. > > All substantive comments are to be sent to the doh@ietf.org list for > > discussions. Editorial comments can be sent to the document editor. > >=20 > > You can find the latest version of the document here: > > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 > >=20 > > Regards, > > Ben & tale > > _______________________________________________ > > Doh mailing list > > Doh@ietf.org > > https://www.ietf.org/mailman/listinfo/doh >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh -- Mark Nottingham https://www.mnot.net/ From nobody Wed May 2 04:43: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 C14FA12DA6F for ; Wed, 2 May 2018 04:43:08 -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 TDbHEEMvA3Sj for ; Wed, 2 May 2018 04:43:06 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED59126B72 for ; Wed, 2 May 2018 04:43:05 -0700 (PDT) Received: from [2001:b98:204:102:fffa::] (port=64996) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fDq9z-0007IW-AC; Wed, 02 May 2018 12:43:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sara Dickinson In-Reply-To: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> Date: Wed, 2 May 2018 12:42:13 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 11:43:09 -0000 > On 1 May 2018, at 04:22, Paul Hoffman wrote: Hi Paul and Martin, > Thanks, Sara! I have opened pull requests for #1, #3, and #4. Thanks Paul for that - I=E2=80=99ll comment directly on the issues. > Of the remaining: >=20 >> 2) Sections 3, 4.2 and 6 mention the presence of EDNS(0) options. = Section 6 specifically says=20 >> =E2=80=9CDNS API clients using the DNS wire format MAY have one or = more EDNS options [RFC6891] in the request.=E2=80=9D=20 >>=20 >> In a similar manner to the problem with truncation of responses, = there are 2 EDNS options I can think of that are transport specific, but = how to handle them isn=E2=80=99t described in this draft i.e. >> - EDNS(0) Padding (When RFC7830 was written only DNS-over-TLS was = standardised, but the text doesn=E2=80=99t restrict it to that it simply = says =E2=80=9CTherefore, implementations MUST NOT use this option if the = DNS transport is not encrypted.=E2=80=9D). Alexander Mayrhofer = requested a note be added about this option in his review of the -04 = draft. >> - EDNS(0) Keepalive (RFC7828). >=20 > I'm not sure why there are "problems" with these. For padding, the = server can use it or not. For me the issue is simply that HTTP padding is specifically mentioned = in the draft (several times) but that EDNS(0) isn=E2=80=99t mentioned at = all. A simple statement in Section 6 to the effect that =E2=80=98DNS API = clients and servers may use EDNS(0) padding [RFC7830] in the DNS wire = format independently of whether or not HTTP padding is used.=E2=80=99 = would suffice I think.=20 > For keepalive, it makes no sense for it to support it. Just like any = traditional DNS server, a DOH server has to understand its context when = deciding how to answer queries with EDNS options. [including Martin's comment] > Sara's request for text regarding 7828 is reasonable. Generic text = might > suffice along the lines of "extensions to DNS that are specific to the > choice of transport, such as RFC 7828, are not applicable to DOH". = FWIW, > HTTP/2 has its own keepalive mechanisms. Precisely - there is no reason to use EDNS(0) Keepalive in DOH and DNS = API clients shouldn=E2=80=99t. I=E2=80=99d be happy with a specific = statement on that rather than the generic text=E2=80=A6 since the above = could be taken to exclude the use of EDNS(0) Padding (which is an = extension specific to encrypted transports)... >> 5) Section 8:=20 >>=20 >> "If a client of this protocol encounters an HTTP >> error after sending a DNS query, and then falls back to a different >> DNS retrieval mechanism, doing so can weaken the privacy and >> authenticity expected by the user of the client.=E2=80=9D >>=20 >> This text brings up the biggest issue I have with the document, which = is that I would like to request that it replaces the above text with a = section that clarifies how DOH can be used in the context of a privacy = usage profile (see both RFC7858 and RFC8310 for descriptions of Strict = vs Opportunistic usage profiles for DNS-over-(D)TLS). To be clear: in = these profiles only configured servers are used (no discovery is = involved). I=E2=80=99m happy to help with text here if there is = consensus that this is in scope and beneficial to the document.=20 >>=20 >> The big, big gain I see here is for applications such as Stubby which = would like to have a standard way to add DOH as a transport option = alongside the existing use of DNS-over-TLS when using those profiles. = In this scenario Stubby would be the =E2=80=98client=E2=80=99 in the = text above which can use either a DNS API client or a =E2=80=98traditional= ' DNS client. =20 >>=20 >> (As an aside, I note that the above is the first and only mention of = the word =E2=80=98privacy' in the document and this document does not = currently describe the specific privacy benefits of this specification = compared to =E2=80=99other mechanisms=E2=80=99.) >>=20 >> Two ambiguities with the current text are: >> - RFC8310 says a DNS client should only use a single privacy usage = profile when resolving a specific query (precisely to avoid the problem = mentioned above) but this text seems to contradict that.=20 >> - while it is heavily implied the document isn=E2=80=99t actually = crystal clear on whether a configured =E2=80=98trusted=E2=80=99 server = can be used if authentication of the certificate fails.=20 >=20 > Please, no. Or at least, not here. The complicated DNS-over-TLS usage = policies are one of the reasons we have so little implementation of = DNS-over-TLS. (Others may disagree with this statement.) [Including Martins comment] > I agree with Paul - the profile in RFC 8310 overlaps considerably with = text > in HTTP RFCs. For instance, HTTP/2 already mandates TLS 1.2 or = greater > without compression (it also goes further to require PFS). 8310 also > misses a few things that DOH covers, such as the OCSP/AIA deadlock. >=20 > The true advantage of DOH is that it just uses HTTP. And that means > relying on HTTP mechanisms for ensuring integrity, confidentiality, = and > authentication. I think that those are broadly adequate. >=20 > Separately, I'd suggest that the 8310 profile requirements are > unrealistic. I'm not aware of many implementations that do raw public = keys > or cached info. I also don't see any particular value in mandating = tickets > and false start - they each provide ample motivation on their own = without > needing a MUST. My request was not at all to have RFC8310 to apply here in general - I = completely agree that doesn=E2=80=99t make any sense, and I didn=E2=80=99t= even mean this document should adopt Strict vs Opportunistic. > It would be lovely if Stubby could add DOH as a transport that is = parallel to DNS-over-TLS, and for that there has to be some common = understanding of privacy and trust levels. Duplicating to twisty mazes = from DNS-over-TLS usage policies is not going to help. Instead, a new = document that covers DNS-over-TLS, DOH, and the likely future = DNS-over-QUIC needs to deal with this, and more clearly. I=E2=80=99m all for that general approach but=E2=80=A6. what I think = would help here is:=20 - Can this document make any clear statement about whether or not a DNS = API server is =E2=80=98trusted' if HTTPS authentication fails?=20 There is an implied MUST in section 9 =E2=80=9Cwhile still = authenticating the resulting connection via HTTPS=E2=80=9D. If there is = actually a MUST here then I believe that actually naturally maps to = using DOH only with a Strict profile for client that already implement = that (in the short-term and in the absence of any other guidance - we = are adding DOH to Stubby right now).=20 - If there is no requirement relating to this or if that is deemed to = be out of scope of this document and will be the subject of future work = then please state that explicitly.=20 (As a general point, in reviewing I had to trawl through the mailing = list again to understand what was in and out of scope - a section in the = document clarifying that would actually be very helpful I believe). =20 >=20 > I'm about to propose a non-WG-forming BoF in Montr=C3=A9al for folks = who want to talk about such work. But I don't think it should stop DOH; = if it does, we're probably talking at least six months to hope for = consensus. (And the consensus on policy in DPRIVE was more from = exhaustion than agreement.) >=20 >> 6) Section 9:=20 >>=20 >> =E2=80=9CA DNS API client may face a similar bootstrapping problem = when the >> HTTP request needs to resolve the hostname portion of the DNS URI." >>=20 >> =E2=80=9C...or resolving the DNS API server's hostname via = traditional DNS =E2=80=9C >>=20 >> DNS-over(D)TLS using only a configured authentication domain name = shares many of the discovery issues that DoH has. Paragraph 4 of Section = 9 overlaps with the discussion of =E2=80=98meta-queries=E2=80=99 as = already described in more detail in RFC8310 and it would be helpful if = the language could be aligned or if RFC8310 was at least referenced = here. One of the issues discussed in that document is the potential for = denial-of-service if these meta-queries are subject to attack, which = seems worthy of note. Again, happy to help with text here. =20 =E2=80=9CAlternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DNS API server while still authenticating the resulting connection via HTTPS.=E2=80=9D Propose adding=20 =E2=80=9CIt should be noted that some of these bootstrapping mechanisms = can be actively attacked which can result in denial-of-service for DOH = clients in a similar manner to that for DNS-over-TLS meta-queries = [RFC8310]. =E2=80=9C Sara.=20 From nobody Wed May 2 06:23: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 B183A126FDC for ; Wed, 2 May 2018 06:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR1s7WJKi3Tc for ; Wed, 2 May 2018 06:23:39 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BCDF126FB3 for ; Wed, 2 May 2018 06:23:39 -0700 (PDT) Received: from [2001:b98:204:102:fffa::] (port=49426) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fDrjI-0001ld-S9; Wed, 02 May 2018 14:23:38 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_48358DC4-1B00-4284-8BA5-4CC371F120D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 2 May 2018 14:23:30 +0100 In-Reply-To: Cc: DoH WG To: Ben Schwartz References: X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 3 Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 13:23:42 -0000 --Apple-Mail=_48358DC4-1B00-4284-8BA5-4CC371F120D0 Content-Type: multipart/alternative; boundary="Apple-Mail=_D3A19346-74DF-4959-91A7-11E9896A6529" --Apple-Mail=_D3A19346-74DF-4959-91A7-11E9896A6529 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 One other last nit/question on this. The WG charts states: =E2=80=9CThe primary focus of this working group is to develop a = mechanism that provides confidentiality and connectivity between DNS clients (e.g., = operating system stub resolvers) and recursive resolvers.=E2=80=9D But the definitions in the Terminology are simply =E2=80=98DNS API = client' and =E2=80=98DNS API server=E2=80=99. Much of the discussion of = caching and DNSSEC is specific to stup-resolver interactions so I think = this needs to be addressed. I suggest stating the scope clearly in the draft e.g.: "This document focuses on communication between DNS clients (e.g., = operating system stub resolvers) and recursive resolvers, as per the charter of the DOH Working Group at the time of writing.=E2=80=9D Sara. > On 18 Apr 2018, at 20:07, Ben Schwartz wrote: >=20 > All, > This message starts a two week WG Last Call on advancing: >=20 > Title : DNS Queries over HTTPS > Author : Paul Hoffman, Patrick McManus > Filename : draft-ietf-doh-dns-over-https-07 > Pages : 17 > Date : 2018-04-11 >=20 > as a Standards Track document. The last call will end on May 2, 2018. > All substantive comments are to be sent to the doh@ietf.org = list for > discussions. Editorial comments can be sent to the document editor. >=20 > You can find the latest version of the document here: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 = >=20 > Regards, > Ben & tale > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh --Apple-Mail=_D3A19346-74DF-4959-91A7-11E9896A6529 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 One = other last nit/question on this. The WG charts states:

=E2=80=9CThe primary focus of this = working group is to develop a mechanism that
provides = confidentiality and connectivity between DNS clients (e.g., operating
system stub resolvers) and recursive = resolvers.=E2=80=9D

But the definitions in the Terminology are simply =E2=80=98DNS = API client' and =E2=80=98DNS API server=E2=80=99. Much of the discussion = of caching and DNSSEC is specific to stup-resolver interactions so I = think this needs to be addressed.

I suggest stating the scope clearly in = the draft e.g.:

"This document focuses on communication = between DNS clients (e.g., operating
system stub = resolvers) and recursive resolvers, as per
 the = charter of the DOH Working Group at the time of writing.=E2=80=9D

Sara. 


On 18 Apr 2018, at 20:07, Ben = Schwartz <bemasc@google.com> wrote:

All,
This message starts a two week WG = Last Call on advancing:

  Title      =      : DNS Queries over HTTPS
  Author      =     : Paul Hoffman, Patrick McManus
  Filename      =   : draft-ietf-doh-dns-over-https-07
  Pages      =      : 17
  Date      =       : 2018-04-11

as a Standards Track document. The = last call will end on May = 2, 2018.
All substantive comments are to be = sent to the doh@ietf.org list = for
discussions. Editorial comments can = be sent to the document editor.

You can find the latest version of the = document here:
https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07

Regards,
Ben & tale
_______________________________________________
Doh = mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

= --Apple-Mail=_D3A19346-74DF-4959-91A7-11E9896A6529-- --Apple-Mail=_48358DC4-1B00-4284-8BA5-4CC371F120D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEARfKBmwUrVFTxWi2+uOzGhY+Sp0FAlrpu9IACgkQ+uOzGhY+ Sp08Awf/X26tcvkSI96qrRQxi1hOw98J9dGgubOF2uMlot5yLiFTBhS04Yq+8YML xm5Kwfd9n6EQRa9jRgQFZCmNw7b7lsgHHpBMr5AZ7bGbBAS9DAhnl/LI+h/XI+2l nvMIl4teK04IZL7fljvEMlosiQxQlIyJ+KPDCWailsLcTG8Hfqh+3OqUcBdtF05P iezf6oc4R9AUeo4faiJSzKJrqiA0JIxyVkVy3fl1oU9CJpQ8Nz4jIB5uEiTNBLN5 QiVEebpn3cZsXOv0nWJGphAs25F33FwE4zX2x+e1pyQwsXt5gm+Wins4vk7iI74k 4m2iVZh5OKeoqEyvZmrgFinCa1ml1w== =caSq -----END PGP SIGNATURE----- --Apple-Mail=_48358DC4-1B00-4284-8BA5-4CC371F120D0-- From nobody Wed May 2 07:46: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 894B012D882 for ; Wed, 2 May 2018 07:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk 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 oZv9QRXz_YwC for ; Wed, 2 May 2018 07:46:25 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110115.outbound.protection.outlook.com [40.107.11.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3C0120726 for ; Wed, 2 May 2018 07:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lwZiJCiiSXuS5uleyT0dz+EkXaJ5hu+ubVwMRzKl2+g=; b=YKyxgYpZsMclhaxlaPWgQscQEZsaL1dVFtfcWtEb+SWgin/Bg2gv0KBkjoD7PRG3px8tuUIVb7DPA3cqECx1ZQueZyM0zHyWYo44gyuM0k9sWcQiUdfdjusjPHfCko9VH5W0fdrWsH3zWzTxhIeah85Tl0QLZZCWf9+lxupvL/8= Received: from MMXP123MB0944.GBRP123.PROD.OUTLOOK.COM (10.166.239.140) by MMXP123MB1326.GBRP123.PROD.OUTLOOK.COM (10.166.242.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.715.23; Wed, 2 May 2018 14:46:21 +0000 Received: from MMXP123MB0944.GBRP123.PROD.OUTLOOK.COM ([fe80::4db7:29ef:71ad:774b]) by MMXP123MB0944.GBRP123.PROD.OUTLOOK.COM ([fe80::4db7:29ef:71ad:774b%13]) with mapi id 15.20.0715.024; Wed, 2 May 2018 14:46:21 +0000 From: Mark O To: "doh@ietf.org" Thread-Topic: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AdPiIZ3o00k31TnqSRiRkDBnQTgtCw== Date: Wed, 2 May 2018 14:46:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_Enabled=True; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_SiteId=14aa5744-ece1-474e-a2d7-34f46dda64a1; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_Ref=https://api.informationprotection.azure.com/api/14aa5744-ece1-474e-a2d7-34f46dda64a1; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_Owner=Mark38706@ncsc.gov.uk; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_SetDate=2018-05-02T15:45:50.7904927+01:00; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_Name=Public; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_Application=Microsoft Azure Information Protection; MSIP_Label_f06a2035-db2b-4d42-a505-747dd3f39da3_Extended_MSFT_Method=Manual; Sensitivity=Public authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mark.O@ncsc.gov.uk; x-originating-ip: [165.225.81.40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MMXP123MB1326; 7:fuygUjmJtQUOHBnb/yrCn9B8Ly2dDa8Mw67tkZv1yVfOfDH6S70LgWDvEJ88nzJM1X4VJQtsnmWmQ2bxiFEyQDZCglw2R6lR+0efW5l04eos840vYDp13BMXZVcL8OxuaW9nTxbSnBjvftXhRiWP98jP8mvX431F6pUqX6s0CTxPGsQ4FKzWgEpUgtENqA2ZzyETvqFLWFhCSEWl+fNCulJWpnbymcsXxz08BLFHEMakQEhF8qxcEHMhxD5Tb5e9 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MMXP123MB1326; x-ms-traffictypediagnostic: MMXP123MB1326: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(278428928389397)(192374486261705)(189930954265078)(211936372134217)(153496737603132)(45079756050767)(27231711734898)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:MMXP123MB1326; BCL:0; PCL:0; RULEID:; SRVR:MMXP123MB1326; x-forefront-prvs: 06607E485E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(396003)(366004)(346002)(39850400004)(377424004)(199004)(189003)(229853002)(26005)(53546011)(5250100002)(6436002)(55236004)(3280700002)(102836004)(6506007)(2906002)(74482002)(3660700001)(316002)(186003)(236005)(33656002)(74316002)(5640700003)(2501003)(105586002)(2900100001)(59450400001)(7696005)(6246003)(5660300001)(2351001)(25786009)(6116002)(54896002)(9686003)(6306002)(3846002)(55016002)(790700001)(53936002)(6916009)(606006)(8676002)(8936002)(478600001)(14454004)(72206003)(966005)(486006)(86362001)(81166006)(106356001)(66066001)(81156014)(1730700003)(75922002)(68736007)(97736004)(5630700001)(99286004)(7736002)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:MMXP123MB1326; H:MMXP123MB0944.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: wVc7QnbWl8Juk+ALi6TSSnpcUyNpUBOBbyr+diHSuRBHfuLhQC7YA2odcTXUS3ICx/rkBoH8aLgXX0LKnF3xaxNbvH85tmqYHPyPJ16OWlaDJc1CcBnV+K683gMzKZ2ZWRDzb/81Eoh83qTXMWhDNVggGZE48lbYCfZOLb/4cYtOiUUIQPN3yf6HB5jYqXvl spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MMXP123MB094409CCCD7420EF2D60E055D3800MMXP123MB0944GBRP_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 8610c4c9-5ef2-43c6-c828-08d5b03b78cc X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 8610c4c9-5ef2-43c6-c828-08d5b03b78cc X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2018 14:46:21.7944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MMXP123MB1326 Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 14:46:29 -0000 --_000_MMXP123MB094409CCCD7420EF2D60E055D3800MMXP123MB0944GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The charter for the DOH working group states that "The working group will a= nalyze the security and privacy issues that could arise from accessing DNS = over HTTPS". I'd like to suggest that the section on Security Consideration= s of draft-ietf-doh-dns-over-https should include text on the impact on cyb= er defence. Additionally, there is currently no section on Privacy Consider= ations; I think there ought to be one, highlighting the privacy implication= s of adopting DOH. Suggested text: Security Considerations "DNS queries and responses transmitted using DOH will not be visible to sec= urity appliances that filter traffic without proxying it. These security ap= pliances may be used to protect the user (or the DNS resolver) from cyber a= ttackers, by blocking DNS resolution and therefore connection attempts to b= lack-listed domains that have been associated with malware or mass hacking = attacks, or using DNS to monitor outbreaks of such malware across a network= . DOH may reduce the effectiveness of these security appliances." (The section on Operational Considerations already includes the statement "= Filtering or inspection systems that rely on unsecured transport of DNS wil= l not function in a DNS over HTTPS environment", but this fails to capture = the impact on cyber defence.) Privacy Considerations "As recognised in RFC7626, running DNS queries over an unencrypted channel = has privacy implications for the user: both the name of the domain being qu= eried, and the source IP addresses of the user, are available to an eavesdr= opper. Although neither of these may be sensitive in themselves, the linkin= g of one to another is a major privacy concern. DOH improves privacy for th= e user because the domain names being queried are no longer visible to the = attacker." "Some enterprises may use DNS filtering systems, which may filter queries o= r re-write DNS responses to protect applications and local users from malwa= re or illicit content. The DNS filtering system is an observer of the enterprise users' DNS querie= s and responses and may be able to correlate the queries and responses to H= TTPS sessions, and attribute DNS queries to individuals. This has privacy i= mplications for the enterprise users. With DOH, DNS filtering systems that = rely on clear DNS traffic will no longer work; this is a privacy improvemen= t, but also causes a security risk to the enterprise if not addressed. One = possible remedial action would be to decrypt the HTTPS data that contains t= he DOH queries and responses. Since it is not possible to distinguish DOH f= rom other HTTPS traffic and selectively decrypt only the DOH traffic, the r= esult would be to decrypt all HTTPS traffic, which would represent a greate= r level of privacy intrusion." I also suggest moving this [existing] paragraph from "Security Consideratio= ns" to "Privacy Considerations": "A client can use DNS over HTTPS as one of multiple mechanisms to obtain DN= S data. If a client of this protocol encounters an HTTP error after sendin= g a DNS query, and then falls back to a different DNS retrieval mechanism, = doing so can weaken the privacy expected by the user of the client." Additionally, there is a paragraph in the Security Considerations about not= trusting an HTTPS DNS server just because it has been discovered; it says = "a client MUST only trust DNS API server that is configured as trustworthy.= " For clarity, it might be better to reverse the logic of this statement, i= .e. "a client MUST NOT trust a DNS API server that has not been configured = by the client to be trustworthy." - Mark > On 19 Apr 2018, at 5:07 am, Ben Schwartz > wrote: > > All, > This message starts a two week WG Last Call on advancing: > > Title : DNS Queries over HTTPS > Author : Paul Hoffman, Patrick McManus > Filename : draft-ietf-doh-dns-over-https-07 > Pages : 17 > Date : 2018-04-11 > > as a Standards Track document. The last call will end on May 2, 2018. > All substantive comments are to be sent to the doh@ietf.org list for > discussions. Editorial comments can be sent to the document editor. > > You can find the latest version of the document here: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07 > > Regards, > Ben & tale > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_MMXP123MB094409CCCD7420EF2D60E055D3800MMXP123MB0944GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The charter for the DO= H working group states that “The working group will analyze the secur= ity and privacy issues that could arise from accessing DNS over HTTPS”= ;. I’d like to suggest that the section on Security Considerations of draft-ietf-doh-dns-over-https should include text on the= impact on cyber defence. Additionally, there is currently no section on Pr= ivacy Considerations; I think there ought to be one, highlighting the priva= cy implications of adopting DOH.

 

Suggested text:=

 

Security Considerat= ions

“DNS queries and= responses transmitted using DOH will not be visible to security appliances= that filter traffic without proxying it. These security appliances may be = used to protect the user (or the DNS resolver) from cyber attackers, by blocking DNS resolution and therefore connec= tion attempts to black-listed domains that have been associa= ted with malware or mass hacking attacks, or using DNS to monitor outbreaks= of such malware across a network. DOH may reduce the effectiveness of these security appliances.”

(The section on Operational Considerations already i= ncludes the statement “Filtering or inspection systems that rely on u= nsecured transport of DNS will not function in a DNS over HTTPS environment= ”, but this fails to capture the impact on cyber defence.)

 

Privacy Considerati= ons

“As recognised i= n RFC7626, running DNS queries over an unencrypted channel has privacy impl= ications for the user: both the name of the domain being queried, and the s= ource IP addresses of the user, are available to an eavesdropper. Although neither of these may be sensitive in themselv= es, the linking of one to another is a major privacy concern. DOH improves = privacy for the user because the domain names being queried are no longer v= isible to the attacker.”

 

“Some enterprise= s may use DNS filtering systems, which may filter queries or re-write DNS r= esponses to protect applications and local users from malware or illicit co= ntent.

The DNS filtering system is an observer of the enter= prise users’ DNS queries and responses and may be able to correlate t= he queries and responses to HTTPS sessions, and attribute DNS queries to in= dividuals. This has privacy implications for the enterprise users. With DOH, DNS filt= ering systems that rely on clear DNS traffic will no longer work; this is a= privacy improvement, but also causes a security risk to the enterprise if = not addressed. One possible remedial action would be to decrypt the HTTPS data that contains the DOH queri= es and responses. Since it is not possible to distinguish DOH from other HT= TPS traffic and selectively decrypt only the DOH traffic, the res= ult would be to decrypt all HTTPS traffic, which would represent a greater level of privacy intrusion.”

 

I also suggest moving = this [existing] paragraph from "Security Considerations" to "= ;Privacy Considerations":

“A client can us= e DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If= a client of this protocol encounters an HTTP error after sending= a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy expected by the user of the cli= ent.”

 

Additionally, there is=  a paragraph in the Security Considerations about not trusting an HTTP= S DNS server just because it has been discovered; it says “a client M= UST only trust DNS API server that is configured as trustworthy.” For clarity, it might be better to revers= e the logic of this statement, i.e. “a client MUST NOT trust a DNS AP= I server that has not been configured by the client to be trustworthy.̶= 1; 

 <= /span>

- Mark

 



> On 19 Apr 2018, at 5:07 am, Ben Schwartz <bemasc@google.com> wrote:
>
> All,
> This message starts a two week WG Last Call on advancing:
>
>   Title           : DNS Querie= s over HTTPS
>   Author          : Paul Hoffman, P= atrick McManus
>   Filename        : draft-ietf-doh-dns-o= ver-https-07
>   Pages           : 17
>   Date            : 2018-04-11=
>
> as a Standards Track document. The last call will end on May 2, 2018.<= br> > All substantive comments are to be sent to the doh@ietf.org list for
> discussions. Editorial comments can be sent to the document editor. >
> You can find the latest version of the document here:
> https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-07
>
> Regards,
> Ben & tale

> ________________= _______________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh

&nbs= p;

&nbs= p;

&nbs= p;

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_MMXP123MB094409CCCD7420EF2D60E055D3800MMXP123MB0944GBRP_-- From nobody Wed May 2 09:09:15 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D31112895E for ; Wed, 2 May 2018 09:09:14 -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 e-h9g6uLRZVR for ; Wed, 2 May 2018 09:09:12 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 DC5911200F1 for ; Wed, 2 May 2018 09:09:12 -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.1178.4; Wed, 2 May 2018 09:09:11 -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.1178.000; Wed, 2 May 2018 09:09:11 -0700 From: Paul Hoffman To: Mark O CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT4i/nD8tXli9mIEKpyy7H8pe1Qw== Date: Wed, 2 May 2018 16:09:10 +0000 Message-ID: <3AF88665-5E46-4226-B7BE-082EBA1FE5C5@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="utf-8" Content-ID: <1D6C2AA6A71ABF41949D24090F49621B@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 16:09:14 -0000 T24gTWF5IDIsIDIwMTgsIGF0IDc6NDYgQU0sIE1hcmsgTyA8TWFyay5PQG5jc2MuZ292LnVrPiB3 cm90ZToNCj4gDQo+ICBUaGUgY2hhcnRlciBmb3IgdGhlIERPSCB3b3JraW5nIGdyb3VwIHN0YXRl cyB0aGF0IOKAnFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYW5hbHl6ZSB0aGUgc2VjdXJpdHkgYW5k IHByaXZhY3kgaXNzdWVzIHRoYXQgY291bGQgYXJpc2UgZnJvbSBhY2Nlc3NpbmcgRE5TIG92ZXIg SFRUUFPigJ0uDQoNCkl0IGRvZXMuIEhvd2V2ZXIsIGl0IGRvZXMgbm90IHNheSB0aGF0IHRoZSBw cm90b2NvbCBkb2N1bWVudCBoYXMgdG8gZG8gc28uDQoNCj4gSeKAmWQgbGlrZSB0byBzdWdnZXN0 IHRoYXQgdGhlIHNlY3Rpb24gb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgb2YgZHJhZnQtaWV0 Zi1kb2gtZG5zLW92ZXItaHR0cHMgc2hvdWxkIGluY2x1ZGUgdGV4dCBvbiB0aGUgaW1wYWN0IG9u IGN5YmVyIGRlZmVuY2UuDQoNCkl0IG1pZ2h0IGJlIGJldHRlciBkZWFsdCB3aXRoIGluIGEgc3Rh bmRhbG9uZSBkb2N1bWVudC4gR2l2ZW4gdGhhdCB0aGUgSUVURiBoaXN0b3JpY2FsbHkgdGFrZXMg YXQgbGVhc3QgYSB5ZWFyIHRvICJhZ3JlZSIgb24gd29yZGluZyByZWxhdGluZyB0byB0aGlzLCBj YXVzaW5nIHRoZSBwcm90b2NvbCBkb2N1bWVudCB0byB3YWl0IGZvciBzdWNoIGFncmVlbWVudCBt aWdodCBiZSBiYWQuIEZvciBleGFtcGxlLCBJIGZpbmQgc29tZSBvZiB0aGUgd29yZGluZyB5b3Ug cHJvcG9zZWQgdG8gYmUgaGlnaGx5IGJpYXNlZCB0b3dhcmRzICJtaWRkbGVib3hlcyBoYXZlIGEg cmlnaHQgdG8gaW5zcGVjdCIuIE90aGVycyBtaWdodCBmaW5kIHlvdXIgd29yZGluZyB0b28gd2Vh aywgYW5kIHdvdWxkIHdhbnQgbW9yZSB3b3JkaW5nIGFsb25nIHRoZSBsaW5lcyBvZiAic2VjdXJp dHkgbWlkZGxlYm94ZXMgYWxyZWFkeSBpbnNwZWN0IEROUyBtZXNzYWdlcywgYW5kIERPSCBpcyBw cmV2ZW50aW5nIHRoYXQsIHNvIERPSCBodXJ0cyBzZWN1cml0eSIuIFRoZXJlIGFyZSBsaXRlcmFs bHkgdGhvdXNhbmRzIG9mIG1lc3NhZ2VzIG9uIHRoaXMgdG9waWMgb24gdmFyaW91cyBJRVRGIG1h aWxpbmcgbGlzdHMgaW4gdGhlIHBhc3QgZmV3IHllYXJzLg0KDQpGdXJ0aGVyLCB0aGUgd29yZGlu ZyBwcm9wb3NlZCBpcyBhcyBhcHByb3ByaWF0ZSBmb3IgRE5TLW92ZXItVExTIGFzIGZvciBET0gg KHdpdGggc2xpZ2h0bHkgZGlmZmVyZW50IHNlY3VyaXR5IGFuZCBwcml2YWN5IGNvbnNpZGVyYXRp b25zKSwgYW5kIHRodXMgYSBzZXBhcmF0ZSBkb2N1bWVudCB0aGF0IGRlYWxzIHdpdGggYm90aCBv ZiB0aGVtIHdvdWxkIGFjdHVhbGx5IGJlIG1vcmUgaGVscGZ1bCB0aGFuIGp1c3QgZG9pbmcgaXQg Zm9yIERPSC4NCg0KLS1QYXVsIEhvZmZtYW4= From nobody Wed May 2 15:23: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 898FA12DA4A for ; Wed, 2 May 2018 15:23:40 -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 rfQamf-levmg for ; Wed, 2 May 2018 15:23:38 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BC212DA49 for ; Wed, 2 May 2018 15:23:38 -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.1178.4; Wed, 2 May 2018 15:23: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.1178.000; Wed, 2 May 2018 15:23:36 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: [Ext] [Doh] Does the HTTP freshness lifetime need to match the TTL? Thread-Index: AQHT4mQ2oIkpK1chOkms/JhO5B5Qeg== Date: Wed, 2 May 2018 22:23:36 +0000 Message-ID: <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> In-Reply-To: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> 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: <2D12367B34F8F54D9EF45BE5C1AB53D6@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 22:23:40 -0000 I'm going to re-up this here on the list. Please see the discussion on https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 It would be handy if people who disagree with each other offer text *on the= list*, not pull requests, specifying what they want the text in the draft = to say. Then, people to try to come to consensus on this. (Yes, some people= are more comfortable with editing pull requests; I feel that this issue is= too important to not have the discussion here on the list.) --Paul Hoffman= From nobody Wed May 2 17:58:43 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 87B63127275 for ; Wed, 2 May 2018 17:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxBGPf0XbMDP for ; Wed, 2 May 2018 17:58:39 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 C0288127241 for ; Wed, 2 May 2018 17:58:39 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id i5-v6so7103811otf.1 for ; Wed, 02 May 2018 17:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FjBDKt3FKbYGAvRiq1/HxItlFWpiDIEmOHqD2Vi5S4M=; b=f9iWhU1J7c/gkj5pDy8ZCgX9iSK5RnJJmGdgKH9QaWIl4qK4uxRs0DXoUgc6+daUDl awvjE4EBwhVbwkU7wS2SgMhv5XBjPsiabCC5fj7tZahOPGqpc3IhyMYwWNDZqUBj+IlS u2Urjwj1cJIbm300BqzTYrMcavq8cc81w7lfE6awKAYdmYESwfYh6gSxm6S/ZRWd5JIx XTjHZllEtr+WLr3c0wReSJi2IDKBlhtDxDWT3g+94y/SVthUHMFmhTK77Y9aImJz/j8y Gb9ePCDTOQoxMEgjX7DPgzox76rOOQLhC+WLIYnz0tWK6q88Zb7TLk2SOgXZKfFS2g7p 61IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FjBDKt3FKbYGAvRiq1/HxItlFWpiDIEmOHqD2Vi5S4M=; b=YuACMEHeptGN0wIC5HoxRwyjauZNse5SaSBw/wmcwXk2MrxoURfQoI4l6CEzSOjFto 3xVZMcA3rhm1e/Gf+iiIUzqRq7r9wrKe+WvW8rGwrNJqoVB0dok2gyYoDxWl/vU5zjDh gqfzHMZO6vQkzyMO7Qgru2A32eNIeICUQwkVlvD432z4wOrbZ0nlsIrXXHZCSt9jSklK d1vVIL5NCCH/d9asrRZ9suVIvC39H3cu6KPjqihgxa676WxTr+uCHAwnVNjf9rop4Myl +Y6D4Rh0jox/Q+ObML0qvyDmTpUubrwhPyiJQvbGEv7pTVSdf0LKOGaTgo+CgCbYZAMe SKKQ== X-Gm-Message-State: ALQs6tC7Rm4Z1lcFQKIS5jHdrjXRj++rGilvdLkSwI5oXGXyUwjvY/SF 0I/mQVYYXk+4/AQ4SLwxuiZbJF6TSFr1cF5Ul/o= X-Google-Smtp-Source: AB8JxZoUfKmlEByhH+wPOtw7JcKuW9vBLag65Iussokh7bKeeU02DRi/jufcYIaH3lOTMlJCgCuRp6i+UnTQ+XJO+nE= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr2504232otk.392.1525309119032; Wed, 02 May 2018 17:58:39 -0700 (PDT) MIME-Version: 1.0 References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> In-Reply-To: <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> From: Martin Thomson Date: Thu, 03 May 2018 00:58:27 +0000 Message-ID: To: sara@sinodun.com Cc: Paul Hoffman , DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 00:58:41 -0000 On Wed, May 2, 2018 at 9:43 PM Sara Dickinson wrote: > A simple statement in Section 6 to the effect that =E2=80=98DNS API clien= ts and servers may use EDNS(0) padding [RFC7830] in the DNS wire format independently of whether or not HTTP padding is used.=E2=80=99 would suffic= e I think. That would be fine with me. Or a more general: "Padding of requests and responses can use padding provided at any protocol layer that supports it: TLS 1.3, HTTP/2, and EDNS(0) padding can all be used as desired." > > It would be lovely if Stubby could add DOH as a transport that is parallel to DNS-over-TLS, and for that there has to be some common understanding of privacy and trust levels. Duplicating to twisty mazes from DNS-over-TLS usage policies is not going to help. Instead, a new document that covers DNS-over-TLS, DOH, and the likely future DNS-over-QUIC needs to deal with this, and more clearly. > I=E2=80=99m all for that general approach but=E2=80=A6. what I think woul= d help here is: > - Can this document make any clear statement about whether or not a DNS API server is =E2=80=98trusted' if HTTPS authentication fails? If trust is attached to a name or URI, then authenticating that identifier is a critical precondition of authorizing a server. Though that isn't stated here directly, it is at implied through the use of HTTPS. I don't think that we need to explicitly restate requirements from RFC 2818 though. From nobody Wed May 2 18:07: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 E68DA127275 for ; Wed, 2 May 2018 18:07:14 -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 GMvlgwUO0Rbd for ; Wed, 2 May 2018 18:07:13 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 1CF3D127241 for ; Wed, 2 May 2018 18:07:13 -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.1178.4; Wed, 2 May 2018 18:07:11 -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.1178.000; Wed, 2 May 2018 18:07:10 -0700 From: Paul Hoffman To: Sara Dickinson CC: DoH WG Thread-Topic: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT4grBbSFsXsZVm0m2M+3OryXWv6Qdp2MA Date: Thu, 3 May 2018 01:07:10 +0000 Message-ID: <0E4C2A45-3447-43D8-84DC-692F42EDC2D0@icann.org> References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> In-Reply-To: <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.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] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 01:07:15 -0000 T24gTWF5IDIsIDIwMTgsIGF0IDQ6NDIgQU0sIFNhcmEgRGlja2luc29uIDxzYXJhQHNpbm9kdW4u Y29tPiB3cm90ZToNCj4+PiAyKSBTZWN0aW9ucyAzLCA0LjIgYW5kIDYgbWVudGlvbiB0aGUgcHJl c2VuY2Ugb2YgRUROUygwKSBvcHRpb25zLiBTZWN0aW9uIDYgc3BlY2lmaWNhbGx5IHNheXMgDQo+ Pj4g4oCcRE5TIEFQSSBjbGllbnRzIHVzaW5nIHRoZSBETlMgd2lyZSBmb3JtYXQgTUFZIGhhdmUg b25lIG9yIG1vcmUgRUROUyBvcHRpb25zIFtSRkM2ODkxXSBpbiB0aGUgcmVxdWVzdC7igJ0gDQo+ Pj4gDQo+Pj4gSW4gYSBzaW1pbGFyIG1hbm5lciB0byB0aGUgcHJvYmxlbSB3aXRoIHRydW5jYXRp b24gb2YgcmVzcG9uc2VzLCB0aGVyZSBhcmUgMiBFRE5TIG9wdGlvbnMgSSBjYW4gdGhpbmsgb2Yg dGhhdCBhcmUgdHJhbnNwb3J0IHNwZWNpZmljLCBidXQgaG93IHRvIGhhbmRsZSB0aGVtIGlzbuKA mXQgZGVzY3JpYmVkIGluIHRoaXMgZHJhZnQgaS5lLg0KPj4+IC0gRUROUygwKSBQYWRkaW5nIChX aGVuIFJGQzc4MzAgd2FzIHdyaXR0ZW4gb25seSBETlMtb3Zlci1UTFMgd2FzIHN0YW5kYXJkaXNl ZCwgYnV0IHRoZSB0ZXh0IGRvZXNu4oCZdCByZXN0cmljdCBpdCB0byB0aGF0IGl0IHNpbXBseSBz YXlzIOKAnFRoZXJlZm9yZSwgaW1wbGVtZW50YXRpb25zIE1VU1QgTk9UIHVzZSB0aGlzIG9wdGlv biBpZiB0aGUgRE5TIHRyYW5zcG9ydCBpcyBub3QgZW5jcnlwdGVkLuKAnSkuICBBbGV4YW5kZXIg TWF5cmhvZmVyIHJlcXVlc3RlZCBhIG5vdGUgYmUgYWRkZWQgYWJvdXQgdGhpcyBvcHRpb24gaW4g aGlzIHJldmlldyBvZiB0aGUgLTA0IGRyYWZ0Lg0KPj4+IC0gRUROUygwKSBLZWVwYWxpdmUgKFJG Qzc4MjgpLg0KPj4gDQo+PiBJJ20gbm90IHN1cmUgd2h5IHRoZXJlIGFyZSAicHJvYmxlbXMiIHdp dGggdGhlc2UuIEZvciBwYWRkaW5nLCB0aGUgc2VydmVyIGNhbiB1c2UgaXQgb3Igbm90Lg0KPiAN Cj4gRm9yIG1lIHRoZSBpc3N1ZSBpcyBzaW1wbHkgdGhhdCBIVFRQIHBhZGRpbmcgaXMgc3BlY2lm aWNhbGx5IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQgKHNldmVyYWwgdGltZXMpIGJ1dCB0aGF0IEVE TlMoMCkgaXNu4oCZdCBtZW50aW9uZWQgYXQgYWxsLiBBIHNpbXBsZSBzdGF0ZW1lbnQgaW4gU2Vj dGlvbiA2IHRvIHRoZSBlZmZlY3QgdGhhdCDigJhETlMgQVBJIGNsaWVudHMgYW5kIHNlcnZlcnMg bWF5IHVzZSBFRE5TKDApIHBhZGRpbmcgW1JGQzc4MzBdIGluIHRoZSBETlMgd2lyZSBmb3JtYXQg aW5kZXBlbmRlbnRseSBvZiB3aGV0aGVyIG9yIG5vdCBIVFRQIHBhZGRpbmcgaXMgdXNlZC7igJkg d291bGQgc3VmZmljZSBJIHRoaW5rLiANCg0KSXMgdGhhdCBraW5kIG9mIHNwZWNpZmljaXR5IHJl YWxseSBuZWNlc3Nhcnk/IElzbid0Og0KICAgRE5TIEFQSSBjbGllbnRzIHVzaW5nIHRoZSBETlMg d2lyZSBmb3JtYXQgTUFZIGhhdmUgb25lIG9yIG1vcmUgRUROUyBvcHRpb25zIHt7UkZDNjg5MX19 IGluIHRoZSByZXF1ZXN0Lg0KYW5kIGl0J3MgcGFpciBmb3IgRE5TIEFQSSBzZXJ2ZXJzIHN1ZmZp Y2llbnQ/IFRoYXQgaXMsIHdoeSBzaG91bGQgd2UgY2FsbCBvdXQgc29tZSBraW5kcyBvZiBFRE5T IGV4dGVuc2lvbnMgYnV0IG5vdCBvdGhlcnM/DQoNCg0KPiANCj4+IEZvciBrZWVwYWxpdmUsIGl0 IG1ha2VzIG5vIHNlbnNlIGZvciBpdCB0byBzdXBwb3J0IGl0LiBKdXN0IGxpa2UgYW55IHRyYWRp dGlvbmFsIEROUyBzZXJ2ZXIsIGEgRE9IIHNlcnZlciBoYXMgdG8gdW5kZXJzdGFuZCBpdHMgY29u dGV4dCB3aGVuIGRlY2lkaW5nIGhvdyB0byBhbnN3ZXIgcXVlcmllcyB3aXRoIEVETlMgb3B0aW9u cy4NCj4gDQo+IFtpbmNsdWRpbmcgTWFydGluJ3MgY29tbWVudF0NCj4+IFNhcmEncyByZXF1ZXN0 IGZvciB0ZXh0IHJlZ2FyZGluZyA3ODI4IGlzIHJlYXNvbmFibGUuICBHZW5lcmljIHRleHQgbWln aHQNCj4+IHN1ZmZpY2UgYWxvbmcgdGhlIGxpbmVzIG9mICJleHRlbnNpb25zIHRvIEROUyB0aGF0 IGFyZSBzcGVjaWZpYyB0byB0aGUNCj4+IGNob2ljZSBvZiB0cmFuc3BvcnQsIHN1Y2ggYXMgUkZD IDc4MjgsIGFyZSBub3QgYXBwbGljYWJsZSB0byBET0giLiAgRldJVywNCj4+IEhUVFAvMiBoYXMg aXRzIG93biBrZWVwYWxpdmUgbWVjaGFuaXNtcy4NCj4gDQo+IFByZWNpc2VseSAtIHRoZXJlIGlz IG5vIHJlYXNvbiB0byB1c2UgRUROUygwKSBLZWVwYWxpdmUgaW4gRE9IIGFuZCBETlMgQVBJIGNs aWVudHMgc2hvdWxkbuKAmXQuIEnigJlkIGJlIGhhcHB5IHdpdGggYSBzcGVjaWZpYyBzdGF0ZW1l bnQgb24gdGhhdCByYXRoZXIgdGhhbiB0aGUgZ2VuZXJpYyB0ZXh04oCmIHNpbmNlIHRoZSBhYm92 ZSBjb3VsZCBiZSB0YWtlbiB0byBleGNsdWRlIHRoZSB1c2Ugb2YgRUROUygwKSBQYWRkaW5nICh3 aGljaCBpcyBhbiBleHRlbnNpb24gc3BlY2lmaWMgdG8gZW5jcnlwdGVkIHRyYW5zcG9ydHMpLi4u DQoNCldlIGhhdmUgZm9yIHRoZSBuZXh0IHZlcnNpb246DQogICBNYW55IGV4dGVuc2lvbnMgdG8g RE5TLCB1c2luZyB7e1JGQzY4OTF9fSwgaGF2ZSBiZWVuIGRlZmluZWQgb3ZlciB0aGUgeWVhcnMu DQogICBFeHRlbnNpb25zIHRoYXQgYXJlIHNwZWNpZmljIHRvIHRoZSBjaG9pY2Ugb2YgdHJhbnNw b3J0LCBzdWNoIGFzIHt7UkZDNzgyOH19LA0KICAgYXJlIG5vdCBhcHBsaWNhYmxlIHRvIERPSC4N ClRoZSBmYWN0IHRoYXQgc29tZSBleHRlbnNpb25zIG1pZ2h0IG9yIG1pZ2h0IG5vdCBoZWxwIERP SCBzZWVtcyBsaW1pdGluZywgcGFydGljdWxhcmx5IGJlY2F1c2Ugd2UgZG9uJ3Qga25vdyBhYm91 dCBmdXR1cmUgZXh0ZW5zaW9ucy4NCg0KPj4+IDUpIFNlY3Rpb24gODogDQo+Pj4gDQo+Pj4gICJJ ZiBhIGNsaWVudCBvZiB0aGlzIHByb3RvY29sIGVuY291bnRlcnMgYW4gSFRUUA0KPj4+ICBlcnJv ciBhZnRlciBzZW5kaW5nIGEgRE5TIHF1ZXJ5LCBhbmQgdGhlbiBmYWxscyBiYWNrIHRvIGEgZGlm ZmVyZW50DQo+Pj4gIEROUyByZXRyaWV2YWwgbWVjaGFuaXNtLCBkb2luZyBzbyBjYW4gd2Vha2Vu IHRoZSBwcml2YWN5IGFuZA0KPj4+ICBhdXRoZW50aWNpdHkgZXhwZWN0ZWQgYnkgdGhlIHVzZXIg b2YgdGhlIGNsaWVudC7igJ0NCj4+PiANCj4+PiBUaGlzIHRleHQgYnJpbmdzIHVwIHRoZSBiaWdn ZXN0IGlzc3VlIEkgaGF2ZSB3aXRoIHRoZSBkb2N1bWVudCwgd2hpY2ggaXMgdGhhdCBJIHdvdWxk IGxpa2UgdG8gcmVxdWVzdCB0aGF0IGl0IHJlcGxhY2VzIHRoZSBhYm92ZSB0ZXh0IHdpdGggYSBz ZWN0aW9uIHRoYXQgY2xhcmlmaWVzIGhvdyBET0ggY2FuIGJlIHVzZWQgaW4gdGhlIGNvbnRleHQg b2YgYSBwcml2YWN5IHVzYWdlIHByb2ZpbGUgKHNlZSBib3RoIFJGQzc4NTggYW5kIFJGQzgzMTAg Zm9yIGRlc2NyaXB0aW9ucyBvZiBTdHJpY3QgdnMgT3Bwb3J0dW5pc3RpYyB1c2FnZSBwcm9maWxl cyBmb3IgRE5TLW92ZXItKEQpVExTKS4gIFRvIGJlIGNsZWFyOiBpbiB0aGVzZSBwcm9maWxlcyBv bmx5IGNvbmZpZ3VyZWQgc2VydmVycyBhcmUgdXNlZCAobm8gZGlzY292ZXJ5IGlzIGludm9sdmVk KS4gSeKAmW0gaGFwcHkgdG8gaGVscCB3aXRoIHRleHQgaGVyZSBpZiB0aGVyZSBpcyBjb25zZW5z dXMgdGhhdCB0aGlzIGlzIGluIHNjb3BlIGFuZCBiZW5lZmljaWFsIHRvIHRoZSBkb2N1bWVudC4g DQo+Pj4gDQo+Pj4gVGhlIGJpZywgYmlnIGdhaW4gSSBzZWUgaGVyZSBpcyBmb3IgYXBwbGljYXRp b25zIHN1Y2ggYXMgU3R1YmJ5IHdoaWNoIHdvdWxkIGxpa2UgdG8gaGF2ZSBhIHN0YW5kYXJkIHdh eSB0byBhZGQgRE9IIGFzIGEgdHJhbnNwb3J0IG9wdGlvbiBhbG9uZ3NpZGUgdGhlIGV4aXN0aW5n IHVzZSBvZiBETlMtb3Zlci1UTFMgd2hlbiB1c2luZyB0aG9zZSBwcm9maWxlcy4gIEluIHRoaXMg c2NlbmFyaW8gU3R1YmJ5IHdvdWxkIGJlIHRoZSDigJhjbGllbnTigJkgaW4gdGhlIHRleHQgYWJv dmUgd2hpY2ggY2FuIHVzZSBlaXRoZXIgYSBETlMgQVBJIGNsaWVudCBvciBhIOKAmHRyYWRpdGlv bmFsJyBETlMgY2xpZW50LiAgDQo+Pj4gDQo+Pj4gKEFzIGFuIGFzaWRlLCBJIG5vdGUgdGhhdCB0 aGUgYWJvdmUgaXMgdGhlIGZpcnN0IGFuZCBvbmx5IG1lbnRpb24gb2YgdGhlIHdvcmQg4oCYcHJp dmFjeScgaW4gdGhlIGRvY3VtZW50IGFuZCB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGN1cnJlbnRs eSBkZXNjcmliZSB0aGUgc3BlY2lmaWMgcHJpdmFjeSBiZW5lZml0cyBvZiB0aGlzIHNwZWNpZmlj YXRpb24gY29tcGFyZWQgdG8g4oCZb3RoZXIgbWVjaGFuaXNtc+KAmS4pDQo+Pj4gDQo+Pj4gVHdv IGFtYmlndWl0aWVzIHdpdGggdGhlIGN1cnJlbnQgdGV4dCBhcmU6DQo+Pj4gLSBSRkM4MzEwIHNh eXMgYSBETlMgY2xpZW50IHNob3VsZCBvbmx5IHVzZSBhIHNpbmdsZSBwcml2YWN5IHVzYWdlIHBy b2ZpbGUgd2hlbiByZXNvbHZpbmcgYSBzcGVjaWZpYyBxdWVyeSAocHJlY2lzZWx5IHRvIGF2b2lk IHRoZSBwcm9ibGVtIG1lbnRpb25lZCBhYm92ZSkgYnV0IHRoaXMgdGV4dCBzZWVtcyB0byBjb250 cmFkaWN0IHRoYXQuIA0KPj4+IC0gd2hpbGUgaXQgaXMgaGVhdmlseSBpbXBsaWVkIHRoZSBkb2N1 bWVudCBpc27igJl0IGFjdHVhbGx5IGNyeXN0YWwgY2xlYXIgb24gd2hldGhlciBhIGNvbmZpZ3Vy ZWQg4oCYdHJ1c3RlZOKAmSBzZXJ2ZXIgY2FuIGJlIHVzZWQgaWYgYXV0aGVudGljYXRpb24gb2Yg dGhlIGNlcnRpZmljYXRlIGZhaWxzLiANCj4+IA0KPj4gUGxlYXNlLCBuby4gT3IgYXQgbGVhc3Qs IG5vdCBoZXJlLiBUaGUgY29tcGxpY2F0ZWQgRE5TLW92ZXItVExTIHVzYWdlIHBvbGljaWVzIGFy ZSBvbmUgb2YgdGhlIHJlYXNvbnMgd2UgaGF2ZSBzbyBsaXR0bGUgaW1wbGVtZW50YXRpb24gb2Yg RE5TLW92ZXItVExTLiAoT3RoZXJzIG1heSBkaXNhZ3JlZSB3aXRoIHRoaXMgc3RhdGVtZW50LikN Cj4gDQo+IFtJbmNsdWRpbmcgTWFydGlucyBjb21tZW50XQ0KPj4gSSBhZ3JlZSB3aXRoIFBhdWwg LSB0aGUgcHJvZmlsZSBpbiBSRkMgODMxMCBvdmVybGFwcyBjb25zaWRlcmFibHkgd2l0aCB0ZXh0 DQo+PiBpbiBIVFRQIFJGQ3MuICBGb3IgaW5zdGFuY2UsIEhUVFAvMiBhbHJlYWR5IG1hbmRhdGVz IFRMUyAxLjIgb3IgZ3JlYXRlcg0KPj4gd2l0aG91dCBjb21wcmVzc2lvbiAoaXQgYWxzbyBnb2Vz IGZ1cnRoZXIgdG8gcmVxdWlyZSBQRlMpLiAgODMxMCBhbHNvDQo+PiBtaXNzZXMgYSBmZXcgdGhp bmdzIHRoYXQgRE9IIGNvdmVycywgc3VjaCBhcyB0aGUgT0NTUC9BSUEgZGVhZGxvY2suDQo+PiAN Cj4+IFRoZSB0cnVlIGFkdmFudGFnZSBvZiBET0ggaXMgdGhhdCBpdCBqdXN0IHVzZXMgSFRUUC4g IEFuZCB0aGF0IG1lYW5zDQo+PiByZWx5aW5nIG9uIEhUVFAgbWVjaGFuaXNtcyBmb3IgZW5zdXJp bmcgaW50ZWdyaXR5LCBjb25maWRlbnRpYWxpdHksIGFuZA0KPj4gYXV0aGVudGljYXRpb24uICBJ IHRoaW5rIHRoYXQgdGhvc2UgYXJlIGJyb2FkbHkgYWRlcXVhdGUuDQo+PiANCj4+IFNlcGFyYXRl bHksIEknZCBzdWdnZXN0IHRoYXQgdGhlIDgzMTAgcHJvZmlsZSByZXF1aXJlbWVudHMgYXJlDQo+ PiB1bnJlYWxpc3RpYy4gIEknbSBub3QgYXdhcmUgb2YgbWFueSBpbXBsZW1lbnRhdGlvbnMgdGhh dCBkbyByYXcgcHVibGljIGtleXMNCj4+IG9yIGNhY2hlZCBpbmZvLiAgSSBhbHNvIGRvbid0IHNl ZSBhbnkgcGFydGljdWxhciB2YWx1ZSBpbiBtYW5kYXRpbmcgdGlja2V0cw0KPj4gYW5kIGZhbHNl IHN0YXJ0IC0gdGhleSBlYWNoIHByb3ZpZGUgYW1wbGUgbW90aXZhdGlvbiBvbiB0aGVpciBvd24g d2l0aG91dA0KPj4gbmVlZGluZyBhIE1VU1QuDQo+IA0KPiBNeSByZXF1ZXN0IHdhcyBub3QgYXQg YWxsIHRvIGhhdmUgUkZDODMxMCB0byBhcHBseSBoZXJlIGluIGdlbmVyYWwgLSBJIGNvbXBsZXRl bHkgYWdyZWUgdGhhdCBkb2VzbuKAmXQgbWFrZSBhbnkgc2Vuc2UsIGFuZCBJIGRpZG7igJl0IGV2 ZW4gbWVhbiB0aGlzIGRvY3VtZW50IHNob3VsZCBhZG9wdCBTdHJpY3QgdnMgT3Bwb3J0dW5pc3Rp Yy4NCj4gDQo+PiBJdCB3b3VsZCBiZSBsb3ZlbHkgaWYgU3R1YmJ5IGNvdWxkIGFkZCBET0ggYXMg YSB0cmFuc3BvcnQgdGhhdCBpcyBwYXJhbGxlbCB0byBETlMtb3Zlci1UTFMsIGFuZCBmb3IgdGhh dCB0aGVyZSBoYXMgdG8gYmUgc29tZSBjb21tb24gdW5kZXJzdGFuZGluZyBvZiBwcml2YWN5IGFu ZCB0cnVzdCBsZXZlbHMuIER1cGxpY2F0aW5nIHRvIHR3aXN0eSBtYXplcyBmcm9tIEROUy1vdmVy LVRMUyB1c2FnZSBwb2xpY2llcyBpcyBub3QgZ29pbmcgdG8gaGVscC4gSW5zdGVhZCwgYSBuZXcg ZG9jdW1lbnQgdGhhdCBjb3ZlcnMgRE5TLW92ZXItVExTLCBET0gsIGFuZCB0aGUgbGlrZWx5IGZ1 dHVyZSBETlMtb3Zlci1RVUlDIG5lZWRzIHRvIGRlYWwgd2l0aCB0aGlzLCBhbmQgbW9yZSBjbGVh cmx5Lg0KPiANCj4gSeKAmW0gYWxsIGZvciB0aGF0IGdlbmVyYWwgYXBwcm9hY2ggYnV04oCmLiB3 aGF0IEkgdGhpbmsgd291bGQgaGVscCBoZXJlIGlzOiANCj4gDQo+IC0gQ2FuIHRoaXMgZG9jdW1l bnQgbWFrZSBhbnkgY2xlYXIgc3RhdGVtZW50IGFib3V0IHdoZXRoZXIgb3Igbm90IGEgRE5TIEFQ SSBzZXJ2ZXIgaXMg4oCYdHJ1c3RlZCcgaWYgSFRUUFMgYXV0aGVudGljYXRpb24gZmFpbHM/DQoN CkkgZG9uJ3QgdGhpbmsgc28sIG5vdCB3aXRob3V0IHJ1bm5pbmcgc21hY2sgaW50byB0aGUgRE5T LW92ZXItVExTLXBvbGljeSB3YWxsIGFib3ZlLg0KDQo+IFRoZXJlIGlzIGFuIGltcGxpZWQgTVVT VCBpbiBzZWN0aW9uIDkg4oCcd2hpbGUgc3RpbGwgYXV0aGVudGljYXRpbmcgdGhlIHJlc3VsdGlu ZyBjb25uZWN0aW9uIHZpYSBIVFRQU+KAnS4gSWYgdGhlcmUgaXMgYWN0dWFsbHkgYSBNVVNUIGhl cmUgdGhlbiBJIGJlbGlldmUgdGhhdCBhY3R1YWxseSBuYXR1cmFsbHkgbWFwcyB0byB1c2luZyBE T0ggb25seSB3aXRoIGEgU3RyaWN0IHByb2ZpbGUgZm9yIGNsaWVudCB0aGF0IGFscmVhZHkgaW1w bGVtZW50IHRoYXQgKGluIHRoZSBzaG9ydC10ZXJtIGFuZCBpbiB0aGUgYWJzZW5jZSBvZiBhbnkg b3RoZXIgZ3VpZGFuY2UgLSB3ZSBhcmUgYWRkaW5nIERPSCB0byBTdHViYnkgcmlnaHQgbm93KS4N Cg0KQXMgd2VsbCB5b3Ugc2hvdWxkLiANCg0KPiAtIElmIHRoZXJlIGlzIG5vIHJlcXVpcmVtZW50 IHJlbGF0aW5nIHRvIHRoaXMgb3IgaWYgdGhhdCBpcyBkZWVtZWQgdG8gYmUgb3V0IG9mIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQgYW5kIHdpbGwgYmUgdGhlIHN1YmplY3Qgb2YgZnV0dXJlIHdvcmsg dGhlbiBwbGVhc2Ugc3RhdGUgdGhhdCBleHBsaWNpdGx5LiANCg0KUGVyc29uYWxseSwgSSBkaXNs aWtlIHJlYWRpbmcgYW4gUkZDIHRoYXQgdGFsa3MgYWJvdXQgZnV0dXJlIHdvcmsgYmVjYXVzZSBp dCBpcyBpbXBvc3NpYmxlIHRvIGZpbmQgaXQsIHBhcnRpY3VsYXJseSBpZiBpdCBpc24ndCBmaW5p c2hlZC4NCg0KPiAoQXMgYSBnZW5lcmFsIHBvaW50LCBpbiByZXZpZXdpbmcgSSBoYWQgdG8gdHJh d2wgdGhyb3VnaCB0aGUgbWFpbGluZyBsaXN0IGFnYWluIHRvIHVuZGVyc3RhbmQgd2hhdCB3YXMg aW4gYW5kIG91dCBvZiBzY29wZSAtIGEgc2VjdGlvbiBpbiB0aGUgZG9jdW1lbnQgY2xhcmlmeWlu ZyB0aGF0IHdvdWxkIGFjdHVhbGx5IGJlIHZlcnkgaGVscGZ1bCBJIGJlbGlldmUpLiAgDQoNCk5v dGVkLiBXaGVyZWFzIG90aGVycyB3YW50IHRvIHJlbW92ZSB0aGUgY3VycmVudCBSZXF1aXJlbWVu dHMgc2VjdGlvbi4NCg0KPj4+IDYpIFNlY3Rpb24gOTogDQo+Pj4gDQo+Pj4g4oCcQSBETlMgQVBJ IGNsaWVudCBtYXkgZmFjZSBhIHNpbWlsYXIgYm9vdHN0cmFwcGluZyBwcm9ibGVtIHdoZW4gdGhl DQo+Pj4gSFRUUCByZXF1ZXN0IG5lZWRzIHRvIHJlc29sdmUgdGhlIGhvc3RuYW1lIHBvcnRpb24g b2YgdGhlIEROUyBVUkkuIg0KPj4+IA0KPj4+IOKAnC4uLm9yIHJlc29sdmluZyB0aGUgRE5TIEFQ SSBzZXJ2ZXIncyBob3N0bmFtZSB2aWEgdHJhZGl0aW9uYWwgRE5TIOKAnA0KPj4+IA0KPj4+IERO Uy1vdmVyKEQpVExTIHVzaW5nIG9ubHkgYSBjb25maWd1cmVkIGF1dGhlbnRpY2F0aW9uIGRvbWFp biBuYW1lIHNoYXJlcyBtYW55IG9mIHRoZSBkaXNjb3ZlcnkgaXNzdWVzIHRoYXQgRG9IIGhhcy4g UGFyYWdyYXBoIDQgb2YgU2VjdGlvbiA5IG92ZXJsYXBzIHdpdGggdGhlIGRpc2N1c3Npb24gb2Yg 4oCYbWV0YS1xdWVyaWVz4oCZIGFzIGFscmVhZHkgZGVzY3JpYmVkIGluIG1vcmUgZGV0YWlsIGlu IFJGQzgzMTAgYW5kIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgdGhlIGxhbmd1YWdlIGNvdWxkIGJl IGFsaWduZWQgb3IgaWYgUkZDODMxMCB3YXMgYXQgbGVhc3QgcmVmZXJlbmNlZCBoZXJlLiBPbmUg b2YgdGhlIGlzc3VlcyBkaXNjdXNzZWQgaW4gdGhhdCBkb2N1bWVudCBpcyB0aGUgcG90ZW50aWFs IGZvciBkZW5pYWwtb2Ytc2VydmljZSBpZiB0aGVzZSBtZXRhLXF1ZXJpZXMgYXJlIHN1YmplY3Qg dG8gYXR0YWNrLCB3aGljaCBzZWVtcyB3b3J0aHkgb2Ygbm90ZS4gQWdhaW4sIGhhcHB5IHRvIGhl bHAgd2l0aCB0ZXh0IGhlcmUuDQo+IA0KPiANCj4g4oCcQWx0ZXJuYXRpdmUgc3RyYXRlZ2llcyBh IGNsaWVudCBtaWdodCBlbXBsb3kNCj4gICBpbmNsdWRlIG1ha2luZyB0aGUgaW5pdGlhbCByZXNv bHV0aW9uIHBhcnQgb2YgdGhlIGNvbmZpZ3VyYXRpb24sIElQDQo+ICAgYmFzZWQgVVJJcyBhbmQg Y29ycmVzcG9uZGluZyBJUCBiYXNlZCBjZXJ0aWZpY2F0ZXMgZm9yIEhUVFBTLCBvcg0KPiAgIHJl c29sdmluZyB0aGUgRE5TIEFQSSBzZXJ2ZXIncyBob3N0bmFtZSB2aWEgdHJhZGl0aW9uYWwgRE5T IG9yDQo+ICAgYW5vdGhlciBETlMgQVBJIHNlcnZlciB3aGlsZSBzdGlsbCBhdXRoZW50aWNhdGlu ZyB0aGUgcmVzdWx0aW5nDQo+ICAgY29ubmVjdGlvbiB2aWEgSFRUUFMu4oCdDQo+IA0KPiBQcm9w b3NlIGFkZGluZyANCj4g4oCcSXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgc29tZSBvZiB0aGVzZSBi b290c3RyYXBwaW5nIG1lY2hhbmlzbXMgY2FuIGJlIGFjdGl2ZWx5IGF0dGFja2VkIHdoaWNoIGNh biByZXN1bHQgaW4gZGVuaWFsLW9mLXNlcnZpY2UgZm9yIERPSCBjbGllbnRzIGluIGEgc2ltaWxh ciBtYW5uZXIgdG8gdGhhdCBmb3IgRE5TLW92ZXItVExTIG1ldGEtcXVlcmllcyBbUkZDODMxMF0u IOKAnA0KDQpUaGUgZGVuaWFsLW9mLXNlcnZpY2UgaXMgb24gRE9IIHNlcnZpY2UsIG5vdCBvbiBE TlMgc2VydmljZS4gVGhpcyBnb2VzIGJhY2sgdG8gdGhlIHF1ZXN0aW9ucyBhYm92ZS4gSSBzaW1w bHkgZG9uJ3QgdGhpbmsgd2UgKG9yIERQUklWRSwgZm9yIHRoYXQgbWF0dGVyKSBoYXZlIGNsZWFy IHRoaW5raW5nIG9uIHRoaXMgeWV0Lg0KDQotLVBhdWwgSG9mZm1hbg== From nobody Wed May 2 18:09: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 C0682127241 for ; Wed, 2 May 2018 18:09:27 -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 H98AsuCDjfXT for ; Wed, 2 May 2018 18:09:24 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89243127286 for ; Wed, 2 May 2018 18:09:24 -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.1178.4; Wed, 2 May 2018 18:09:22 -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.1178.000; Wed, 2 May 2018 18:09:22 -0700 From: Paul Hoffman To: Sara Dickinson CC: DoH WG Thread-Topic: [Ext] [Doh] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT4ntfU0d5oFjoxkmwtaX8yfa5wg== Date: Thu, 3 May 2018 01:09:22 +0000 Message-ID: <9972068C-8CD1-4389-B3E1-0B2DA2417DAD@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_64CF98AD-0B08-4854-ABA4-7AC0DEB33275"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 01:09:28 -0000 --Apple-Mail=_64CF98AD-0B08-4854-ABA4-7AC0DEB33275 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 2, 2018, at 6:23 AM, Sara Dickinson wrote: >=20 > One other last nit/question on this. The WG charts states: >=20 > =E2=80=9CThe primary focus of this working group is to develop a = mechanism that > provides confidentiality and connectivity between DNS clients (e.g., = operating > system stub resolvers) and recursive resolvers.=E2=80=9D >=20 > But the definitions in the Terminology are simply =E2=80=98DNS API = client' and =E2=80=98DNS API server=E2=80=99. Much of the discussion of = caching and DNSSEC is specific to stup-resolver interactions so I think = this needs to be addressed. >=20 > I suggest stating the scope clearly in the draft e.g.: >=20 > "This document focuses on communication between DNS clients (e.g., = operating > system stub resolvers) and recursive resolvers, as per > the charter of the DOH Working Group at the time of writing.=E2=80=9D Good catch, yes. --Paul Hoffman --Apple-Mail=_64CF98AD-0B08-4854-ABA4-7AC0DEB33275 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE9O5bDZQPcZB6WYPRsZnCoeEPRXsFAlrqYUEACgkQsZnCoeEP RXtSdQf+LZ2E3d6UWi4o1vsVk+Zlu5JSNjFEieIu5+Ba11EVlp7ozNM1NsT1EbZb G5uVLBuqgCguNvymm65O60/JzJEnfge8Yzldwz9EP1gz+OeRQk/qEzvLUynFBQJN V4gFABn/Vpu/8J6/IeSV+ctCIinq8gmn8+JaPbPw4wXNEBJ0ua9cHfKPBalauuW1 bGvomPClzWalj3Q9Lz/4p3pedn5n2vHUUU9KgrsmFy66B+jkaaHTq1JRDG2flCDD FHxjCV0zNwT2fdmwPP/x0CR5kRKYY206c9ssWoqgSZzrtfxxUt+6ZApKJfAq2DWn t3N1UeCPhd3YmEp/iSXGJX2gHFHI2w== =FaDv -----END PGP SIGNATURE----- --Apple-Mail=_64CF98AD-0B08-4854-ABA4-7AC0DEB33275-- From nobody Thu May 3 04:57: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 D5D9D126CC4 for ; Thu, 3 May 2018 04:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWh1lVNomkfY for ; Thu, 3 May 2018 04:57:26 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4942124E15 for ; Thu, 3 May 2018 04:57:26 -0700 (PDT) Received: from [62.232.251.194] (port=18760 helo=[192.168.12.23]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fECrS-0004zo-JN; Thu, 03 May 2018 12:57:24 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sara Dickinson In-Reply-To: <0E4C2A45-3447-43D8-84DC-692F42EDC2D0@icann.org> Date: Thu, 3 May 2018 12:56:38 +0100 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <5CBE3FB6-90C8-4315-A2C4-A25BA3BEF288@sinodun.com> References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> <0E4C2A45-3447-43D8-84DC-692F42EDC2D0@icann.org> To: Paul Hoffman , Martin Thomson X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 11:57:29 -0000 > On 3 May 2018, at 02:07, Paul Hoffman wrote: >=20 > On May 2, 2018, at 4:42 AM, Sara Dickinson wrote: >>>> 2) Sections 3, 4.2 and 6 mention the presence of EDNS(0) options. = Section 6 specifically says=20 >>>> =E2=80=9CDNS API clients using the DNS wire format MAY have one or = more EDNS options [RFC6891] in the request.=E2=80=9D=20 >>>>=20 >>>> In a similar manner to the problem with truncation of responses, = there are 2 EDNS options I can think of that are transport specific, but = how to handle them isn=E2=80=99t described in this draft i.e. >>>> - EDNS(0) Padding (When RFC7830 was written only DNS-over-TLS was = standardised, but the text doesn=E2=80=99t restrict it to that it simply = says =E2=80=9CTherefore, implementations MUST NOT use this option if the = DNS transport is not encrypted.=E2=80=9D). Alexander Mayrhofer = requested a note be added about this option in his review of the -04 = draft. >>>> - EDNS(0) Keepalive (RFC7828). >>>=20 >>> I'm not sure why there are "problems" with these. For padding, the = server can use it or not. >>=20 >> For me the issue is simply that HTTP padding is specifically = mentioned in the draft (several times) but that EDNS(0) isn=E2=80=99t = mentioned at all. A simple statement in Section 6 to the effect that = =E2=80=98DNS API clients and servers may use EDNS(0) padding [RFC7830] = in the DNS wire format independently of whether or not HTTP padding is = used.=E2=80=99 would suffice I think.=20 >=20 > Is that kind of specificity really necessary? Isn't: > DNS API clients using the DNS wire format MAY have one or more EDNS = options {{RFC6891}} in the request. > and it's pair for DNS API servers sufficient? That is, why should we = call out some kinds of EDNS extensions but not others? See below. >=20 >=20 >>=20 >>> For keepalive, it makes no sense for it to support it. Just like any = traditional DNS server, a DOH server has to understand its context when = deciding how to answer queries with EDNS options. >>=20 >> [including Martin's comment] >>> Sara's request for text regarding 7828 is reasonable. Generic text = might >>> suffice along the lines of "extensions to DNS that are specific to = the >>> choice of transport, such as RFC 7828, are not applicable to DOH". = FWIW, >>> HTTP/2 has its own keepalive mechanisms. >>=20 >> Precisely - there is no reason to use EDNS(0) Keepalive in DOH and = DNS API clients shouldn=E2=80=99t. I=E2=80=99d be happy with a specific = statement on that rather than the generic text=E2=80=A6 since the above = could be taken to exclude the use of EDNS(0) Padding (which is an = extension specific to encrypted transports)... >=20 > We have for the next version: > Many extensions to DNS, using {{RFC6891}}, have been defined over = the years. > Extensions that are specific to the choice of transport, such as = {{RFC7828}}, > are not applicable to DOH. As stated, EDNS(0) Padding is specific to the transport choice (it = cannot be used on unencrypted transports) so this statement would rule = out using it.=20 > The fact that some extensions might or might not help DOH seems = limiting, particularly because we don't know about future extensions. I actually don=E2=80=99t have a problem with making the generic = statement because I agree with your point here, but lets be clear about = the extent of it. So, for clarity I would include RFC7830 in the list if = this option is taken. If the consensus is to make specific statements then Martin=E2=80=99s = proposed text "Padding of requests and responses can use padding provided at any protocol layer that supports = it: TLS 1.3, HTTP/2, and EDNS(0) padding can all be used as desired.=E2=80= =9D WFM >>>> 5) Section 8:=20 >>>>=20 >>=20 >> I=E2=80=99m all for that general approach but=E2=80=A6. what I think = would help here is:=20 >>=20 >> - Can this document make any clear statement about whether or not a = DNS API server is =E2=80=98trusted' if HTTPS authentication fails? >=20 > I don't think so, not without running smack into the = DNS-over-TLS-policy wall above. I=E2=80=99m asking specifically about requirements on HTTPS = authentication, nothing related to DNS-over-TLS here... Hum=E2=80=A6Martin seems to think differently: > On 3 May 2018, at 01:58, Martin Thomson = wrote: >=20 >> I=E2=80=99m all for that general approach but=E2=80=A6. what I think = would help here is: >>=20 >> - Can this document make any clear statement about whether or not a = DNS >> API server is =E2=80=98trusted' if HTTPS authentication fails? >=20 > If trust is attached to a name or URI, then authenticating that = identifier > is a critical precondition of authorizing a server. Though that isn't > stated here directly, it is at implied through the use of HTTPS. I = don't > think that we need to explicitly restate requirements from RFC 2818 = though. Maybe you do for the DNS audience=E2=80=A6. I=E2=80=99ve talked to 3 = other DNS folks who read the draft and were not clear on that=E2=80=A6.. >=20 >>>> 6) Section 9:=20 >>>>=20 >>>> =E2=80=9CA DNS API client may face a similar bootstrapping problem = when the >>>> HTTP request needs to resolve the hostname portion of the DNS URI." >>>>=20 >>>> =E2=80=9C...or resolving the DNS API server's hostname via = traditional DNS =E2=80=9C >>>>=20 >>>> DNS-over(D)TLS using only a configured authentication domain name = shares many of the discovery issues that DoH has. Paragraph 4 of Section = 9 overlaps with the discussion of =E2=80=98meta-queries=E2=80=99 as = already described in more detail in RFC8310 and it would be helpful if = the language could be aligned or if RFC8310 was at least referenced = here. One of the issues discussed in that document is the potential for = denial-of-service if these meta-queries are subject to attack, which = seems worthy of note. Again, happy to help with text here. >>=20 >>=20 >> =E2=80=9CAlternative strategies a client might employ >> include making the initial resolution part of the configuration, IP >> based URIs and corresponding IP based certificates for HTTPS, or >> resolving the DNS API server's hostname via traditional DNS or >> another DNS API server while still authenticating the resulting >> connection via HTTPS.=E2=80=9D >>=20 >> Propose adding=20 >> =E2=80=9CIt should be noted that some of these bootstrapping = mechanisms can be actively attacked which can result in = denial-of-service for DOH clients in a similar manner to that for = DNS-over-TLS meta-queries [RFC8310]. =E2=80=9C > This goes back to the questions above. I simply don't think we (or = DPRIVE, for that matter) have clear thinking on this yet. If the document is going to enumerate the possible bootstrapping = techniques then I think it should at least make some statement about the = security considerations of using them, or else kick all discussion of = bootstrapping options to the future document. I also don=E2=80=99t think = there is anything unclear about the specific attack path described in = the above text.=20 Sara.=20 From nobody Fri May 4 04:54: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 B47BD126CBF for ; Fri, 4 May 2018 04:54:53 -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 0elPBrtnVNHv for ; Fri, 4 May 2018 04:54:51 -0700 (PDT) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 342141201F2 for ; Fri, 4 May 2018 04:54:51 -0700 (PDT) Received: by mail-ot0-x229.google.com with SMTP id j27-v6so24144614ota.5 for ; Fri, 04 May 2018 04:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NOztDM1pJs390H2dM3NC/ZQdvijKQd9MBoYBHCGdjZA=; b=IVx6wLO1KLFZ/VH2qMnfaEQGcVOZXexOAE4J9scQ3RzPyc7O+mEHjRtorfjiwvvej3 wQmPnSkAyOEffmTQ0z+LEsjeoaA1w9gPdjXrVPOz16KJIFdtCFpvwd8T83WLS2Jv46fL /80HhSMMd+hzg/OQZ8yUdQMjWCfm09h04ypDqPPjY6U2UYM4p8r38iwpKrC/N9ZoZI8+ bixXd1odJqHrHAn0Ycr5tMuZwMan1ztK2uTJB5Gjo77aC6j6nUS8xT4LCMqfVVJlT9cE ZqXSsjjb7MLneao4fDM6QW0b7mMheo5CQ0pSHxoL670cakJDEyTnIi+gNqXQq5N0u7qt +ALQ== 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:content-transfer-encoding; bh=NOztDM1pJs390H2dM3NC/ZQdvijKQd9MBoYBHCGdjZA=; b=mgD3Sd8fCfA3uOWfx8kzhazuoXvvvn73bE4NVlBNw4TbFPeTnnaxwIxWb0rQGZR8/2 Tl5m3wpNfT4gMeSuGM+XsKwjpT4hpR0o0xG+g7LTbfvYqydhroYChyKrji7Uhjjpk11/ TLnUSlkSwF1kiS/zXM4LxfH4av9mYQBx6GMrQ1fqM1/RA1/uyIyv+jr892TyzLWEjbSC mOSAdDdDY9FPcFgiQIl5zUAgtJrvZWOikToUzgrGWU6PSHyIUZDVhR+wPF3I4RAp05sQ qs5UPHW+29W8x5vM4a7kvf1XVuZzF1CJwTWQo7GMVoWyFDYOWWtZDSqBsxLrc52fcPb+ mRwg== X-Gm-Message-State: ALQs6tAO/u++oGxrVEiMgwuomGhJSjaspDMPDUObxJkOk5JS5LIiwXBE JReyzhleDVkSoFo8zh23JaRSf9BhL8Kis/0gdiY= X-Google-Smtp-Source: AB8JxZr5tGrv88jlDQ5u/jPtWg0VB+w16UHTAjmIGhKxAabR7mqCCNO/tVfNYhGA90t5UsYy5SdBnW1j+6h5RqwvbrI= X-Received: by 2002:a9d:1b6d:: with SMTP id l100-v6mr19640948otl.127.1525434890655; Fri, 04 May 2018 04:54:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.194.24 with HTTP; Fri, 4 May 2018 04:54:50 -0700 (PDT) In-Reply-To: <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.com> From: Alexander Mayrhofer Date: Fri, 4 May 2018 13:54:50 +0200 Message-ID: To: Sara Dickinson Cc: Paul Hoffman , DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 11:54:54 -0000 Hello, [comments inline on Padding] On Wed, May 2, 2018 at 1:42 PM, Sara Dickinson wrote: >> I'm not sure why there are "problems" with these. For padding, the serve= r can use it or not. > > For me the issue is simply that HTTP padding is specifically mentioned in= the draft (several times) but that EDNS(0) isn=E2=80=99t mentioned at all.= A simple statement in Section 6 to the effect that =E2=80=98DNS API client= s and servers may use EDNS(0) padding [RFC7830] in the DNS wire format inde= pendently of whether or not HTTP padding is used.=E2=80=99 would suffice I = think. I do agree with Sara on this. It seems incomplete to mention HTTP padding a few times, but not mention DNS padding at all, given that the protocol is a "mixture" of both worlds. And remembering a few discussions i had with fellow encryption gurus, it seems preferrable to perform padding at the "innermost" level, where the application has the greatest extent of control over whether or not padding has been performed, and to what extent. Looking at the layering of DOH, that probably means that EDNS padding gives an app more control than HTTP padding, and HTTP padding gives an application more control than padding on the TLS layer. Therefore, i do suggest that we do mention EDNS padding as at least an equal choice to HTTP padding. I can prepare text (or a pull request if that is preferred). best, Alex From nobody Fri May 4 07:21: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 EFFF912895E for ; Fri, 4 May 2018 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iv3q1Ai7Yff for ; Fri, 4 May 2018 07:21:35 -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 CDBAF127AD4 for ; Fri, 4 May 2018 07:21:34 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id j186-v6so3559035ita.5 for ; Fri, 04 May 2018 07:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yw4Q0QI4PicI7/UjxWl9JUlHNOSLfboRH/nChLh6oyo=; b=ZZXe5WaqJBZBThUNTvjKhTT8V5ZWLu3HeI17GhDkuudAT7BS0v6aZko8cJdpA17PfP Vr1meuY4KvmvGelOoLFBrpTPqk3jVbN+6ThxNj8fBI9XwZysiBV4QJ8BdebaAKD45m4M Imgw2jAVSttycYUhZKkIUFpA+ZXj/z4fpze0ZBkDFaf0X+3Rv/Og2lKd6k7l2HB5Rb7X aiGLoVgnUdFE8pSZMhbp1BoLo1M4SEvj/fsyn1w430Kuwa0Pzlr2843UZ2j1H9G1EBiW T9vRXGX/01QKWtcAqf4DJUi7gSVAHBr/dDfAxD+SEr9NmiOhFgkypXxe3cQPc6tC00yv UUjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yw4Q0QI4PicI7/UjxWl9JUlHNOSLfboRH/nChLh6oyo=; b=mipwkCZazFzComM6BB9qXt0ySlLqnJHEGXEFYClm/tYUjloCKWNxSzqyKP6mQN2gSC ALBYlmYvGzIW9Os1Yf7NUYFJFTQY99+HvSrYBlYjJXUUPzEVFmcdH6Vo3UUv/YnlDUxO 7yQ07nDkYXMMd/XzApiHej64JLL3QIoXwuLQfcpn1OKnzU+VxMj5NsZdSL6bO9CobhSG R2UptzXzrDnJuL6Je+K37rLqxIM79lCF6rST+0rJ+P9F+3bb52CBBc9OubD4rDwgHsnD MBBUmPonl5QPxhcPx8WrnEFUZFv6dKEic49ndP8fGcWctacWeaVszyLLFEfPn4PEv2Rs yp2w== X-Gm-Message-State: ALQs6tCzJWuZ/6Uq1oAkn2kgJoky7TItfNRYLNDWGzIh2z/IFb7Gi8o/ VdLm+W7J5fmLcU1C6t85ZZyqY5BbDOgY4G0+sQ+v63RUGRg= X-Google-Smtp-Source: AB8JxZodj5DN09qoEV7oHEBH7pAm8Z/dxp7RgnloSlmydn04qRgvxDHbY866rx+7s/52DogHDkQFO/t+pD4toahb89M= X-Received: by 2002:a24:bd49:: with SMTP id x70-v6mr27385661ite.21.1525443693592; Fri, 04 May 2018 07:21:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.70.12 with HTTP; Fri, 4 May 2018 07:21:32 -0700 (PDT) From: Ben Schwartz Date: Fri, 4 May 2018 10:21:32 -0400 Message-ID: To: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000856152056b62090a" Archived-At: Subject: [Doh] New tool for using and testing DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 14:21:37 -0000 --000000000000856152056b62090a Content-Type: multipart/alternative; boundary="0000000000007bf15e056b620965" --0000000000007bf15e056b620965 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi DOH, (No chair hat) My colleagues and I have been trying to make it easier to experience DNS over HTTPS, and determine how well it performs in real-world usage. To that end, I=E2=80=99m pleased to announce Intra, an experimental DNS over H= TTPS client app for Android. Intra routes all DNS queries on your Android device through a DOH server of your choice. (Currently only dns.google.com or cloudflare-dns.com, but I expect we=E2=80=99ll eventually figure out a w= ay to let you add your own). App: https://play.google.com/store/apps/details?id=3Dapp.intra Source code: https://github.com/jigsaw-code/intra Intra currently uses Google=E2=80=99s pre-standard version of DOH with dns.google.com, and uses draft-ietf-doh-dns-over-https with cloudflare-dns.com. Let me know if you have questions or feedback about the app. --Ben --0000000000007bf15e056b620965 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi DOH,

(No chair hat)
=

My colleagues and I have been trying to make it easier = to experience DNS over HTTPS, and determine how well it performs in real-wo= rld usage.=C2=A0 To that end, I=E2=80=99m pleased to announce Intra, an exp= erimental DNS over HTTPS client app for Android.=C2=A0 Intra routes all DNS= queries on your Android device through a DOH server of your choice. (Curre= ntly only dns.google.com or cloudflare-dns.com, but I expect we=E2= =80=99ll eventually figure out a way to let you add your own).

Intra curre= ntly uses Google=E2=80=99s pre-standard version of DOH with dns.google.com, and uses draft-ietf-doh-dns-over-htt= ps with cloudflare-dns.com.
=

Let me know if you have questions or feedback about the= app.

--Ben
--0000000000007bf15e056b620965-- --000000000000856152056b62090a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBzQc4XnofNXonfK8r2Es/X fk9JXlXr7ZsmRgB0M5DA9TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MDQxNDIxMzRaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZNzKsfh6uFAFA64xGBg+l0AyzgwAybUJ8vOvgImj 3b7JRlVQMfRHJVzi9+FocxB6DiQeWKNcbZfVDq3Hv8DdpdgRblPXRlTp7EM635Fh2bfZM5AEfhTn kvBQWgQHwKmI1m2kperGgMQRNn750q9I2Xfdv68X5pv9goZR+OL25gyGWvkmdK11jP7rMpTi5vx1 /fAugNeEV9bpeZ1Txg9IGQcDaPXtPkg3H9LGzV00FnQ+7OioldrRflkfM0bEI5NWDud11+sFliYD d2XBeiSchc0pyYetiKs2jPjcOPOvJhFClvGUJce81DrLyRdsoIX458No9SkNmdNMT78MUGlbMg== --000000000000856152056b62090a-- From nobody Fri May 4 08:29: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 1CB8E12D7F1 for ; Fri, 4 May 2018 08:29: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 ZCK3uJTz0Lss for ; Fri, 4 May 2018 08:29:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80AB012D779 for ; Fri, 4 May 2018 08:29:14 -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.1178.4; Fri, 4 May 2018 08:29:12 -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.1178.000; Fri, 4 May 2018 08:29:12 -0700 From: Paul Hoffman To: Ben Schwartz CC: DoH WG Thread-Topic: [Ext] [Doh] New tool for using and testing DOH Thread-Index: AQHT47M6gSQ7tpUURkarkIsS2nP8pqQgJz+A Date: Fri, 4 May 2018 15:29:11 +0000 Message-ID: <8C5EE3D3-D07A-4CC2-AE6D-75E98F040736@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_CFECDCC8-72C5-4752-8D68-64447C427C23"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] New tool for using and testing DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 15:29:16 -0000 --Apple-Mail=_CFECDCC8-72C5-4752-8D68-64447C427C23 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 4, 2018, at 7:21 AM, Ben Schwartz wrote: > Intra currently uses Google=E2=80=99s pre-standard version of DOH with = dns.google.com, and uses draft-ietf-doh-dns-over-https with = cloudflare-dns.com. >=20 > Let me know if you have questions or feedback about the app. =46rom the Looking A Gift Horse In The Mouth Department: Could you please lean hard on dns.google.com to add support for = draft-ietf-doh-dns-over-https? Only offering a non-standard way to do = this is surely going to cause later interop issues when developers say = "I did DOH the Google way". --Paul Hoffman= --Apple-Mail=_CFECDCC8-72C5-4752-8D68-64447C427C23 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL6zCCBZUw ggR9oAMCAQICEAHlUc/Wu3bw9qj3vjSgnBAwDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBMB4XDTE1MDYyOTAwMDAwMFoXDTE4MDYyOTEy MDAwMFowgbQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRQwEgYDVQQHEwtMb3Mg QW5nZWxlczE8MDoGA1UEChMzSW50ZXJuZXQgQ29ycG9yYXRpb24gZm9yIEFzc2lnbmVkIE5hbWVz IGFuZCBOdW1iZXJzMRUwEwYDVQQDEwxQYXVsIEhvZmZtYW4xJTAjBgkqhkiG9w0BCQEWFnBhdWwu aG9mZm1hbkBpY2Fubi5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDFp+z8d5Ge 3VPgAkNc47Br7C7lVgMGi3KPyzdtdsjKDFmk8G0b4YNv+pmv8TvISr4XRpHf/+u/+1n7wkKhjVjk rY32PWhXEzk5Vky2MGaS9DiNSGwmyY6FXXxwFR8/e9f/DNZy2UEeYFrHz/kIzf5cwwdfrNEPkds8 FNfftOzdg195KOGVbIyC2DmnA8R0VNN9Ymv8U9+uojD0uuQSxK2z0NspQZdjjthk9CgLtGTDqIsk Ji4AuAkwjCmff5aHlEY+G5GyHRuEpczLGqRIEbpLoRTFnLTrhrbshkxsYQM5pNwWTidtw9CWWEmd RX96sMvym3SdYGkhfFWlpgoF7/3nAgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBTnAiOAAE/Y17yU C9k/dDlJMjyKeTAdBgNVHQ4EFgQU9btKWvkJMHw27U3VEwvQ+VCtpqEwDAYDVR0TAQH/BAIwADAh BgNVHREEGjAYgRZwYXVsLmhvZmZtYW5AaWNhbm4ub3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwQwYDVR0gBDwwOjA4BgpghkgBhv1sBAECMCowKAYIKwYB BQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwgYgGA1UdHwSBgDB+MD2gO6A5hjdo dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEuY3JsMD2g O6A5hjdodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNzdXJlZElEQ0EtZzEu Y3JsMHkGCCsGAQUFBwEBBG0wazAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29t MEMGCCsGAQUFBzAChjdodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyQXNz dXJlZElEQ0EuY3J0MA0GCSqGSIb3DQEBCwUAA4IBAQB1Zc/uexWtNIjStm4b/HN1W5/Hcl4eE58O lh+2JgLIsgY7Ten6HoOx/4LNFKPQlnCMdyy1XqkF9FDU/7O+a98B+++tWTvk3U7EBqKGe7XLw1oq w6ymSNZ/gn4L+Bh4Ka5I3RY15+tWxfAOiHkLFHGFvU7NA2Oqsue8tD5fZD/+UNNlQ5YVDiQCgkN1 miFgb6tkX6kLnuItIU1LSFi8etVL+5MN7NyuH2Y/Ta7h3p+JsIvdAGe2F1+9RiVMkHDSRgiS05qo TpdWBJ0hnX9B/0nSs+gXeZbGkO1KXS4+KC9dt+FriAhd5fHc/9g8qtbEkh2TdSZdfse7idXAG+UB tAx3MIIGTjCCBTagAwIBAgIQBK55YGZmkBq5xX+mbFvczTANBgkqhkiG9w0BAQsFADBlMQswCQYD VQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBBc3N1cmVkIElEIFJvb3QgQ0EwHhcNMTMxMTA1MTIwMDAwWhcN MjgxMTA1MTIwMDAwWjBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYD VQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc+BEjP2q178AneRstBYeiEEMx3w7U FRtPd6Qizj6McPC+B47dJyq8AR22LArK3WlYH0HtagUf2mN4WR4iLCv4un7JNTtW8R98Qn4lsCMZ xkU41z1E+SB8YK4csFoYBL6PO/ep8JSapgxjSbZBF1NAMr1P5lB6UB8lRejxia/N/17/UPPwFxH/ vcWJ9b1iudj7jkUEhW2ZzcVITf0mqwI2Reo2119q4hqCQQrc6dn1kReOxiGtODwT5h5/ZpzVTdlG 2vbPUqd9OyTDtMFRNcab69TvfuR7A+FEvXoLN+BPy4KKDXEY5KbgiSwb87JzPMGwkp4Yfb2rfcV9 CKEswp9zAgMBAAGjggL4MIIC9DASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjA0 BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTCBgQYD VR0fBHoweDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElE Um9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEUm9vdENBLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwggGzBgNVHSAEggGq MIIBpjCCAaIGCmCGSAGG/WwAAgQwggGSMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2Vy dC5jb20vQ1BTMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUAcwBlACAAbwBmACAAdABo AGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMAdABpAHQAdQB0AGUAcwAgAGEA YwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQAaQBnAGkAQwBlAHIAdAAgAEMAUAAv AEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkAaQBuAGcAIABQAGEAcgB0AHkAIABBAGcA cgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwAaQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5 ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8AcgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4A IABiAHkAIAByAGUAZgBlAHIAZQBuAGMAZQAuMB0GA1UdDgQWBBTnAiOAAE/Y17yUC9k/dDlJMjyK eTAfBgNVHSMEGDAWgBRF66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQsFAAOCAQEATtSJ J7n9HYd3fg8oBZDxCi/JOz69k5yQxq/6kVGHMlRr6MrBcVFcmY61+uBiGZmmB5p8Eyfb5QKihBLZ FfYKRFfENI9tcx861qABPd7jguRFa7LrJf2AXh05kL5bQvbOkWDj+aBWDEgQzjNoe82Tq/Bqy09Y D7l7XRsEgZ6nIuJXSSfukpMIvmkIUwI6Ll3IGfRQgE4C2bBdkbSTh/mWloFVQI5m7YLYuyhf7Uxh 7QZYKBlTEUS8RyApsgRs2IlUmTt122d4LB6SeMZVPVgSETJuvUMMTTTbe8ZC2+y+q5thTAaS447f ISpQVwTAYKI11SSeZjcJSc/V+GWz4OJuwjGCAxkwggMVAgEBMHkwZTELMAkGA1UEBhMCVVMxFTAT BgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAB5VHP1rt28Pao9740oJwQMAkGBSsOAwIaBQCg ggF1MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MDUwNDE1Mjkx MlowIwYJKoZIhvcNAQkEMRYEFD9htEDpHXgn/geKcJ33btoh+pBmMIGIBgkrBgEEAYI3EAQxezB5 MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdp Y2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2 qPe+NKCcEDCBigYLKoZIhvcNAQkQAgsxe6B5MGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdp Q2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNI QTIgQXNzdXJlZCBJRCBDQQIQAeVRz9a7dvD2qPe+NKCcEDANBgkqhkiG9w0BAQEFAASCAQAPXnor iBQbex7euWLJcpxQmoZtLCWNDt5yyrWAvqrHYQoQxjjuCblc2xNDn5E+4OWWGg9kHlpa5K7q2wlx MwI3RD1y+m5wVoF0bvobwqZ9qW7hiRvXUROGfezt5bj6EluSDhEl2KhOHTjHWDcPmZr44KCysxGd deiVO+YLDpaqf60zse//I27+U8OE2iipJgkF+4hbwq+Sjz0GQSLO/phlKmNrioEAI17asvPrwS6M Z9mnIbq75q14ZZCYKFD908vzsp4iRqnrjmYm5krJnqntL7haZZRb3UeO8zRUKMnzfv6bs6nFC0wX OnT5z9IfRDv1nXjfPlwryprlyUuMviJJAAAAAAAA --Apple-Mail=_CFECDCC8-72C5-4752-8D68-64447C427C23-- From nobody Fri May 4 08:35: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 47A7612D86B for ; Fri, 4 May 2018 08:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AEGLiWTa4kZ for ; Fri, 4 May 2018 08:35:23 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2356512D7F1 for ; Fri, 4 May 2018 08:35:23 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id e78-v6so26144997iod.0 for ; Fri, 04 May 2018 08:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BbzE+/2qY0q1RYtyN7JiXgZvFiHxX5ENnEnTWUlfOYU=; b=iFXlhUQUW2M9J/AG0eqCoNBsyuW581kHxhgs0ArRLqzBRQv0ImklmxGuSzbnsw88er Qnt60HaYdccPKYBbObmLMpg0l6V/6vBcPdxOttmwzGItuAcExoBjxwL7PaC3esLsTt49 L4WI3gdn6lms3hgv6PVCqORDe7dA5J/qpBXnB0ElsObHX4iOPiwpo2UWL47VsLMLLfBm SmeUaRnCqtANLg1yU0+FlI7HhLLYygtF0XZhySpNDN9UpiuZim1edfhUIfYYzpsOZfoC g1JLyOOYTVtcTBcDLQ1jZ9ZdaPI9jIjKiG4OYQQ9rHEcCW02yYrQts0eYIWEz0g9F2rC bZjg== 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=BbzE+/2qY0q1RYtyN7JiXgZvFiHxX5ENnEnTWUlfOYU=; b=hGmeas5KIV+LI1Vyb7b2X6KyhfUFhD1hyVUHsVRKh6q71JkupdJBaL6WUJ6jY2px/G O+4mgvAYDRQO9SvtVv3wyAu4B6MsuSAWStx6TO//96xeckJ/Z9TDoKvMHIlEPBvkLbSx WQD8mQSG+D6stUMBMxC6fQ+OmnOSLhwrOUor36FyVtTCR8HMcz+ssWvJGROPyzMQFagv sc76VmUZcAI9z2amzAEvOPcf/jnJmekGvhON78ZkZPKiQhmQzo3Eh5mnhy5rdfV3utaM FWgeVl47u4IZiqr+OCEcAoF9NaqSuE0i6jL+2CKhLv4tKnFm4Xj/RJAselaXcsemf5/r UMqA== X-Gm-Message-State: ALQs6tDWODX9D3DAOIyrv+lHMmPowkTBn64k8gDp8PktFc2eQtujKWjL rcC44gUYwWrAouwznrAtwLjQrtf/BjvYeDfQb/jjzN38 X-Google-Smtp-Source: AB8JxZr/AgW1bYfVcNb3LCJUIgiu9T52bi0Zq/eY7Vxh1Kq0CLFWNVh4iqVdR4MvLazcYSH+LwSmknjGXWBw3GdaCIA= X-Received: by 2002:a6b:8358:: with SMTP id f85-v6mr28864673iod.3.1525448121907; Fri, 04 May 2018 08:35:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.70.12 with HTTP; Fri, 4 May 2018 08:35:21 -0700 (PDT) In-Reply-To: <8C5EE3D3-D07A-4CC2-AE6D-75E98F040736@icann.org> References: <8C5EE3D3-D07A-4CC2-AE6D-75E98F040736@icann.org> From: Ben Schwartz Date: Fri, 4 May 2018 11:35:21 -0400 Message-ID: To: Paul Hoffman Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000079bb33056b63112e" Archived-At: Subject: Re: [Doh] [Ext] New tool for using and testing DOH X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 15:35:25 -0000 --00000000000079bb33056b63112e Content-Type: multipart/alternative; boundary="0000000000006e8dfa056b6311ec" --0000000000006e8dfa056b6311ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I noted on the list in November, IETF DOH is available at https://dns.google.com/experimental. However, I intend to deactivate that path (and move to a more permanent location) once the protocol is finalized, so I would strongly discourage any clients from relying on it. On Fri, May 4, 2018 at 11:29 AM, Paul Hoffman wrote: > On May 4, 2018, at 7:21 AM, Ben Schwartz wrote: > > Intra currently uses Google=E2=80=99s pre-standard version of DOH with > dns.google.com, and uses draft-ietf-doh-dns-over-https with > cloudflare-dns.com. > > > > Let me know if you have questions or feedback about the app. > > From the Looking A Gift Horse In The Mouth Department: > > Could you please lean hard on dns.google.com to add support for > draft-ietf-doh-dns-over-https? Only offering a non-standard way to do thi= s > is surely going to cause later interop issues when developers say "I did > DOH the Google way". > > --Paul Hoffman --0000000000006e8dfa056b6311ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I noted on the list in November, IETF DOH is available = at https://dns.google.com/e= xperimental.=C2=A0 However, I intend to deactivate that path (and move = to a more permanent location) once the protocol is finalized, so I would st= rongly discourage any clients from relying on it.

On Fri, May 4, 2018 at 11:29 AM, = Paul Hoffman <paul.hoffman@icann.org> wrote:
On May 4, 2018, at 7:21 AM, Ben Sc= hwartz <bemasc@google.com> w= rote:
> Intra currently uses Google=E2=80=99s pre-standard version of DOH with= dns= .google.com, and uses draft-ietf-doh-dns-over-https with cloudflare-dns= .com.
>
> Let me know if you have questions or feedback about the app.

From the Looking A Gift Horse In The Mouth Department:

Could you please lean hard on dns.google.com to add support for draft-ietf-= doh-dns-over-https? Only offering a non-standard way to do this is surely g= oing to cause later interop issues when developers say "I did DOH the = Google way".

--Paul Hoffman

--0000000000006e8dfa056b6311ec-- --00000000000079bb33056b63112e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCr+VQE5cRTdnVcPGxt/sxk m4eyDf1SU///lMvJR+yU7jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MDQxNTM1MjJaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEACFDLVqnYvkLyT03EP9z04D2WO35MoxfgpUr2pPIy lCNuo/O2HUXGnaPLXUr+eSIJn4hXmX0p7+Rud1LthLIbNNNWjykFlMQ9DC0TWXm5hJeQWUDfDV4n WW1X42rAM5SrjhDpHMGrB+A01aCsavaTyKLKn/ExXwUhG4+42gMZ1elhYx1k4Nex3CpSeibPrxg8 lImKgAVyMLc1tlmSn9iBcBh524unNjmgvuBlIzgtKWyClEoqY1ll+nwlwg3mT/DHkvzQ2HIHC7RI ibp4cQbOl9AwNxdvRyyoRQrs4J1v/s3u3+NzBng4tfKS41IlaPEsVBhUbr2j9l2/DcMBNHWi6g== --00000000000079bb33056b63112e-- From nobody Fri May 4 08:42: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 69563127136 for ; Fri, 4 May 2018 08:42:15 -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 WKZqP3tnrE-W for ; Fri, 4 May 2018 08:42:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 0824512D872 for ; Fri, 4 May 2018 08:42:13 -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.1178.4; Fri, 4 May 2018 08:42:08 -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.1178.000; Fri, 4 May 2018 08:42:08 -0700 From: Paul Hoffman To: Alexander Mayrhofer CC: Sara Dickinson , DoH WG Thread-Topic: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https Thread-Index: AQHT45667P1vxvsH+EeLZtDuOPL5QaQgKwWA Date: Fri, 4 May 2018 15:42:07 +0000 Message-ID: <09B39ED1-52A7-4579-8A7C-5679A0D3CE16@icann.org> References: <9452C542-6F2F-4167-AE71-7A48C8C8055C@icann.org> <2A0E3E8D-2D0C-4164-9EAC-6535686725DB@sinodun.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="utf-8" Content-ID: <9095F9EDB02ACF428AE485C04786E960@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 15:42:15 -0000 T24gTWF5IDQsIDIwMTgsIGF0IDQ6NTQgQU0sIEFsZXhhbmRlciBNYXlyaG9mZXIgPGFsZXgubWF5 cmhvZmVyLmlldGZAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxvLA0KPiANCj4gW2NvbW1l bnRzIGlubGluZSBvbiBQYWRkaW5nXQ0KPiANCj4gT24gV2VkLCBNYXkgMiwgMjAxOCBhdCAxOjQy IFBNLCBTYXJhIERpY2tpbnNvbiA8c2FyYUBzaW5vZHVuLmNvbT4gd3JvdGU6DQo+Pj4gSSdtIG5v dCBzdXJlIHdoeSB0aGVyZSBhcmUgInByb2JsZW1zIiB3aXRoIHRoZXNlLiBGb3IgcGFkZGluZywg dGhlIHNlcnZlciBjYW4gdXNlIGl0IG9yIG5vdC4NCj4+IA0KPj4gRm9yIG1lIHRoZSBpc3N1ZSBp cyBzaW1wbHkgdGhhdCBIVFRQIHBhZGRpbmcgaXMgc3BlY2lmaWNhbGx5IG1lbnRpb25lZCBpbiB0 aGUgZHJhZnQgKHNldmVyYWwgdGltZXMpIGJ1dCB0aGF0IEVETlMoMCkgaXNu4oCZdCBtZW50aW9u ZWQgYXQgYWxsLiBBIHNpbXBsZSBzdGF0ZW1lbnQgaW4gU2VjdGlvbiA2IHRvIHRoZSBlZmZlY3Qg dGhhdCDigJhETlMgQVBJIGNsaWVudHMgYW5kIHNlcnZlcnMgbWF5IHVzZSBFRE5TKDApIHBhZGRp bmcgW1JGQzc4MzBdIGluIHRoZSBETlMgd2lyZSBmb3JtYXQgaW5kZXBlbmRlbnRseSBvZiB3aGV0 aGVyIG9yIG5vdCBIVFRQIHBhZGRpbmcgaXMgdXNlZC7igJkgd291bGQgc3VmZmljZSBJIHRoaW5r Lg0KPiANCj4gSSBkbyBhZ3JlZSB3aXRoIFNhcmEgb24gdGhpcy4gSXQgc2VlbXMgaW5jb21wbGV0 ZSB0byBtZW50aW9uIEhUVFANCj4gcGFkZGluZyBhIGZldyB0aW1lcywgYnV0IG5vdCBtZW50aW9u IEROUyBwYWRkaW5nIGF0IGFsbCwgZ2l2ZW4gdGhhdA0KPiB0aGUgcHJvdG9jb2wgaXMgYSAibWl4 dHVyZSIgb2YgYm90aCB3b3JsZHMuDQo+IA0KPiBBbmQgcmVtZW1iZXJpbmcgYSBmZXcgZGlzY3Vz c2lvbnMgaSBoYWQgd2l0aCBmZWxsb3cgZW5jcnlwdGlvbiBndXJ1cywNCj4gaXQgc2VlbXMgcHJl ZmVycmFibGUgdG8gcGVyZm9ybSBwYWRkaW5nIGF0IHRoZSAiaW5uZXJtb3N0IiBsZXZlbCwNCj4g d2hlcmUgdGhlIGFwcGxpY2F0aW9uIGhhcyB0aGUgZ3JlYXRlc3QgZXh0ZW50IG9mIGNvbnRyb2wg b3ZlciB3aGV0aGVyDQo+IG9yIG5vdCBwYWRkaW5nIGhhcyBiZWVuIHBlcmZvcm1lZCwgYW5kIHRv IHdoYXQgZXh0ZW50LiBMb29raW5nIGF0IHRoZQ0KPiBsYXllcmluZyBvZiBET0gsIHRoYXQgcHJv YmFibHkgbWVhbnMgdGhhdCBFRE5TIHBhZGRpbmcgZ2l2ZXMgYW4gYXBwDQo+IG1vcmUgY29udHJv bCB0aGFuIEhUVFAgcGFkZGluZywgYW5kIEhUVFAgcGFkZGluZyBnaXZlcyBhbiBhcHBsaWNhdGlv bg0KPiBtb3JlIGNvbnRyb2wgdGhhbiBwYWRkaW5nIG9uIHRoZSBUTFMgbGF5ZXIuDQo+IA0KPiBU aGVyZWZvcmUsIGkgZG8gc3VnZ2VzdCB0aGF0IHdlIGRvIG1lbnRpb24gRUROUyBwYWRkaW5nIGFz IGF0IGxlYXN0IGFuDQo+IGVxdWFsIGNob2ljZSB0byBIVFRQIHBhZGRpbmcuICBJIGNhbiBwcmVw YXJlIHRleHQgKG9yIGEgcHVsbCByZXF1ZXN0DQo+IGlmIHRoYXQgaXMgcHJlZmVycmVkKS4NCg0K SSBoYXZlIGNyZWF0ZWQgUHVsbCBSZXF1ZXN0ICMxNzMgdG8gYWRkIHRoaXMuDQoNCi0tUGF1bCBI b2ZmbWFu From nobody Fri May 4 10:03: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 483DD1242EA for ; Fri, 4 May 2018 10:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0SmH373fb15 for ; Fri, 4 May 2018 10:03:54 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4771200F1 for ; Fri, 4 May 2018 10:03:54 -0700 (PDT) Received: from [2001:b98:204:102:fffa::] (port=61666) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fEe7a-0007wf-Ej for doh@ietf.org; Fri, 04 May 2018 18:03:52 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_24F38A31-D068-47DA-8197-306A126C824A" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Fri, 4 May 2018 18:03:48 +0100 References: To: DoH WG In-Reply-To: Message-Id: <2AE1447E-98A1-41CA-91B7-3019711D3E8E@sinodun.com> X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 17:03:56 -0000 --Apple-Mail=_24F38A31-D068-47DA-8197-306A126C824A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All,=20 The text in the latest GitHub version of the draft now uses phrases like = "a client MUST specifically authorize DNS API servers=E2=80=9D.=20 I=E2=80=99m not clear if there is any difference between = =E2=80=98authorizing=E2=80=99 a server and just using a server? If there = is some subtlety here then I=E2=80=99d like to understand if but if not = I created = https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 = to = simplify the text and also put the discussion of selection of server in = its own section.=20 Sara.=20 > On 30 Apr 2018, at 18:59, Sara Dickinson wrote: >=20 >=20 > 4) Section 8: With regard to trusted/untrusted servers I would suggest = at least a small restructure for clarity. At the moment the first = discussion of the client trust model is in section 5.3 =E2=80=98Server = Push=E2=80=99. >=20 > I would suggest adding a section before this (possibly after section = 3) called something like =E2=80=99Trust model for client queries=E2=80=99 = with the following (combining text from section 5.3 and 8): --Apple-Mail=_24F38A31-D068-47DA-8197-306A126C824A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = All, 

The text = in the latest GitHub version of the draft now uses phrases like "a = client MUST specifically authorize DNS API = servers=E2=80=9D. 

I=E2=80=99m not clear if there is any difference between = =E2=80=98authorizing=E2=80=99 a server and just using a server? If there = is some subtlety here then I=E2=80=99d like to understand if but if not = I created https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174=  to simplify the text and also put the discussion of selection = of server in its own section. 

Sara. 

On 30 = Apr 2018, at 18:59, Sara Dickinson <sara@sinodun.com> wrote:


4) = Section 8: With regard to trusted/untrusted servers I would suggest at = least a small restructure for clarity. At the moment the first = discussion of the client trust model is in section 5.3 =E2=80=98Server = Push=E2=80=99.

I= would suggest adding a section before this (possibly after section 3) = called something like =E2=80=99Trust model for client queries=E2=80=99 = with the following (combining text from section 5.3 and = 8):

= --Apple-Mail=_24F38A31-D068-47DA-8197-306A126C824A-- From nobody Sat May 5 09:17: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 93B6212E8CB for ; Sat, 5 May 2018 09:17:39 -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, FREEMAIL_FROM=0.001, 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 eeeBP_NL6Ovy for ; Sat, 5 May 2018 09:17:37 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 BCADA126CBF for ; Sat, 5 May 2018 09:17:35 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 15289 invoked from network); 5 May 2018 18:17:31 +0200 Received: from acld108.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.105.108]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 5 May 2018 18:17:31 +0200 To: DoH WG Cc: sara@sinodun.com From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <56fb94bd-ec0f-81c8-16c8-8391ef1a5f46@o2.pl> Date: Sat, 5 May 2018 18:17:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ht3w9qWgRnQLPS7qwXl40HldEUqamBZGJ" X-WP-MailID: 714d67049daa133fe35d6324db250d11 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [gSMU] Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 16:17:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ht3w9qWgRnQLPS7qwXl40HldEUqamBZGJ Content-Type: multipart/mixed; boundary="mZ1DISDpaK0IhetcWoxiMimScUj1y9vlz"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Cc: sara@sinodun.com Message-ID: <56fb94bd-ec0f-81c8-16c8-8391ef1a5f46@o2.pl> Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https --mZ1DISDpaK0IhetcWoxiMimScUj1y9vlz Content-Type: multipart/mixed; boundary="------------76E0840D674B6D0B54153BC3" Content-Language: pl This is a multi-part message in MIME format. --------------76E0840D674B6D0B54153BC3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sara Dickinson on Fri, 04 May 2018 17:03 UTC wrote: > The text in the latest GitHub version of the draft now uses phrases lik= e "a > client MUST specifically authorize DNS API servers=E2=80=9D. > > I=E2=80=99m not clear if there is any difference between =E2=80=98autho= rizing=E2=80=99 a server and > just using a server? If there is some subtlety here then I=E2=80=99d li= ke to > understand if but if not I created > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 to simp= lify > the text and also put the discussion of selection of server in its own > section. This text is unclear also to me. I cannot really understand what is meant= by the following sentence: For HTTP requests initiated by the DNS API client this authorization is implicit in the selection of URI. Should I read it so: "by selecting a DNS API server URI the client is imp= licitly authorizing the server", whatever this means in practice? On the other hand, the wording proposed by Sara Dickinson looks too verbo= se to me and is unclear also. In the following sentence: Before using a DNS API server for DNS resolution, the client MUST establish that the HTTP request URI is a trusted service for the DOH query, [...] what should the phrase "is a trusted service for the DOH query" mean? Is it possible that for some DOH queries the request URI is trusted and f= or some others isn't? I would propose simply the following text for the "# Security" section: When DNSSEC is not used, a DNS API server can give the client invalid data as a response to a DNS query. Therefore, a DNS API client SHOULD carefully determine which DNS API server(s) it trusts. For example, a DNS API client can have trusted DNS API server(s) preconfigured. I suppose that most computer users won't know what a DNS is and won't con= figure a DNS API server themselves. Therefore "explicit configuration" in practi= ce means "preconfigured DNS API server(s)". Greetings, Mateusz Jo=C5=84czyk --------------76E0840D674B6D0B54153BC3 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------76E0840D674B6D0B54153BC3-- --mZ1DISDpaK0IhetcWoxiMimScUj1y9vlz-- --Ht3w9qWgRnQLPS7qwXl40HldEUqamBZGJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa7dkaAAoJEPvWWrhhCv7GPXcP/io5/M6EscVMhqoqgiDE/x8r J2fXJZ87UqDD7pGVDO0shNHcKrR8aDUHFVZh2eO5d63v4ScR/02h+w67Eu4RxnwX GktCN3lU19UAibJ9SA9NWqzwqHXspxKUT6xOCZgsALSX8yfEzqf7Tbad3GKnhv8h 15VlOeOBZG6Vj6oR6He2q5roM5B923o3s20sZ99gYNgUjmg3rGqpP/S9PMqOtsMJ ZMpz3JijrhfuD0oGvuNAip3mYktN7wHqocG7mwHaMlnq+gSk+GdigM57/98ynGQl Zy0QyqyVor/LZo2FY9DJi1oAa+GeWskaiN2oWMPAmRhnRRR/3WgfgEHb3lI8BKsW sXAvLETVHE/bBDbskQw0e2Uu1ZBlk/ifxVdvmo59Pg4P4jzeQiQr2mMat9qwJn1h MN1HcX6208/NPOhABMVgQVTK/r4fCnZFj6IMYclKM4RMP132oSYELsTU9u6KU6Mj JLtGVb8k9dEaoWtn1Cvpo0CHF2OwBsjs3isgVva24OSrzXhmbeShhJkIlMtbB08O DALepqLw6U6PyaTL6tkq+F79Vni27mJlwTWgC84b7Roxopdi7G3WaFJovg+rwwHV y6WQuafuf8JKBXAil6Xm27PbGM1/23jW/211AFlmtF0pWN68wXdyW1uam1zmoZV2 nds1NUknyxfgCRXecjvN =+UGH -----END PGP SIGNATURE----- --Ht3w9qWgRnQLPS7qwXl40HldEUqamBZGJ-- From nobody Mon May 7 02:11: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 4AD6D126B6D for ; Mon, 7 May 2018 02:11:31 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wv_nkY04jDL for ; Mon, 7 May 2018 02:11:28 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 BCFE8124BE8 for ; Mon, 7 May 2018 02:11:27 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 11333 invoked from network); 7 May 2018 11:11:24 +0200 Received: from acle104.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.106.104]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 7 May 2018 11:11:24 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG References: <56fb94bd-ec0f-81c8-16c8-8391ef1a5f46@o2.pl> Openpgp: preference=signencrypt Message-ID: <02d1ab18-a10d-0aaa-ceed-32ef9e6403e6@o2.pl> Date: Mon, 7 May 2018 11:11:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <56fb94bd-ec0f-81c8-16c8-8391ef1a5f46@o2.pl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7jQ9vTJDPBA2UczRQWivKRncsclaqj59C" X-WP-MailID: 4222b65be1e834cc8aa204b20e2f4c48 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [sYNk] Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 09:11:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7jQ9vTJDPBA2UczRQWivKRncsclaqj59C Content-Type: multipart/mixed; boundary="qlQVrpMwhfp17SADUMuUvLAPL0yH3s0wY"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: <02d1ab18-a10d-0aaa-ceed-32ef9e6403e6@o2.pl> Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https References: <56fb94bd-ec0f-81c8-16c8-8391ef1a5f46@o2.pl> In-Reply-To: <56fb94bd-ec0f-81c8-16c8-8391ef1a5f46@o2.pl> --qlQVrpMwhfp17SADUMuUvLAPL0yH3s0wY Content-Type: multipart/mixed; boundary="------------51AD9B5FB4E12ED3879359AB" Content-Language: pl This is a multi-part message in MIME format. --------------51AD9B5FB4E12ED3879359AB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 05.05.2018 o=C2=A018:17, Mateusz Jo=C5=84czyk pisze: > what should the phrase "is a trusted service for the DOH query" mean? > Is it possible that for some DOH queries the request URI is trusted and= for some > others isn't? >=20 >=20 > I would propose simply the following text for the "# Security" section:= > When DNSSEC is not used, a DNS API server can give the client invalid > data as a response to a DNS query. Therefore, a DNS API client SHOULD > carefully determine which DNS API server(s) it trusts. For example, a > DNS API client can have trusted DNS API server(s) preconfigured. >=20 > I suppose that most computer users won't know what a DNS is and won't c= onfigure > a DNS API server themselves. Therefore "explicit configuration" in prac= tice > means "preconfigured DNS API server(s)". >=20 I have received no response, so I have sent a corresponding pull request:= https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/175 Greetings, Mateusz Jo=C5=84czyk --------------51AD9B5FB4E12ED3879359AB Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------51AD9B5FB4E12ED3879359AB-- --qlQVrpMwhfp17SADUMuUvLAPL0yH3s0wY-- --7jQ9vTJDPBA2UczRQWivKRncsclaqj59C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa8Bg7AAoJEPvWWrhhCv7GYtUP/0u5012YO2JuciKZrnBFlG9z NlJqSI0149FP5x29RV/nOhvGo9oiTypZpv2uQNZ8coMqT9jbciig2VziKtMURxbp iWxpCYtACtQ4MMHXo0cC27dWaUHIe2bF+q7NQlM4dvVKRFM7npH76WapjqWz4wpY //vEdZAYY7pygMQriThycjDCkvj6/7aWuAn2YRpj2xiZ+aNplUg2ScUAXyW/RQTN FfLmBURsCIwbFvImwU8e8yuqEBa21humaz+ob5i+HMWW4A0PUOAgWYpV2/9J8fI/ agQ3MS85gY6YDIuHSQ1HZn9mQ4qt/kkXy36DpLvtU+RXMAZiIu6eFDK11qrRyOXj D2V8tbIQ8xvy0w1AMVEriCWFV99wLbc3RVudZQVQ9bV0HNVxCf9UqqW2KN9KtTOM AQ7jyA7NjeHg2hgsRuR3FNBn5UMwOTaFO+7UoAMmtj7UX9RG+WatU7rKsxy9I0/X r5sfdH4z9JbacU907NAxN/P61lfVAuVrF0quBbTxrNFSfPW9SEYp/lzdiiBHk2c3 VTjpjXCPhnGzCg14ksCZM0GXxjuPRYVVe9Eh84w0yabrvwuRemMhIu1iQ3v+LvCP oqpmDeRFBrRWiZop2T0qOXMUWFcqmmxuJttgwqou9C6pSVGZfKZd9bT//dDhOn+n eFo0EnEJW9sABGlI11nw =GUfp -----END PGP SIGNATURE----- --7jQ9vTJDPBA2UczRQWivKRncsclaqj59C-- From nobody Mon May 7 04:47: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 11F3A124217 for ; Mon, 7 May 2018 04:47:52 -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 Pajw0FTM1dNo for ; Mon, 7 May 2018 04:47:50 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id DEE88120725 for ; Mon, 7 May 2018 04:47:49 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 9300B3A024 for ; Mon, 7 May 2018 07:47:47 -0400 (EDT) Received: by mail-ot0-f176.google.com with SMTP id t1-v6so31577472ott.13 for ; Mon, 07 May 2018 04:47:47 -0700 (PDT) X-Gm-Message-State: ALQs6tDb6z0XU3ica/jIvt9/VuiVG8MLMzWeR21NogoOlmN5Gcw51EUK eBzNPCrbyzgEv9b0GbR0xKFXUMdRdMP7L7FAEyQ= X-Google-Smtp-Source: AB8JxZo8AgL1V2fIqbcJeWceB4pB7UctdG1WrAXxjnLy08+F0qnLsOMVqVFwIvON5ffHT37dNbHf//HLdT5BRwvSeaE= X-Received: by 2002:a9d:2c64:: with SMTP id f91-v6mr24765060otb.263.1525693667277; Mon, 07 May 2018 04:47:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.36 with HTTP; Mon, 7 May 2018 04:47:46 -0700 (PDT) In-Reply-To: <2AE1447E-98A1-41CA-91B7-3019711D3E8E@sinodun.com> References: <2AE1447E-98A1-41CA-91B7-3019711D3E8E@sinodun.com> From: Patrick McManus Date: Mon, 7 May 2018 07:47:46 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000001300b3056b9c3da1" Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 11:47:52 -0000 --0000000000001300b3056b9c3da1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for this suggestion. I like it. On Fri, May 4, 2018 at 1:03 PM, Sara Dickinson wrote: > Hi All, > > The text in the latest GitHub version of the draft now uses phrases like > "a client MUST specifically authorize DNS API servers=E2=80=9D. > > I=E2=80=99m not clear if there is any difference between =E2=80=98authori= zing=E2=80=99 a server > and just using a server? If there is some subtlety here then I=E2=80=99d = like to > understand if but if not I created https://github.com/ > dohwg/draft-ietf-doh-dns-over-https/pull/174 to simplify the text and > also put the discussion of selection of server in its own section. > > Sara. > > On 30 Apr 2018, at 18:59, Sara Dickinson wrote: > > > 4) Section 8: With regard to trusted/untrusted servers I would suggest at > least a small restructure for clarity. At the moment the first discussion > of the client trust model is in section 5.3 =E2=80=98Server Push=E2=80=99= . > > I would suggest adding a section before this (possibly after section 3) > called something like =E2=80=99Trust model for client queries=E2=80=99 wi= th the following > (combining text from section 5.3 and 8): > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --0000000000001300b3056b9c3da1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this suggestion. I like it.

On Fri, May 4, 2018 at 1:03= PM, Sara Dickinson <sara@sinodun.com> wrote:
Hi All,=C2=A0

The text in the latest GitHub ver= sion of the draft now uses phrases like "a client MUST=C2=A0specifical= ly=C2=A0authorize=C2=A0DNS=C2=A0API servers=E2=80=9D.=C2=A0
=
I=E2=80=99m not clear if there is any difference between =E2= =80=98authorizing=E2=80=99 a server and just using a server? If there is so= me subtlety here then I=E2=80=99d like to understand if but if not I create= d=C2=A0https://github.com/dohwg/draft-ietf-doh-dns-= over-https/pull/174=C2=A0to simplify the text and also put the dis= cussion of selection of server in its own section.=C2=A0

Sara.=C2=A0

On 30 Apr 2018, at 18:= 59, Sara Dickinson <sara@sinodun.com> wrote:


4) Section 8: With regard to trusted/untruste= d servers I would suggest at least a small restructure for clarity. At the = moment the first discussion of the client trust model is in section 5.3 =E2= =80=98Server Push=E2=80=99.

I would suggest adding= a section before this (possibly after section 3) called something like =E2= =80=99Trust model for client queries=E2=80=99 with the following (combining= text from section 5.3 and 8):


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


--0000000000001300b3056b9c3da1-- From nobody Mon May 7 17:11: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 10D8812D7F7 for ; Mon, 7 May 2018 17:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=QXhctSnr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E+55XHmh 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 Hl4sf2c3MnRV for ; Mon, 7 May 2018 17:10:59 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4A712708C for ; Mon, 7 May 2018 17:10:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A99BD224DE; Mon, 7 May 2018 20:10:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 07 May 2018 20:10:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=OSOv4ZivPsiluGRAvc4/rKQcL6zep 7uU+ZxJBJMVpf4=; b=QXhctSnr1Fdi/aDfBKAomI5T1UFJw9C/gTBuKk4r7pLOw uSR+PhqoylAaT6cwNFdhtCkML5URChA55+7oqy+kkIlijW8OS2An6TzasiDQEmHI IXwPcvj3Nul0BAjk+LfkFfEa7DiCTsD1fcLR+SlLsAteSE9m1fD3ZY6d1vDYC29F 1m8CgMBrdS0KstC6k8h4kh/T/KhDokZ4ihz7c465WSDC4D7/P0Sor8gWeIrcyA02 B/ye5g6VAYWMmYgTm0BTLxoT9/VixJzqZd7q1T4lNdyOm98eRt96qskO0x0pwREt u/27fknQ7cyzKhWIyzVxGd/dti34vnCk3mybDxWcA== 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=fm2; bh=OSOv4Z ivPsiluGRAvc4/rKQcL6zep7uU+ZxJBJMVpf4=; b=E+55XHmhSvvg/MO/CqL0Z3 8X9dwRfYpR6L2rp0OZ0oQbB6spcz2WiF05srS7X3bJG04k6mvGltIRMliaFZHvPQ qEvqpLJ0uHnDEYZ256DMcZxPOB6f4/Ii63gQPfDhIVQAMxqsfAGhfbx0d4u2Jbe7 wzAmc6oMamxYFRG3zH3hKFk9M7qROLPD+GZSX9aJOTZbo5kI7F1hyfq/DF5CrZOW zUbZAjp4jinvTzerx8RFgh9Zu+QaecGUnXCZJh0rjDxP1M+R2/SUUYmpetqfvbcz 6w8Ymlz7+vKtqf/+Ua30WrWV9pPFcLiexGf1bFocL2ZldHgeGaDoh/aYIWKocDZA == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0E7A6E491A; Mon, 7 May 2018 20:10:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> Date: Tue, 8 May 2018 10:10:53 +1000 Cc: DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 00:11:02 -0000 On 3 May 2018, at 8:23 am, Paul Hoffman wrote: >=20 > I'm going to re-up this here on the list. Please see the discussion on > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 >=20 > It would be handy if people who disagree with each other offer text = *on the list*, not pull requests, specifying what they want the text in = the draft to say. Then, people to try to come to consensus on this. = (Yes, some people are more comfortable with editing pull requests; I = feel that this issue is too important to not have the discussion here on = the list.) Proposal: Cache Interaction {#caching} A DNS API request can pass through a hierarchy of caches that include = both HTTP and DNS specific caches. HTTP caches are by design generic; = that is, they do not understand this protocol. Even if a DNS API client = has modified its cache implementation to be aware of DOH semantics, it = does not follow that all upstream caches (for example, in proxies, = server-side gateways and Content Delivery Networks) will be. As a result, DNS API servers need to carefully consider the HTTP caching = metadata they send in response to GET requests (POST requests are not = cacheable unless specific response headers are sent; this is not widely = implemented, and not advised for DOH).=20 In particular, they are encouraged to assign an explicit freshness = lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign = heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby = taking control out of the hands of the DNS API server. Typically, the assigned freshness lifetime of a given DOH HTTP response = will use the smallest TTL in the Answer section of the DNS response as a = maximum. For example, if a HTTP response carries three RRsets with TTLs = of 30, 600 and 300, the HTTP freshness lifetime usually ought to be no = more than 30 seconds (e.g., "Cache-Control: max-age=3D30"), so that the = RRset with the smallest TTL is not stale when retrieved from cache. This assures that none of the RRsets contained within are served stale = from an HTTP cache. If the DNS response has no records in the Answer section, and the DNS = response has an SOA record in the Authority section, the response = freshness lifetime typically ought not be greater than the MINIMUM field = from that SOA record (see {{RFC2308}}). 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. DNS API servers also need to consider caching when generating responses = that are not globally valid. For instance, if a DNS API server = customizes a response based on the client's identity, it would not want = to allow global reuse of that response. This could be accomplished = through a variety of HTTP techniques such as a Cache-Control max-age of = 0, or by using the Vary response header ({{RFC7231}}, Section 7.1.4) to = establish a secondary cache key ({{RFC7234}}, Section 4.1). DNS API clients MUST account for the Age response header's value = ({{RFC7234}}) when calculating the DNS TTL of a response. For example, = if a RRset is received with a DNS TTL of 600, but the Age header = indicates that the response has been cached for 250 seconds, the = remaining lifetime of the RRset is 350 seconds.=20 DNS API clients that encounter stale responses (either because the HTTP = freshness lifetime has passed, or because one or more RRset's lifetime = has passed) can request a fresh copy by using the "no-cache" request = cache control directive ({{RFC7234}}, Section 5.2.1.4) and similar = controls. Note that some caches might not honour these directives, = depending upon their configuration. HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, = as revalidation provides only a bandwidth benefit and DNS transactions = are normally latency bound. Furthermore, the HTTP response headers that = enable revalidation (such as "Last-Modified" and "Etag") are often = fairly large when compared to the overall DNS response size, and have a = variable nature that creates constant pressure on the HTTP/2 compression = dictionary {{RFC7541}}. Other types of DNS data, such as zone transfers, = may be larger and benefit more from revalidation. -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 8 02:45: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 AA72A12D7E8 for ; Tue, 8 May 2018 02:45:51 -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, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=miek-nl.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 CEI7CJ8aREuy for ; Tue, 8 May 2018 02:45:49 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D75120227 for ; Tue, 8 May 2018 02:45:49 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y15-v6so19877980wrg.11 for ; Tue, 08 May 2018 02:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=miek-nl.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=H7Q8zxm8ltb8OcwEqQwYRDH0XeBAPi5POkFPGqtxEtk=; b=vOvB+CwF5JSDWOq6UacbvHhuor7qFPdSr7v32pwmMqhqpLJNx9JHFrfRWkBBWPavKH IRxvRusjq+cM3jBzt52M63yrgL5vPbY9wzG5w5DtlN4CdxNu3kpiLEAuA5dxhLGWFYPs IWjQ1SsJ4QdG9P5xxS0Wn44s4OKq4sh4Kokh6FFhN0Ws1fvE1sxFmK1i+5Ccx42Aylbs P3moewiC68zNGxTsy0xOd4BsDu+usrl3ZtO2YTilrtLOGfPr2sjXfKrQL/QlL6Am1VZF U3ZCcMI7I+3DHAEddYo9LTOpcbL6+1NCMoE/SQlsiIToYjr90vsuyyvgteA++z6Z7hFv PlJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=H7Q8zxm8ltb8OcwEqQwYRDH0XeBAPi5POkFPGqtxEtk=; b=C+xiL6CxEFjZAMRRKgoFUjvqhda/4VjBTCzAkWwd4MGKtk/amRUeScZJxV6nK1+Gqm yfYesHvXlr6NojmucF/R0OLx+ryvlpPr5pqLeBA3LqmQzP2O3RyxhRts+fGybXwVLMtC jIe2KZb2gkDc+yBTM+udW1N5jpjY2q5oiCWmQ5Pjt+o2f5Nf0fU+dneDeyWwp2NTyfnU uQfM9FcLwzcygHL0Jrn5VTGXHYDL8v39YZKnrR2jlSRo0ub6qjkX00GtcOUsyUG57EQW M89/+n11aevo3vCk+jHND8d4ln+Vsc7xTreWR26cy2JdhjPpGd64ik+1f9eoG93wZR0h V2MA== X-Gm-Message-State: ALQs6tBOCYl/utH7eo9YXRBnZaPrHkAdnZwtaQ8xh6asBb303YAVyPXV e8bVSjT4DDpYA/WEc+Zcu1imAtxg2D4= X-Google-Smtp-Source: AB8JxZqs0rvnUe0Q6deLBLf95wtWD6moUPTCo9shSGgNIIO2VMHJO5AW0mLy1i229gTp2fYsxVryKw== X-Received: by 2002:adf:9306:: with SMTP id 6-v6mr27030615wro.175.1525772747582; Tue, 08 May 2018 02:45:47 -0700 (PDT) Received: from miek.nl ([2a01:7e00::f03c:91ff:fe79:234c]) by smtp.gmail.com with ESMTPSA id b57-v6sm39027953wra.9.2018.05.08.02.45.46 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 May 2018 02:45:46 -0700 (PDT) Date: Tue, 8 May 2018 09:45:45 +0000 From: Miek Gieben To: Mark Nottingham Cc: Paul Hoffman , DoH WG Message-ID: <20180508094545.itl6cvpsekzrpxs4@miek.nl> Mail-Followup-To: Mark Nottingham , Paul Hoffman , DoH WG References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> User-Agent: Vim/Mutt/Linux X-Home: http://www.miek.nl Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 09:45:52 -0000 [ Quoting in "Re: [Doh] [Ext] Does the HTTP fresh..." ] >Proposal: > >Cache Interaction {#caching} I like this text, but is the working-group OK with *not* mentioning DNSSEC? If you only look a the TTL and not the inception and expiry dates of RRSIGs you can easily serve BAD data. /Miek -- Miek Gieben From nobody Tue May 8 04:36: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 7C0E912DA21 for ; Tue, 8 May 2018 04:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAPkL8mw5TrN for ; Tue, 8 May 2018 04:36:02 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 6CB0612D94F for ; Tue, 8 May 2018 04:36:02 -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]:36294) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fG0uT-000Cug-kf (Exim 4.89_2) (return-path ); Tue, 08 May 2018 12:35:57 +0100 Date: Tue, 8 May 2018 12:35:57 +0100 From: Tony Finch To: Mark Nottingham , Miek Gieben cc: Paul Hoffman , DoH WG In-Reply-To: <20180508094545.itl6cvpsekzrpxs4@miek.nl> Message-ID: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <20180508094545.itl6cvpsekzrpxs4@miek.nl> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 11:36:04 -0000 Miek Gieben wrote: > [ Quoting in "Re: [Doh] [Ext] Does the HTTP fresh..." ] > > > > Cache Interaction {#caching} > > I like this text, but is the working-group OK with *not* mentioning DNSSEC? > > If you only look a the TTL and not the inception and expiry dates of RRSIGs > you can easily serve BAD data. Mark's suggestion is pretty comprehensive in other areas, so I think it ought to mention RRSIG expiry dates. (The upstream DNS server should have fixed up the TTLs, but if you're going through the DNS packet to work out an expiry time you might as well do it properly.) The other possible addition is a reference to draft-ietf-dnsop-serve-stale alongside the HTTP staleness considerations. But serve-stale is still a draft and you probably don't want to make DoH wait for it. Tony. -- f.anthony.n.finch http://dotat.at/ Biscay: Northwesterly 4 or 5, occasionally 6 at first in northeast, becoming variable 4 later. Moderate, becoming rough in west. Occasional drizzle. Moderate or good, occasionally poor. From nobody Tue May 8 04:37: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 7502D12DA14 for ; Tue, 8 May 2018 04:37: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 O7kpt32VZKq1 for ; Tue, 8 May 2018 04:37:41 -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 D713A12DA02 for ; Tue, 8 May 2018 04:37:40 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id CB8EC3A026 for ; Tue, 8 May 2018 07:37:39 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id c203-v6so28020725oib.7 for ; Tue, 08 May 2018 04:37:39 -0700 (PDT) X-Gm-Message-State: ALQs6tCVu/sjmnm43H9RAtrhXWFXycAXu7ESceRugBcRfkxU6XLZ+PXZ TCGX4KLN30L8RUxxXxuurecfPAhWpOmJhCKcZxM= X-Google-Smtp-Source: AB8JxZrc/7SLdHNWMJCGsnWrqO1Za620YFoX08IBS+wkrvsUmndSJ3YmAtc1TKjCc/DXEWbREfJONF8Fhyr4+ALkOGI= X-Received: by 2002:aca:eb0b:: with SMTP id j11-v6mr24496340oih.347.1525779459482; Tue, 08 May 2018 04:37:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.36 with HTTP; Tue, 8 May 2018 04:37:38 -0700 (PDT) In-Reply-To: <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> From: Patrick McManus Date: Tue, 8 May 2018 13:37:38 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Mark Nottingham Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="000000000000b02c94056bb036bb" Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 11:37:44 -0000 --000000000000b02c94056bb036bb Content-Type: text/plain; charset="UTF-8" Thanks Mark, This text reads more fluidly, and that is nice. OTOH it doesn't do much to resolve the core tension in https://github.com/dohwg/ draft-ietf-doh-dns-over-https/issues/153. The current ID uses normative language for creating http freshness lifetimes from DNS sets. Comments from you and Martin (and this text suggestion) support changing this from normative language to advice. The other comments favor the more deterministic behavior we currently have. Can you help me understand the argument you are making? Martin primarily suggests having the DNS code check the TTL before use rather than relying on the cache to serve fresh responses - but I think that particular point has met significant pushback largely from the DNS experts in the community. fwiw I think I agree with the existing normative requirement - a response ought to be valid at the time of receipt and it is very helpful to harmonize the concepts of DNS and HTTP valid. This doesn't preclude fancy stuff like stale-if-error or insane client max-age headers if a client is motivated. The existing draft seems to have caused a little bit of confusion by saying SHOULD match rather than MUST match.. The intent for that was to allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if you cannot figure out the DNS lifetime from your HTTP server code). The subsequent sentence enforced the >= property. Is there another aspect to the question I'm missing? On Tue, May 8, 2018 at 2:10 AM, Mark Nottingham wrote: > On 3 May 2018, at 8:23 am, Paul Hoffman wrote: > > > > I'm going to re-up this here on the list. Please see the discussion on > > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 > > > > It would be handy if people who disagree with each other offer text *on > the list*, not pull requests, specifying what they want the text in the > draft to say. Then, people to try to come to consensus on this. (Yes, some > people are more comfortable with editing pull requests; I feel that this > issue is too important to not have the discussion here on the list.) > > Proposal: > > Cache Interaction {#caching} > > A DNS API request can pass through a hierarchy of caches that include both > HTTP and DNS specific caches. HTTP caches are by design generic; that is, > they do not understand this protocol. Even if a DNS API client has modified > its cache implementation to be aware of DOH semantics, it does not follow > that all upstream caches (for example, in proxies, server-side gateways and > Content Delivery Networks) will be. > > As a result, DNS API servers need to carefully consider the HTTP caching > metadata they send in response to GET requests (POST requests are not > cacheable unless specific response headers are sent; this is not widely > implemented, and not advised for DOH). > > In particular, they are encouraged to assign an explicit freshness > lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign > heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby taking > control out of the hands of the DNS API server. > > Typically, the assigned freshness lifetime of a given DOH HTTP response > will use the smallest TTL in the Answer section of the DNS response as a > maximum. For example, if a HTTP response carries three RRsets with TTLs of > 30, 600 and 300, the HTTP freshness lifetime usually ought to be no more > than 30 seconds (e.g., "Cache-Control: max-age=30"), so that the RRset with > the smallest TTL is not stale when retrieved from cache. > > This assures that none of the RRsets contained within are served stale > from an HTTP cache. > > If the DNS response has no records in the Answer section, and the DNS > response has an SOA record in the Authority section, the response freshness > lifetime typically ought not be greater than the MINIMUM field from that > SOA record (see {{RFC2308}}). > > 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. > > DNS API servers also need to consider caching when generating responses > that are not globally valid. For instance, if a DNS API server customizes a > response based on the client's identity, it would not want to allow global > reuse of that response. This could be accomplished through a variety of > HTTP techniques such as a Cache-Control max-age of 0, or by using the Vary > response header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache > key ({{RFC7234}}, Section 4.1). > > DNS API clients MUST account for the Age response header's value > ({{RFC7234}}) when calculating the DNS TTL of a response. For example, if a > RRset is received with a DNS TTL of 600, but the Age header indicates that > the response has been cached for 250 seconds, the remaining lifetime of the > RRset is 350 seconds. > > DNS API clients that encounter stale responses (either because the HTTP > freshness lifetime has passed, or because one or more RRset's lifetime has > passed) can request a fresh copy by using the "no-cache" request cache > control directive ({{RFC7234}}, Section 5.2.1.4) and similar controls. Note > that some caches might not honour these directives, depending upon their > configuration. > > HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as > revalidation provides only a bandwidth benefit and DNS transactions are > normally latency bound. Furthermore, the HTTP response headers that enable > revalidation (such as "Last-Modified" and "Etag") are often fairly large > when compared to the overall DNS response size, and have a variable nature > that creates constant pressure on the HTTP/2 compression dictionary > {{RFC7541}}. Other types of DNS data, such as zone transfers, may be larger > and benefit more from revalidation. > > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000b02c94056bb036bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Mark,

This text reads= more fluidly, and that is nice. OTOH it doesn't do much to resolve the= core tension in https://github.com/dohwg/draft-i= etf-doh-dns-over-https/issues/153. The current ID uses normative l= anguage for creating http freshness lifetimes from DNS sets.

=
Comments from you and Martin (and this text suggestion) support = changing this from normative language to advice. The other comments favor t= he more deterministic behavior we currently have.

= Can you help me understand the argument you are making? Martin primarily su= ggests having the DNS code check the TTL before use rather than relying on = the cache to serve fresh responses - but I think that particular point has = met significant pushback largely from the DNS experts in the community.

fwiw I think I agree with the existing normative requ= irement - a response ought to be valid at the time of receipt and it is ver= y helpful to harmonize the concepts of DNS and HTTP valid. This doesn't= preclude fancy stuff like stale-if-error or insane client max-age headers = if a client is motivated.

The existing draft s= eems to have caused a little bit of confusion by saying SHOULD match rather= than MUST match.. The intent for that was to allow for http lifetimes less= than DNS lifetimes (particularly max-age:0 if you cannot figure out the DN= S lifetime from your HTTP server code). The subsequent sentence enforced th= e >=3D property.

Is there another aspect to= the question I'm missing?



=


On Tue, May 8, 2018 at 2:10 AM, Mark Nottingham <mnot@mnot.net&g= t; wrote:
On 3 Ma= y 2018, at 8:23 am, Paul Hoffman <paul.hoffman@icann.org> wrote:
>
> I'm going to re-up this here on the list. Please see the discussio= n on
>=C2=A0 =C2=A0https://github.com= /dohwg/draft-ietf-doh-dns-over-https/issues/153
>
> It would be handy if people who disagree with each other offer text *o= n the list*, not pull requests, specifying what they want the text in the d= raft to say. Then, people to try to come to consensus on this. (Yes, some p= eople are more comfortable with editing pull requests; I feel that this iss= ue is too important to not have the discussion here on the list.)

Proposal:

Cache Interaction {#caching}

A DNS API request can pass through a hierarchy of caches that include both = HTTP and DNS specific caches. HTTP caches are by design generic; that is, t= hey do not understand this protocol. Even if a DNS API client has modified = its cache implementation to be aware of DOH semantics, it does not follow t= hat all upstream caches (for example, in proxies, server-side gateways and = Content Delivery Networks) will be.

As a result, DNS API servers need to carefully consider the HTTP caching me= tadata they send in response to GET requests (POST requests are not cacheab= le unless specific response headers are sent; this is not widely implemente= d, and not advised for DOH).

In particular, they are encouraged to assign an explicit freshness lifetime= (Section 4.2 of {{RFC7234}}), since HTTP caches can assign heuristic fresh= ness otherwise (Section x.x of {{RFC7234}}), thereby taking control out of = the hands of the DNS API server.

Typically, the assigned freshness lifetime of a given DOH HTTP response wil= l use the smallest TTL in the Answer section of the DNS response as a maxim= um. For example, if a HTTP response carries three RRsets with TTLs of 30, 6= 00 and 300, the HTTP freshness lifetime usually ought to be no more than 30= seconds (e.g., "Cache-Control: max-age=3D30"), so that the RRset= with the smallest TTL is not stale when retrieved from cache.

This assures that none of the RRsets contained within are served stale from= an HTTP cache.

If the DNS response has no records in the Answer section, and the DNS respo= nse has an SOA record in the Authority section, the response freshness life= time typically ought not be greater than the MINIMUM field from that SOA re= cord (see {{RFC2308}}).

The stale-while-revalidate and stale-if-error Cache-Control directives ({{?= RFC5861}}) could be well suited to a DOH implementation when allowed by ser= ver policy. Those mechanisms allow a client, at the server's discretion= , to reuse a cache entry that is no longer fresh.

DNS API servers also need to consider caching when generating responses tha= t are not globally valid. For instance, if a DNS API server customizes a re= sponse based on the client's identity, it would not want to allow globa= l reuse of that response. This could be accomplished through a variety of H= TTP techniques such as a Cache-Control max-age of 0, or by using the Vary r= esponse header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache = key ({{RFC7234}}, Section 4.1).

DNS API clients MUST account for the Age response header's value ({{RFC= 7234}}) when calculating the DNS TTL of a response. For example, if a RRset= is received with a DNS TTL of 600, but the Age header indicates that the r= esponse has been cached for 250 seconds, the remaining lifetime of the RRse= t is 350 seconds.

DNS API clients that encounter stale responses (either because the HTTP fre= shness lifetime has passed, or because one or more RRset's lifetime has= passed) can request a fresh copy by using the "no-cache" request= cache control directive ({{RFC7234}}, Section 5.2.1.4) and similar control= s. Note that some caches might not honour these directives, depending upon = their configuration.

HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as = revalidation provides only a bandwidth benefit and DNS transactions are nor= mally latency bound. Furthermore, the HTTP response headers that enable rev= alidation (such as "Last-Modified" and "Etag") are ofte= n fairly large when compared to the overall DNS response size, and have a v= ariable nature that creates constant pressure on the HTTP/2 compression dic= tionary {{RFC7541}}. Other types of DNS data, such as zone transfers, may b= e larger and benefit more from revalidation.


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

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

--000000000000b02c94056bb036bb-- From nobody Tue May 8 04:54: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 1269412D96B for ; Tue, 8 May 2018 04:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=FJhQZHzA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QVRDgryB 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 czn-LqDKdYMX for ; Tue, 8 May 2018 04:54:39 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EDA12D962 for ; Tue, 8 May 2018 04:54:39 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8091920E37; Tue, 8 May 2018 07:54:38 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Tue, 08 May 2018 07:54:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=vz4TofEPGt4K+R5EY1yzc108qfTCd nvIesYE6EWnxVI=; b=FJhQZHzA+CRyficPFZKBs0t8yg0L2PB8/hkPfls9AalJD eNniT3u4fbpT5c/6mX0wpzQRCr7seI+YnmD10dVaWzrz9Oj4xfcr5uvnh+kbSt16 QYFqiXufhiQP/kXwjegv1/DZY0GmL1bULI39SXw8sQVHMw661fMW1P7LXCjNTwR0 sgouxWZcutAZRIbAtHJFxjYw74iP9/17a2jB/A0/2yW1haisoqHZMExTaRkaObJW +kUs0kbXrQuqpUDSLG6oFxyaGyRwbNRDvD8CTY4lWmkaYf8rRK2HvvEmgNpDLPuA /IO9w4W+TLPhJSlt+o57u+lxbO3Skm80PzIVLRiGw== 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=fm2; bh=vz4Tof EPGt4K+R5EY1yzc108qfTCdnvIesYE6EWnxVI=; b=QVRDgryBfww6jPUJ3akRgP o/3sPGMKkX8inJKjkoU5QN3KOd/Mrz05+u5A381HtDuikyl8wQNUWVYMG4tEm/5l 0DzR2kb/F+lweqviA7GZVANbQhDaVovLn2ownCmFomxV7u97J1aWAk35kK3WTxEQ LF7jCZgn6soqaBcXRFmBg8U55kOoKojO6fLgMQzjch6fMRZ595zoRWThKL3iVaTN 1mVt1Kbco/tvDnfIPHJ7g7V3cJpep179isdSqEStFBW3zKAUzPSz4LkkYMifz0EE Noi7GbuLNVijUdGDsCxrIJktZNI/7fzF5XZjxKTtjkNnHweGYoISOeTy/lux9YAg == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 71C5210453; Tue, 8 May 2018 07:54:36 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: Date: Tue, 8 May 2018 21:54:32 +1000 Cc: Paul Hoffman , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> To: Patrick McManus X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 11:54:42 -0000 > On 8 May 2018, at 9:37 pm, Patrick McManus = wrote: >=20 > Thanks Mark, >=20 > This text reads more fluidly, and that is nice. OTOH it doesn't do = much to resolve the core tension in = https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153. The = current ID uses normative language for creating http freshness lifetimes = from DNS sets. Well, Paul asked for text... > Comments from you and Martin (and this text suggestion) support = changing this from normative language to advice. The other comments = favor the more deterministic behavior we currently have. >=20 > Can you help me understand the argument you are making? Martin = primarily suggests having the DNS code check the TTL before use rather = than relying on the cache to serve fresh responses - but I think that = particular point has met significant pushback largely from the DNS = experts in the community. I'm not hearing pushback to this approach on this thread so far, so I'd = like to hear (here) what the issue is. > fwiw I think I agree with the existing normative requirement - a = response ought to be valid at the time of receipt and it is very helpful = to harmonize the concepts of DNS and HTTP valid. This doesn't preclude = fancy stuff like stale-if-error or insane client max-age headers if a = client is motivated. HTTP caches can and do serve stale content even without those "fancy" = things (e.g., when the origin server is disconnected). If you're using = HTTP and caching has taken place, you fundamentally need to understand = how old the response you're using is if it's time-sensitive -- which = this is. That means checking the Age. > The existing draft seems to have caused a little bit of confusion by = saying SHOULD match rather than MUST match.. The intent for that was to = allow for http lifetimes less than DNS lifetimes (particularly max-age:0 = if you cannot figure out the DNS lifetime from your HTTP server code). = The subsequent sentence enforced the >=3D property. >=20 > Is there another aspect to the question I'm missing? It looks like you're using RFC2119 requirements to bring attention to = important parts of the specification ("we really mean that this could = trip you up"), rather than stating actual requirements for = interoperability. These MUSTs aren't testable, and they may be too = confining in some deployments. This stuff really is advice, of the "if = it hurts, don't do that" sort -- not requirements. >=20 >=20 >=20 >=20 >=20 > On Tue, May 8, 2018 at 2:10 AM, Mark Nottingham wrote: > On 3 May 2018, at 8:23 am, Paul Hoffman = wrote: > >=20 > > I'm going to re-up this here on the list. Please see the discussion = on > > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 > >=20 > > It would be handy if people who disagree with each other offer text = *on the list*, not pull requests, specifying what they want the text in = the draft to say. Then, people to try to come to consensus on this. = (Yes, some people are more comfortable with editing pull requests; I = feel that this issue is too important to not have the discussion here on = the list.) >=20 > Proposal: >=20 > Cache Interaction {#caching} >=20 > A DNS API request can pass through a hierarchy of caches that include = both HTTP and DNS specific caches. HTTP caches are by design generic; = that is, they do not understand this protocol. Even if a DNS API client = has modified its cache implementation to be aware of DOH semantics, it = does not follow that all upstream caches (for example, in proxies, = server-side gateways and Content Delivery Networks) will be. >=20 > As a result, DNS API servers need to carefully consider the HTTP = caching metadata they send in response to GET requests (POST requests = are not cacheable unless specific response headers are sent; this is not = widely implemented, and not advised for DOH).=20 >=20 > In particular, they are encouraged to assign an explicit freshness = lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign = heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby = taking control out of the hands of the DNS API server. >=20 > Typically, the assigned freshness lifetime of a given DOH HTTP = response will use the smallest TTL in the Answer section of the DNS = response as a maximum. For example, if a HTTP response carries three = RRsets with TTLs of 30, 600 and 300, the HTTP freshness lifetime usually = ought to be no more than 30 seconds (e.g., "Cache-Control: max-age=3D30"),= so that the RRset with the smallest TTL is not stale when retrieved = from cache. >=20 > This assures that none of the RRsets contained within are served stale = from an HTTP cache. >=20 > If the DNS response has no records in the Answer section, and the DNS = response has an SOA record in the Authority section, the response = freshness lifetime typically ought not be greater than the MINIMUM field = from that SOA record (see {{RFC2308}}). >=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. >=20 > DNS API servers also need to consider caching when generating = responses that are not globally valid. For instance, if a DNS API server = customizes a response based on the client's identity, it would not want = to allow global reuse of that response. This could be accomplished = through a variety of HTTP techniques such as a Cache-Control max-age of = 0, or by using the Vary response header ({{RFC7231}}, Section 7.1.4) to = establish a secondary cache key ({{RFC7234}}, Section 4.1). >=20 > DNS API clients MUST account for the Age response header's value = ({{RFC7234}}) when calculating the DNS TTL of a response. For example, = if a RRset is received with a DNS TTL of 600, but the Age header = indicates that the response has been cached for 250 seconds, the = remaining lifetime of the RRset is 350 seconds.=20 >=20 > DNS API clients that encounter stale responses (either because the = HTTP freshness lifetime has passed, or because one or more RRset's = lifetime has passed) can request a fresh copy by using the "no-cache" = request cache control directive ({{RFC7234}}, Section 5.2.1.4) and = similar controls. Note that some caches might not honour these = directives, depending upon their configuration. >=20 > HTTP conditional requests ({{RFC7232}}) may be of limited value to = DOH, as revalidation provides only a bandwidth benefit and DNS = transactions are normally latency bound. Furthermore, the HTTP response = headers that enable revalidation (such as "Last-Modified" and "Etag") = are often fairly large when compared to the overall DNS response size, = and have a variable nature that creates constant pressure on the HTTP/2 = compression dictionary {{RFC7541}}. Other types of DNS data, such as = zone transfers, may be larger and benefit more from revalidation. >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue May 8 05:17:24 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07AF12DB6F for ; Tue, 8 May 2018 05:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FbXTG9BMjxGq for ; Tue, 8 May 2018 05:17:20 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8248812DB6D for ; Tue, 8 May 2018 05:17:20 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id o4-v6so32058959wrm.0 for ; Tue, 08 May 2018 05:17:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=z1bXUmAhxGOpW7sv9Lnfkp08wGMMWj11ScW7hSMDvEY=; b=d6O8t38owHKEfpKejBgLyY5lhi3eQIPARnbALSixeG6hzBOvLHfV87WMaNPMhw1aLY jNhHKcY6xWwe56rC6KzJZnWBXHdt63T2SIsIcRqmcAoo5+3nFA4rs9DBJAzfZqGI9c49 fgUMm/5od9LPl4wlGxYIbDGdfWZtk/q6mvtOQFmFmeOSXXSXizdpnG3XMIfQSdnWiAoy QsAHNIgWBX3QxvTP6v9eSBFd/nCub7ve9x/9Xj2SEVZSg+5AL3N6izcGqeG6R0bfBHfs ULgCmWi1ttbDbSSBnYJn6Uf4b+Vf4ictoxOrJsCH95Zpo81sKfZrqtpYeiRsf/Aknfv3 Rg4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z1bXUmAhxGOpW7sv9Lnfkp08wGMMWj11ScW7hSMDvEY=; b=Dp/IxDRd3rNpd1N7bQPuY/RPGHU9ik82G784ROUyiYU7EwPw53s3FWICBRj1oVpsy1 qBFFrEHkwsSp4pzs6xr31YZ+DpU5MTGNuLwX8LZmb90jkN5TIYX2XzxevoGx0FPg6SIT FJuX2SNk3Qad24+p7PM7ftKLJLwz4IUUeBPm2Y0jlhMWB4GwBhdOyz1YPuET4TOP7kTr w/CUoGvNAa7CXO2xPZGbjemK4vBu/hAoL7z7xcmGA/NYN+IR+nyYPa//fGC2DWhAH4Zr c+Eq259RZflibdE7j7mQ8rOEGENa/B1h3+QqxvpCw90newvgXYL5mXjl9JtfHWtTxfh6 nRWw== X-Gm-Message-State: ALQs6tDdoLgQaG17cbRSs/pvzrmi8Yc7KedqdArp5aP6Yya8MRSJZNou sdhIDOp+eiQxSOan9Lz2KXwYXwMsPUgmMa+qL6bdHViB74s= X-Google-Smtp-Source: AB8JxZqKWS0KSg+UKeJlQQVsFt8hFGsC1GfTEaDCzo0LbKL5t866rYBjVJgNkBnNUovIDG5m7Y8smfkh5Hz25QC5l4U= X-Received: by 2002:adf:e1ce:: with SMTP id l14-v6mr32320100wri.148.1525781838473; Tue, 08 May 2018 05:17:18 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Tue, 08 May 2018 12:16:42 +0000 Message-ID: To: doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Doh] DNS Resolver Identification and Use (DRIU) BoF. X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 12:17:23 -0000 [ Apparently first version of this mail didn't arrive, resending. ] Hi all, I wanted to mention a proposed (non-WG forming) BoF -- DNS Resolver Identification and Use (DRIU). The description is below, and the mailing list is: https://www.ietf.org/mailman/listinfo/driu I think that this will be of interest to many... -------- The IETF has added additional methods for DNS stub resolvers to get to recursive resolvers (notably DNS-over-TLS, RFC 7858), and is about to add another (DNS-over-HTTPS, from the DOH Working Group). As these have been developed, questions have been raised about how to identify these resolvers from protocols such as DHCP and DHCPv6, what the security properties these transports have in various configurations (such as between strict security and opportunistic security), and what it means for a user who has multiple resolvers configured when the elements of the configured set have different transports and security properties. This BoF is not intended to form a Working Group. Instead, it is meant to bring together authors of various WG and individual drafts to prevent overlap and to garner interest in particular topics. Because many people are thinking of writing documents covering various related topics, it would be good to have a mailing list and a BoF to help cross-pollinate the ideas. Some of the topics that would be on-topic would be: * How to identify DNS-over-different-transport in protocols such as DHCP, and in user-accessible configuration * Security properties of the various flavors of transport-secured DNS * TLS authentication when the identifier is an IP address (which is most common for identifying DNS resolvers) * How resolvers can express their capabilities to clients who might care (such as "this resolver does DNSSEC validation" or "this resolver passes client subnet information to authoritative servers") * Identifying a resolver in the "dns:" URI scheme in RFC 4501. A related question is whether there should be a "dnss:" URI scheme whose semantics mean "Look up this name, but only use a secure DNS server", where "secure" would need to be defined. * There are likely additional related topics that the BoF and mailing list might delve into. ----- W -- 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 From nobody Tue May 8 09:25:26 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF312E891 for ; Tue, 8 May 2018 09:25:23 -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 rVgvfm2-sppA for ; Tue, 8 May 2018 09:25:21 -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 5A7ED12E9D9 for ; Tue, 8 May 2018 09:25:21 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id E39423A026 for ; Tue, 8 May 2018 12:25:20 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id t27-v6so28856562oij.9 for ; Tue, 08 May 2018 09:25:20 -0700 (PDT) X-Gm-Message-State: ALQs6tAd9+MCb7jRso+LOp43oJT6m8OoObNoXwFyHAls85O/ypKfGXgq Tdy8mPpAN6HccSNsoWVzNanCtMqboraCA1QFtIE= X-Google-Smtp-Source: AB8JxZpgp0OxxM3hx0/vBZLO5f1lNtoQauaMbCwoj2Tcewkro8hhkgHWZLAq54bhhJ2rwUZ/O4SSfiVfSIBf64WZpfI= X-Received: by 2002:aca:f388:: with SMTP id r130-v6mr25388281oih.17.1525796720621; Tue, 08 May 2018 09:25:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.36 with HTTP; Tue, 8 May 2018 09:25:20 -0700 (PDT) In-Reply-To: <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> From: Patrick McManus Date: Tue, 8 May 2018 18:25:20 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Mark Nottingham Cc: Patrick McManus , Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="000000000000883e87056bb43b80" Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:25:24 -0000 --000000000000883e87056bb43b80 Content-Type: text/plain; charset="UTF-8" On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham wrote: > > > This text reads more fluidly, and that is nice. OTOH it doesn't do much > to resolve the core tension in https://github.com/dohwg/draft > -ietf-doh-dns-over-https/issues/153. The current ID uses normative > language for creating http freshness lifetimes from DNS sets. > > Well, Paul asked for text... > > I forgot to say thank you for the text - I just was trying to communicate that I think the rationale is more of the blocker for this issue than the text. So that's what I'm trying to drill down on here.. > > Comments from you and Martin (and this text suggestion) support changing > this from normative language to advice. The other comments favor the more > deterministic behavior we currently have. > > > > Can you help me understand the argument you are making? Martin primarily > suggests having the DNS code check the TTL before use rather than relying > on the cache to serve fresh responses - but I think that particular point > has met significant pushback largely from the DNS experts in the community. > > I'm not hearing pushback to this approach on this thread so far, so I'd > like to hear (here) what the issue is. > Ben and Dave pushed back in the github - it would be helpful to hear them here as well, I agree. > > HTTP caches can and do serve stale content even without those "fancy" > things (e.g., when the origin server is disconnected). If you're using HTTP > and caching has taken place, you fundamentally need to understand how old > the response you're using is if it's time-sensitive -- which this is. That > means checking the Age. > > This text doesn't prevent you from serving anything - it just defines how you set the freshness lifetime so that an Age calculation at the HTTP level actually reflects the fresh/stale status of the DNS content in a conservative fashion. A client very concerned about that could make the calculation or it can assume that the server did the best it could do (i.e. its either fresh, or stale in extremis so use it anyhow) and use it once for record types like A. > The existing draft seems to have caused a little bit of confusion by > saying SHOULD match rather than MUST match.. The intent for that was to > allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if > you cannot figure out the DNS lifetime from your HTTP server code). The > subsequent sentence enforced the >= property. > > > > Is there another aspect to the question I'm missing? > > It looks like you're using RFC2119 requirements to bring attention to > important parts of the specification ("we really mean that this could trip > you up"), rather than stating actual requirements for interoperability. > These MUSTs aren't testable, and they may be too confining in some > deployments. This stuff really is advice, of the "if it hurts, don't do > that" sort -- not requirements. > > I must be misunderstanding what you mean by not testable - the alignment of expiration information seems pretty observable. And there is an operational impact to terminal clients without caches (either DNS or HTTP) which simply want to lookup a record and use it having to retry to get non-expired info (and the rather large risk of them not trying and using old data instead). So I guess you can argue that without 2119 language the DOH client and server can communicate, but without normative provisions constraining the server you can't interop well with the Internet.. seems 2119 in scope to me. --000000000000883e87056bb43b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham <mnot@mnot.n= et> wrote:

> This text reads more fluidly, and that is nice. OTOH it doesn't do= much to resolve the core tension in https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/1= 53. The current ID uses normative language for creating http freshness = lifetimes from DNS sets.

Well, Paul asked for text...

I forgot to say thank you for the text -= I just was trying to communicate that I think the rationale is more of the= blocker for this issue than the text. So that's what I'm trying to= drill down on here..

=C2=A0
> Comments from you and Martin (and this text suggestion) support changi= ng this from normative language to advice. The other comments favor the mor= e deterministic behavior we currently have.
>
> Can you help me understand the argument you are making? Martin primari= ly suggests having the DNS code check the TTL before use rather than relyin= g on the cache to serve fresh responses - but I think that particular point= has met significant pushback largely from the DNS experts in the community= .

I'm not hearing pushback to this approach on this thread so far,= so I'd like to hear (here) what the issue is.
Ben and Dave pushed back in the github - it would be helpful to= hear them here as well, I agree.
=C2=A0

HTTP caches can and do serve stale content even without those "= fancy" things (e.g., when the origin server is disconnected). If you&#= 39;re using HTTP and caching has taken place, you fundamentally need to und= erstand how old the response you're using is if it's time-sensitive= -- which this is. That means checking the Age.


This text doesn't pre= vent you from serving anything - it just defines how you set the freshness = lifetime so that an Age calculation at the HTTP level actually reflects the= fresh/stale status of the DNS content in a conservative fashion. A client = very concerned about that could make the calculation or it can assume that = the server did the best it could do (i.e. its either fresh, or stale in ext= remis so use it anyhow) and use it once for record types like A.
<= div>
> The existing draft seems to have caused a little bit of confusion by s= aying SHOULD match rather than MUST match.. The intent for that was to allo= w for http lifetimes less than DNS lifetimes (particularly max-age:0 if you= cannot figure out the DNS lifetime from your HTTP server code). The subseq= uent sentence enforced the >=3D property.
>
> Is there another aspect to the question I'm missing?

It looks like you're using RFC2119 requirements to bring attenti= on to important parts of the specification ("we really mean that this = could trip you up"), rather than stating actual requirements for inter= operability. These MUSTs aren't testable, and they may be too confining= in some deployments. This stuff really is advice, of the "if it hurts= , don't do that" sort -- not requirements.


I must be misunde= rstanding what you mean by not testable - the alignment of expiration infor= mation seems pretty observable. And there is an operational impact to termi= nal clients without caches (either DNS or HTTP) which simply want to lookup= a record and use it having to retry to get non-expired info (and the rathe= r large risk of them not trying and using old data instead). So I guess you= can argue that without 2119 language the DOH client and server can communi= cate, but without normative provisions constraining the server you can'= t interop well with the Internet.. seems 2119 in scope to me.
=C2=A0

--000000000000883e87056bb43b80-- From nobody Tue May 8 09:44:24 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0CA126E64 for ; Tue, 8 May 2018 09:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Tmd9a9pciZqU for ; Tue, 8 May 2018 09:44:19 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0737312EA52 for ; Tue, 8 May 2018 09:44:19 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f21-v6so39155838iob.13 for ; Tue, 08 May 2018 09:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZOv68iknE5oeONRdZ5fjNmv4WDGE9RELj7lt7wCrC5k=; b=IdE2unIQoSCgLZm4U4icBXBPkf4fSdb1g5pdw/7VabB4HOItiZ15ZC44t1ITBoleny LcxtQnNRK5Fvbd64cFE8buXY/q3OpNbPnMRWHHXtHElJQYuHtEahcAZgOwvt144NK4Ct a3QJ89AVzBPCTdiTjET0vG0POec1Di9jC5NAtmk2fKlhA78CoMOj+KNp2LOweJ0yvfvw O8dbwpRA2MQkmdOB0Pu0nkvRowgqNV+1Nc5zk7f/kayfVFfB5K7KINrUdHEoMPKc3+tJ ekO7ewzg96mVhwqQISCtioNpTH8c9aiIZr5Gy03u2YTghayyQ3wMun64far+vfwdyvBa ciZQ== 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=ZOv68iknE5oeONRdZ5fjNmv4WDGE9RELj7lt7wCrC5k=; b=ZnkxOZ6YLeU8s3Rl4SMSXamJeumSL1LmjYrGs8vfy4tCav7QRXSTjprQAHRQAMRs+8 dwupMpsuUEZ95N2TKsyHnQr3ABPyAvz5tv87CESzqmQnlFhoCSfUBBG2gAk3CrumF+g1 86qXf//PJ4tG7zoUMLJ514BoUo8KYTcQyEfXdHJlxJwdaqKGZWS6xOqRpD0Hgc1axwWM qSqoeL2scKlGMdoMh9NOHkx2BKWe7E3DM3lBDgIlihrXHGjWjVkZ3R6snteySFChQuv6 1rdEHx7yxW/6/HnvHyjGascbEhwE0qhyymcFCejAbJJS+Ya8+akDY2ZJpixppXgp2drd nphw== X-Gm-Message-State: ALQs6tCZi2nB1BQag1+lVTZW4VFNgB0IyGR7P4QNQy5EKdqJfHdNBHxf EIWg6MGe94dv/obSvdJEN5wVficYf/sq/cmtqRoL7fW2aiI= X-Google-Smtp-Source: AB8JxZota+YG7EQ0UuOORZxiUA0X91ey987YwKnl4frgR/R6U+PS1TE7SmeVSibP899t7O8OYBonLirbYUdNZuosV6I= X-Received: by 2002:a6b:697:: with SMTP id f23-v6mr46051022ioi.18.1525797857865; Tue, 08 May 2018 09:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.70.12 with HTTP; Tue, 8 May 2018 09:44:17 -0700 (PDT) In-Reply-To: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> From: Ben Schwartz Date: Tue, 8 May 2018 12:44:17 -0400 Message-ID: To: Patrick McManus Cc: Mark Nottingham , Paul Hoffman , DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000005c00c7056bb47f00" Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:44:23 -0000 --0000000000005c00c7056bb47f00 Content-Type: multipart/alternative; boundary="00000000000051ebeb056bb47fe7" --00000000000051ebeb056bb47fe7 Content-Type: text/plain; charset="UTF-8" On Tue, May 8, 2018 at 12:25 PM, Patrick McManus wrote: > On Tue, May 8, 2018 at 1:54 PM, Mark Nottingham wrote: > >> >> > This text reads more fluidly, and that is nice. OTOH it doesn't do much >> to resolve the core tension in https://github.com/dohwg/draft >> -ietf-doh-dns-over-https/issues/153. The current ID uses normative >> language for creating http freshness lifetimes from DNS sets. >> >> Well, Paul asked for text... >> >> I forgot to say thank you for the text - I just was trying to communicate > that I think the rationale is more of the blocker for this issue than the > text. So that's what I'm trying to drill down on here.. > > > >> > Comments from you and Martin (and this text suggestion) support >> changing this from normative language to advice. The other comments favor >> the more deterministic behavior we currently have. >> > >> > Can you help me understand the argument you are making? Martin >> primarily suggests having the DNS code check the TTL before use rather than >> relying on the cache to serve fresh responses - but I think that particular >> point has met significant pushback largely from the DNS experts in the >> community.. >> >> I'm not hearing pushback to this approach on this thread so far, so I'd >> like to hear (here) what the issue is. >> > > Ben and Dave pushed back in the github - it would be helpful to hear them > here as well, I agree. > As a standards matter, it seems to me that the DNS experts are still working out the details of when it might be OK to go past the end of TTL (e.g. https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale-00). Allowing DOH to violate TTL would risk pre-empting that DNS discussion. I think it's worthwhile for us to be conservative in what we send until serve-stale and related DNS issues are resolved. > >> >> HTTP caches can and do serve stale content even without those "fancy" >> things (e.g., when the origin server is disconnected). If you're using HTTP >> and caching has taken place, you fundamentally need to understand how old >> the response you're using is if it's time-sensitive -- which this is. That >> means checking the Age. >> >> > This text doesn't prevent you from serving anything - it just defines how > you set the freshness lifetime so that an Age calculation at the HTTP level > actually reflects the fresh/stale status of the DNS content in a > conservative fashion. A client very concerned about that could make the > calculation or it can assume that the server did the best it could do (i.e. > its either fresh, or stale in extremis so use it anyhow) and use it once > for record types like A. > > > The existing draft seems to have caused a little bit of confusion by >> saying SHOULD match rather than MUST match.. The intent for that was to >> allow for http lifetimes less than DNS lifetimes (particularly max-age:0 if >> you cannot figure out the DNS lifetime from your HTTP server code). The >> subsequent sentence enforced the >= property. >> > >> > Is there another aspect to the question I'm missing? >> >> It looks like you're using RFC2119 requirements to bring attention to >> important parts of the specification ("we really mean that this could trip >> you up"), rather than stating actual requirements for interoperability. >> These MUSTs aren't testable, and they may be too confining in some >> deployments. This stuff really is advice, of the "if it hurts, don't do >> that" sort -- not requirements. >> >> > I must be misunderstanding what you mean by not testable - the alignment > of expiration information seems pretty observable. And there is an > operational impact to terminal clients without caches (either DNS or HTTP) > which simply want to lookup a record and use it having to retry to get > non-expired info (and the rather large risk of them not trying and using > old data instead). So I guess you can argue that without 2119 language the > DOH client and server can communicate, but without normative provisions > constraining the server you can't interop well with the Internet.. seems > 2119 in scope to me. > > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --00000000000051ebeb056bb47fe7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 8, 2018 at 12:25 PM, Patrick McManus <= pmcmanus@mozilla.= com> wrote:
On Tue, May 8, 2018 at 1:54 PM,= Mark Nottingham <mnot@mnot.net> wrote:

> This text reads more fluidly, and that is nice. OTOH it doesn't do= much to resolve the core tension in https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/1= 53. The current ID uses normative language for creating http freshness = lifetimes from DNS sets.

Well, Paul asked for text...

I forgot to say thank you for the= text - I just was trying to communicate that I think the rationale is more= of the blocker for this issue than the text. So that's what I'm tr= ying to drill down on here..

=C2=A0
> Comments from you and Martin (and this text suggestion) support changi= ng this from normative language to advice. The other comments favor the mor= e deterministic behavior we currently have.
>
> Can you help me understand the argument you are making? Martin primari= ly suggests having the DNS code check the TTL before use rather than relyin= g on the cache to serve fresh responses - but I think that particular point= has met significant pushback largely from the DNS experts in the community= ..

I'm not hearing pushback to this approach= on this thread so far, so I'd like to hear (here) what the issue is.

Ben and Dave pushed back in the g= ithub - it would be helpful to hear them here as well, I agree.

As a standards matter, it = seems to me that the DNS experts are still working out the details of when = it might be OK to go past the end of TTL (e.g.=C2=A0https://tools.ietf.org/htm= l/draft-ietf-dnsop-serve-stale-00).=C2=A0 Allowing DOH to violate TTL w= ould risk pre-empting that DNS discussion.=C2=A0 I think it's worthwhil= e for us to be conservative in what we send until serve-stale and related D= NS issues are resolved.

=C2=A0=

HTTP caches can and do serve stale content even without those "= fancy" things (e.g., when the origin server is disconnected). If you&#= 39;re using HTTP and caching has taken place, you fundamentally need to und= erstand how old the response you're using is if it's time-sensitive= -- which this is. That means checking the Age.


This text doesn= 9;t prevent you from serving anything - it just defines how you set the fre= shness lifetime so that an Age calculation at the HTTP level actually refle= cts the fresh/stale status of the DNS content in a conservative fashion. A = client very concerned about that could make the calculation or it can assum= e that the server did the best it could do (i.e. its either fresh, or stale= in extremis so use it anyhow) and use it once for record types like A.
=

> The existing draft seems to have caused a little bit of confusion by s= aying SHOULD match rather than MUST match.. The intent for that was to allo= w for http lifetimes less than DNS lifetimes (particularly max-age:0 if you= cannot figure out the DNS lifetime from your HTTP server code). The subseq= uent sentence enforced the >=3D property.
>
> Is there another aspect to the question I'm missing?

It looks like you're using RFC2119 requirements to bring attenti= on to important parts of the specification ("we really mean that this = could trip you up"), rather than stating actual requirements for inter= operability. These MUSTs aren't testable, and they may be too confining= in some deployments. This stuff really is advice, of the "if it hurts= , don't do that" sort -- not requirements.


I must be misunderstanding what= you mean by not testable - the alignment of expiration information seems p= retty observable. And there is an operational impact to terminal clients wi= thout caches (either DNS or HTTP) which simply want to lookup a record and = use it having to retry to get non-expired info (and the rather large risk o= f them not trying and using old data instead). So I guess you can argue tha= t without 2119 language the DOH client and server can communicate, but with= out normative provisions constraining the server you can't interop well= with the Internet.. seems 2119 in scope to me.
=C2=A0
<= /div>

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


--00000000000051ebeb056bb47fe7-- --0000000000005c00c7056bb47f00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCud6p+2wFb2Lg44Nf6tf52 3WYThW/wPNtY/VyWhcmYIDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MDgxNjQ0MThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAYI8uI3EPfyuilJRXwM9aGsc18Qnk72nQSNm2m9P9 VJLqJG0zPZZOuWV5QT6SgB0ugcsLoWXtfToo4iEATFXex3HD7tY20luvVoIMNbr22OY6cfZs5SNx PPqn7PWNpuKfSAOdLVVG0RikVrRcU3ulVCKLWG9eOu3ekAM4LNTkJ9LAPGNjAgI4lfkmqHYEh9i6 IdDciP/S1lgOrQ5BGhWwHLNBmOd31Mri5zNDpoqxwghi6RytoM5JDBWowqfAWOorYrtXDhj/Lp04 ijwciGav4tbuWJpQlNFWicw1UNfvXYeZf+d71NTpbMCSfwDPv8zufgjona3A3RNj+VuUM9rftw== --0000000000005c00c7056bb47f00-- From nobody Tue May 8 09:57: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 5973312EA58 for ; Tue, 8 May 2018 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upIvkBqiQXZ2 for ; Tue, 8 May 2018 09:56:58 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3947612EA56 for ; Tue, 8 May 2018 09:56:58 -0700 (PDT) Received: from [2001:b98:204:102:fffa::] (port=50845) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fG5v4-0007BN-TF for doh@ietf.org; Tue, 08 May 2018 17:56:56 +0100 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_B7E53C64-8E55-4146-8807-C84060655613" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 8 May 2018 17:56:53 +0100 References: <2AE1447E-98A1-41CA-91B7-3019711D3E8E@sinodun.com> To: DoH WG In-Reply-To: <2AE1447E-98A1-41CA-91B7-3019711D3E8E@sinodun.com> Message-Id: <92391030-9BBD-4835-A42E-6D32BA2F08CA@sinodun.com> X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Doh] WGLC on draft-ietf-doh-dns-over-https X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 16:57:00 -0000 --Apple-Mail=_B7E53C64-8E55-4146-8807-C84060655613 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi All,=20 A small pull request after off-list comments by Willem Toorop on the = wording for DNSSEC usage: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/176 = Sara.=20 > On 4 May 2018, at 18:03, Sara Dickinson wrote: >=20 > Hi All,=20 >=20 > The text in the latest GitHub version of the draft now uses phrases = like "a client MUST specifically authorize DNS API servers=E2=80=9D.=20 >=20 > I=E2=80=99m not clear if there is any difference between = =E2=80=98authorizing=E2=80=99 a server and just using a server? If there = is some subtlety here then I=E2=80=99d like to understand if but if not = I created = https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 = to = simplify the text and also put the discussion of selection of server in = its own section.=20 >=20 > Sara.=20 >=20 >> On 30 Apr 2018, at 18:59, Sara Dickinson > wrote: >>=20 >>=20 >> 4) Section 8: With regard to trusted/untrusted servers I would = suggest at least a small restructure for clarity. At the moment the = first discussion of the client trust model is in section 5.3 =E2=80=98Serv= er Push=E2=80=99. >>=20 >> I would suggest adding a section before this (possibly after section = 3) called something like =E2=80=99Trust model for client queries=E2=80=99 = with the following (combining text from section 5.3 and 8): >=20 > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh --Apple-Mail=_B7E53C64-8E55-4146-8807-C84060655613 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = All, 

A small = pull request after off-list comments by Willem Toorop on the wording for = DNSSEC usage:
https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/176=

Sara. 

On 4 May 2018, at 18:03, Sara = Dickinson <sara@sinodun.com> wrote:

Hi All, 

The text in the latest = GitHub version of the draft now uses phrases like "a client = MUST specifically authorize DNS API = servers=E2=80=9D. 

I=E2=80=99m not clear if there is any difference between = =E2=80=98authorizing=E2=80=99 a server and just using a server? If there = is some subtlety here then I=E2=80=99d like to understand if but if not = I created https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174=  to simplify the text and also put the discussion of selection = of server in its own section. 

Sara. 

On 30 Apr 2018, at 18:59, Sara Dickinson <sara@sinodun.com> = wrote:


4) Section 8: With regard to = trusted/untrusted servers I would suggest at least a small restructure = for clarity. At the moment the first discussion of the client trust = model is in section 5.3 =E2=80=98Server Push=E2=80=99.

I would suggest adding a = section before this (possibly after section 3) called something like = =E2=80=99Trust model for client queries=E2=80=99 with the following = (combining text from section 5.3 and = 8):

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

= --Apple-Mail=_B7E53C64-8E55-4146-8807-C84060655613-- From nobody Tue May 8 17:01: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 6677D12D7F2 for ; Tue, 8 May 2018 17:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvR30VOoa4g1 for ; Tue, 8 May 2018 17:01:50 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 D587312D7F1 for ; Tue, 8 May 2018 17:01:49 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 11-v6so29952384ois.8 for ; Tue, 08 May 2018 17:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a6DBfjaneJkK0ckh7J2cXOCg4L908SGVNOpDW2X+jqk=; b=IfaeFqBfgA9bhlG50UTXzYHvxDU9Ifre/6GqU/8YKJLa/XT9pQly1HvulTUdEgsIZ7 HKXRGpdOq1SLmJ7HsZfBIWLey29rVPjtEuV35GTty5lPugw32DvCqxxY454d/fuUxZgo cGb1pKdn+mDS+mhNXpxt7W7W002Hk46kJPtkQWsov3OF4BwufD1hAiJxY3FUYvW9p+Eq Ij1WcQqPKstI8yp30Kid/obpNp2Tp824Ay+QnCdni3uCjuoKQ87JVf133PfICXQV8Y/3 ifjhgi3/HSsd/uMyJ5A0jD4AeRLAH4aACiwnIvUOqnvvsTnkzbN4mUguIEn7f+nnFcqp oLiA== 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=a6DBfjaneJkK0ckh7J2cXOCg4L908SGVNOpDW2X+jqk=; b=Vd9sebdirobFPgsRQgArtKUkfJJ/SfD8OrZixfHamgd1ZqXIEJcTrr4sP/Jo2VcaBH 2qj00AkqxVZKYL4Wtv1Lx+M8tIX+lUqeLTOkAqAiH4he7LqRWiLCN1uOU/klhopA4HUR /RJKdyC04rBczL0n/RNTozoY+GBDOKoOiOS1AFKEAkIHSYRsL0dwPfTeECHosTyu8Gy6 z7YdCYrwCJeCbotvsSUvd4DtIgL1Yg5xKu8bkRRjykYSy0Ul/ibaNf1YaF57vTbQS/ZF yxA5J83+kuEBYuJYLBlIUh9D5z3V/AlfSedUaksrWjvbJVvGOhVVjAbW7iC9cBllxvD2 hFag== X-Gm-Message-State: ALQs6tBm7jHCjmfOykY8/NjNjRsxYSApSsuyzdQgaDXQuqIID31+w9Is xSq3UVbAgDFqB42zA5+D8b3idEnSRbLXmtEv8jU= X-Google-Smtp-Source: AB8JxZrVFLR63C6sCoEOkMtk7vA+/awxcmyvBcbRFuGJS8QscoUIcNmb3JW+HcKrlANdliGByqvFd1WVO+bMjkPEbLs= X-Received: by 2002:aca:62c1:: with SMTP id w184-v6mr22141198oib.122.1525824109014; Tue, 08 May 2018 17:01:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.67.153 with HTTP; Tue, 8 May 2018 17:01:18 -0700 (PDT) In-Reply-To: <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> From: Ted Hardie Date: Tue, 8 May 2018 17:01:18 -0700 Message-ID: To: Mark Nottingham Cc: Paul Hoffman , DoH WG Content-Type: multipart/alternative; boundary="00000000000001f2aa056bba9cac" Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 00:01:53 -0000 --00000000000001f2aa056bba9cac Content-Type: text/plain; charset="UTF-8" Howdy, Some comments in-line, thanks for the text. On Mon, May 7, 2018 at 5:10 PM, Mark Nottingham wrote: > On 3 May 2018, at 8:23 am, Paul Hoffman wrote: > > > > I'm going to re-up this here on the list. Please see the discussion on > > https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/153 > > > > It would be handy if people who disagree with each other offer text *on > the list*, not pull requests, specifying what they want the text in the > draft to say. Then, people to try to come to consensus on this. (Yes, some > people are more comfortable with editing pull requests; I feel that this > issue is too important to not have the discussion here on the list.) > > Proposal: > > Cache Interaction {#caching} > > A DNS API request can pass through a hierarchy of caches that include both > HTTP and DNS specific caches. HTTP caches are by design generic; that is, > they do not understand this protocol. Even if a DNS API client has modified > its cache implementation to be aware of DOH semantics, it does not follow > that all upstream caches (for example, in proxies, server-side gateways and > Content Delivery Networks) will be. > > I think it would be useful to specify whether we are talking only about the upstream network caches or the local caches when using phrases like "pass through" (the use of a local HTTP cache here by a DNS API service to furnish data to a DNS client should either be explicitly in or out of scope, in other words). > As a result, DNS API servers need to carefully consider the HTTP caching > metadata they send in response to GET requests (POST requests are not > cacheable unless specific response headers are sent; this is not widely > implemented, and not advised for DOH). > > In particular, they are encouraged to assign an explicit freshness > lifetime (Section 4.2 of {{RFC7234}}), since HTTP caches can assign > heuristic freshness otherwise (Section x.x of {{RFC7234}}), thereby taking > control out of the hands of the DNS API server. > > I agree with other that the use of RFC 2119 language like SHOULD is appropriate here. We may want to allow for some variance, but a very clear expectation will help more than "encouraged" will, at least in my opinion. > Typically, the assigned freshness lifetime of a given DOH HTTP response > will use the smallest TTL in the Answer section of the DNS response as a > maximum. For example, if a HTTP response carries three RRsets with TTLs of > 30, 600 and 300, the HTTP freshness lifetime usually ought to be no more > than 30 seconds (e.g., "Cache-Control: max-age=30"), so that the RRset with > the smallest TTL is not stale when retrieved from cache. > > Again, I think "Typically...will" should transition to an RFC 2119 requirement. This may mean making it explicit that when the HTTP responder cannot calculate the smallest TTL it should use cache-control methods to limit caching. > This assures that none of the RRsets contained within are served stale > from an HTTP cache. > > If the DNS response has no records in the Answer section, and the DNS > response has an SOA record in the Authority section, the response freshness > lifetime typically ought not be greater than the MINIMUM field from that > SOA record (see {{RFC2308}}). > > 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. > I'm concerned about the use of these with responses that contain multiple records. If this text is retained, I think it will have to specify how to manage the multiple record case. > > DNS API servers also need to consider caching when generating responses > that are not globally valid. For instance, if a DNS API server customizes a > response based on the client's identity, it would not want to allow global > reuse of that response. This could be accomplished through a variety of > HTTP techniques such as a Cache-Control max-age of 0, or by using the Vary > response header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache > key ({{RFC7234}}, Section 4.1). > > DNS API clients MUST account for the Age response header's value > ({{RFC7234}}) when calculating the DNS TTL of a response. For example, if a > RRset is received with a DNS TTL of 600, but the Age header indicates that > the response has been cached for 250 seconds, the remaining lifetime of the > RRset is 350 seconds. > > DNS API clients that encounter stale responses (either because the HTTP > freshness lifetime has passed, or because one or more RRset's lifetime has > passed) can request a fresh copy by using the "no-cache" request cache > control directive ({{RFC7234}}, Section 5.2.1.4) and similar controls. Note > that some caches might not honour these directives, depending upon their > configuration. > > Should a DNS API client consider such a response as equivalent to SERVFAIL? > HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as > revalidation provides only a bandwidth benefit and DNS transactions are > normally latency bound. Furthermore, the HTTP response headers that enable > revalidation (such as "Last-Modified" and "Etag") are often fairly large > when compared to the overall DNS response size, and have a variable nature > that creates constant pressure on the HTTP/2 compression dictionary > {{RFC7541}}. Other types of DNS data, such as zone transfers, may be larger > and benefit more from revalidation. > > I would have, perhaps naively, expected zone transfers to be the result of POSTs rather than GETs. Which types of results can be be retrieved by each might be useful to lay out somewhere, just to forestall confusion like mine. thanks, Ted > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --00000000000001f2aa056bba9cac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

Some comments in-line, thanks for= the text.

On = Mon, May 7, 2018 at 5:10 PM, Mark Nottingham <mnot@mnot.net> wr= ote:
On 3 May 2018, at 8= :23 am, Paul Hoffman <paul.hof= fman@icann.org> wrote:
>
> I'm going to re-up this here on the list. Please see the discussio= n on
>=C2=A0 =C2=A0https://github.com= /dohwg/draft-ietf-doh-dns-over-https/issues/153
>
> It would be handy if people who disagree with each other offer text *o= n the list*, not pull requests, specifying what they want the text in the d= raft to say. Then, people to try to come to consensus on this. (Yes, some p= eople are more comfortable with editing pull requests; I feel that this iss= ue is too important to not have the discussion here on the list.)

Proposal:

Cache Interaction {#caching}

A DNS API request can pass through a hierarchy of caches that include both = HTTP and DNS specific caches. HTTP caches are by design generic; that is, t= hey do not understand this protocol. Even if a DNS API client has modified = its cache implementation to be aware of DOH semantics, it does not follow t= hat all upstream caches (for example, in proxies, server-side gateways and = Content Delivery Networks) will be.

I think it would be useful to specify whether we are = talking only about the upstream network caches or the local caches when usi= ng phrases like "pass through" (the use of a local HTTP cache her= e by a DNS API service to furnish data to a DNS client should either be exp= licitly in or out of scope, in other words).
=C2=A0
As a result, DNS API servers need to carefully consider the HTTP caching me= tadata they send in response to GET requests (POST requests are not cacheab= le unless specific response headers are sent; this is not widely implemente= d, and not advised for DOH).

In particular, they are encouraged to assign an explicit freshness lifetime= (Section 4.2 of {{RFC7234}}), since HTTP caches can assign heuristic fresh= ness otherwise (Section x.x of {{RFC7234}}), thereby taking control out of = the hands of the DNS API server.

I agree with other that the use of RFC 2119 language = like SHOULD is appropriate here.=C2=A0 We may want to allow for some varian= ce, but a very clear expectation will help more than "encouraged"= will, at least in my opinion.
=C2=A0
Typically, the assigned freshness lifetime of a given DOH HTTP response wil= l use the smallest TTL in the Answer section of the DNS response as a maxim= um. For example, if a HTTP response carries three RRsets with TTLs of 30, 6= 00 and 300, the HTTP freshness lifetime usually ought to be no more than 30= seconds (e.g., "Cache-Control: max-age=3D30"), so that the RRset= with the smallest TTL is not stale when retrieved from cache.

Again, I think "Typically...will" should tr= ansition to an RFC 2119 requirement.=C2=A0 This may mean making it explicit= that when the HTTP responder cannot calculate the smallest TTL it should u= se cache-control methods to limit caching.
=C2=A0
This assures that none of the RRsets contained within are served stale from= an HTTP cache.

If the DNS response has no records in the Answer section, and the DNS respo= nse has an SOA record in the Authority section, the response freshness life= time typically ought not be greater than the MINIMUM field from that SOA re= cord (see {{RFC2308}}).

The stale-while-revalidate and stale-if-error Cache-Control directives ({{?= RFC5861}}) could be well suited to a DOH implementation when allowed by ser= ver policy. Those mechanisms allow a client, at the server's discretion= , to reuse a cache entry that is no longer fresh.

=
I'm concerned about the use of these with responses that con= tain multiple records.=C2=A0 If this text is retained, I think it will have= to specify how to manage the multiple record case.
=C2=A0

DNS API servers also need to consider caching when generating responses tha= t are not globally valid. For instance, if a DNS API server customizes a re= sponse based on the client's identity, it would not want to allow globa= l reuse of that response. This could be accomplished through a variety of H= TTP techniques such as a Cache-Control max-age of 0, or by using the Vary r= esponse header ({{RFC7231}}, Section 7.1.4) to establish a secondary cache = key ({{RFC7234}}, Section 4.1).

DNS API clients MUST account for the Age response header's value ({{RFC= 7234}}) when calculating the DNS TTL of a response. For example, if a RRset= is received with a DNS TTL of 600, but the Age header indicates that the r= esponse has been cached for 250 seconds, the remaining lifetime of the RRse= t is 350 seconds.

DNS API clients that encounter stale responses (either because the HTTP fre= shness lifetime has passed, or because one or more RRset's lifetime has= passed) can request a fresh copy by using the "no-cache" request= cache control directive ({{RFC7234}}, Section 5.2.1.4) and similar control= s. Note that some caches might not honour these directives, depending upon = their configuration.


Should a DNS API client consider such = a response as equivalent to SERVFAIL?
=C2=A0
HTTP conditional requests ({{RFC7232}}) may be of limited value to DOH, as = revalidation provides only a bandwidth benefit and DNS transactions are nor= mally latency bound. Furthermore, the HTTP response headers that enable rev= alidation (such as "Last-Modified" and "Etag") are ofte= n fairly large when compared to the overall DNS response size, and have a v= ariable nature that creates constant pressure on the HTTP/2 compression dic= tionary {{RFC7541}}. Other types of DNS data, such as zone transfers, may b= e larger and benefit more from revalidation.

I would have, perhaps naively, expected zone transfer= s to be the result of POSTs rather than GETs.=C2=A0 Which types of results = can be be retrieved by each might be useful to lay out somewhere, just to f= orestall confusion like mine.

thanks,

T= ed

=C2=A0

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

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

--00000000000001f2aa056bba9cac-- From nobody Tue May 8 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 ABBE112D7F7 for ; Tue, 8 May 2018 17:22:25 -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 5Rtrx_-HBkTo for ; Tue, 8 May 2018 17:22:23 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0DF12426E for ; Tue, 8 May 2018 17:22:23 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id m11-v6so32030224otf.3 for ; Tue, 08 May 2018 17:22:23 -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=ATFbr5OroE3m4YGvzc6CBo+yIPC66q+Aeba4usIIQNA=; b=uRdK52RnvbxpljnmqrtBxMGm6hHhWHroBFW9iH31PTqKitL5diVp68AlrDDPDLvvp0 W0ILcge1AdNtHaLAaJjQE27pZNlgGoAnSiZp6ZGqsLjqWeXuZ9Jp1iv0zDjqcQzkvRJ2 Wetv3jTDX18COlg8Jn6DQcZ6evpndUqyXtwWP+BwpjqUzvJ3fZKk/Vb5yTOvgsrkJpB+ VFk4229RHJRQHff1x4P8lUw3xY/Q4mYcEaXt8F1u49He1z1Qz2rf5wzqFxRxm7i0rA44 QhisbDfERsrzwaMf8b9Uii1EFhs5H+Px7usAwD+7V0qWVkkG49YPddnmxr7Lnwx0ZKw4 N5fA== 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=ATFbr5OroE3m4YGvzc6CBo+yIPC66q+Aeba4usIIQNA=; b=iduspZbUI/sQx5uXdynQWK0ydudIDQu6pvPBczEp2FAzor3hL9fyYwal+z0r75xGhq Ac57YOJVfqzt7mar04B8r0zUzZhXjUxQ94sUqaF9idW3cB0Gi0VtSlBJmbh2Yqv4R8gy ZVi2a4DMy+ikbP52Oa3Woun9/FDuqUv5LoXabeUN6Kbc3CZRZxpAgfUItnezybTH7z+s 3+a2Qxp38omUchxYQMzCNJHt5Dke3yGcmJsF8zUvHkZIqLYtAPoqpOx5sFa4tHMLlWXz DYw/OeOTDoCTfHndCt16BGkgoTWNtQYbslHXGSkc2Mp1RoOjI9id/K2uWFLPhZeDZv/e p4xQ== X-Gm-Message-State: ALQs6tDpNEo+LqgSFGnSq4D1ECO86w91FMnsEPF5JGyzk859AEFGxsYW hAHSbb/thllpvjWA1ZSThkxfnG39OR0o0tz7ibs= X-Google-Smtp-Source: AB8JxZq5CzwpaGG7THSxP/GeOd8iLgPQaDr5ziKxEbg2JcnZda6TxDzYBNAvUcI4eXK6qcK/mmnnl1HmmZZBLvIG/zI= X-Received: by 2002:a9d:72c6:: with SMTP id d6-v6mr17841373otk.392.1525825342950; Tue, 08 May 2018 17:22:22 -0700 (PDT) MIME-Version: 1.0 References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> In-Reply-To: From: Martin Thomson Date: Wed, 09 May 2018 00:22:12 +0000 Message-ID: To: patrick mcmanus Cc: Mark Nottingham , Paul Hoffman , DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 00:22:25 -0000 On Tue, May 8, 2018 at 9:37 PM Patrick McManus wrote: > Comments from you and Martin (and this text suggestion) support changing this from normative language to advice. The other comments favor the more deterministic behavior we currently have. I'm just glad we're having the discussion. There wasn't a lot of debate about this point and now it seems like it's well-litigated. (Beyond my tolerance, but that's OK, I have a short attention span.) In any case, Mark's text is an improvement; with or without the use of 2119 language. I don't like having two sources for the same type of information, but that is the nature of the protocol we're building. I had hoped that we could lean more heavily on DNS, but it seems like DNS folks want to lean more heavily on HTTP mechanisms. That's something to reflect on, perhaps, but not worth more debate. From nobody Fri May 11 02:47: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 E6549127078 for ; Fri, 11 May 2018 02:47:39 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnMuFIF9xmEm for ; Fri, 11 May 2018 02:47:36 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 E2EC312711E for ; Fri, 11 May 2018 02:47:34 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 33262 invoked from network); 11 May 2018 11:47:30 +0200 Received: from agkb104.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.129.104]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 11 May 2018 11:47:30 +0200 To: DoH WG From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl> Date: Fri, 11 May 2018 11:47:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KVd6m164uDNsagzP8Qdqjs29LkqttxVpv" X-WP-MailID: 097579f3655e894f329267d2fe1f6d3f X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000001 [QSLC] Archived-At: Subject: [Doh] DNS API server trust X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 09:47:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KVd6m164uDNsagzP8Qdqjs29LkqttxVpv Content-Type: multipart/mixed; boundary="Le2pvUSa6QWeDxvEfvC0yNXsCcVcVmGfr"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl> Subject: DNS API server trust --Le2pvUSa6QWeDxvEfvC0yNXsCcVcVmGfr Content-Type: multipart/mixed; boundary="------------0F6471C6E07543499E4C4C77" Content-Language: pl This is a multi-part message in MIME format. --------------0F6471C6E07543499E4C4C77 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, There was an interesting discussion on a Github pull request https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 It was discussed whether there should be an absolute requirement which se= rvers the client can use, i.e. the following text: In the absence of DNSSEC information about the authenticity of responses= a DNS API server can give a client invalid data in responses. A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration. This does not guarantee protection against invalid data but reduces the risk. User roryhewitt opposed this wording, He or She argued that usage of MUST= is unsuitable as it is used here to describe policy, not a mechanism. I would side with His / Her. The concern is merely theoretical at the tim= e being as there is currently no other way to obtain a DNS API server other then = manual configuration (the usage of DNS responses obtained by server push is deal= t earlier in the specification). I would claim that concerns "that DOH clie= nts will spray queries to random webservers, or otherwise violate security co= mmon sense." (as Benjamin M. Schwartz put it) are unfounded. The policy should probably be defined after DNS API server discovery will= be standarized. At the very least, I would lower the requirement from MUST to SHOULD here= as trust is an intricate topic. Greetings, Mateusz Jo=C5=84czyk --------------0F6471C6E07543499E4C4C77 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------0F6471C6E07543499E4C4C77-- --Le2pvUSa6QWeDxvEfvC0yNXsCcVcVmGfr-- --KVd6m164uDNsagzP8Qdqjs29LkqttxVpv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa9WawAAoJEPvWWrhhCv7GV4YQAKRPI42JI8K6B3tAqPjYhU+2 /Tx4fSMgbXB50MEc+JeDoVjVAJKtLPv84Tgj28Fb9ScNYl7t3Y6fUp8sHrDojTGB D6k2j57Y8HLrPr3EIr+Qoi0zXjS5GUqVLmR20wdofX7pdxSfOEP4nljc0dhNlz8L Vyjg5Nnkzls9t/XAWP6ZU8l0ASw5BlJo47YgpbxxQOf8mShCyByUAxV93FI1joDi OKzNCi5RI4Pwfr9UC9DpyQFY50NodaeovNKptpaOhc96fNRfCwtc3SYEIjjsl2TM Yoc5W+3s+F9RPFW3O/fV9r2nQ95uFDpSK3UBqTEn4z7S+wSBgDCNwMav80YGhh0K 11l5bjY+GAgr1W3VSJAhQjVsxCeXPXWgf43WZOfHsZTXHUNpQz2pqMJ+of2czGeV G04V6utnvr5zs7p1/o14vAC1wvJJIRJUtJ6b791k89UqQxcnUo4ap2q3t/HId8lr 94UN6pXPkz4WDZXyP0rKr0J4V0IKRXqbAB5FazzjKSuLe88qdn6YX0n3FfU9jBPk jS0VE+9u/M6NatycWlneLbPKwYJsQBef1W//WvREIPN5jaHGqk71ol3tpm22SNVY Zn+IaAlLnjg0IDgcGQmLd39bea4qBA0S0EXd8IWleipa7GeypgwJNHYTdU8yAh0l YxG7VIfhAbARrUElJUvE =/gfN -----END PGP SIGNATURE----- --KVd6m164uDNsagzP8Qdqjs29LkqttxVpv-- From nobody Fri May 11 05:18:15 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AFE12702E for ; Fri, 11 May 2018 05:18:13 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYPrv7BWahK0 for ; Fri, 11 May 2018 05:18:12 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 A1D25120227 for ; Fri, 11 May 2018 05:18:11 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 27609 invoked from network); 11 May 2018 14:18:08 +0200 Received: from agtn205.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.117.205]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 11 May 2018 14:18:08 +0200 To: DoH WG From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl> Date: Fri, 11 May 2018 14:17:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FRC6xaA6BG7cz9RNU7yNxGLAFe9pbJ5t3" X-WP-MailID: ac13c42fb2766d5689848c8d55b52b83 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [ccME] Archived-At: Subject: [Doh] Subsection Server Push: unclear wording X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 12:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FRC6xaA6BG7cz9RNU7yNxGLAFe9pbJ5t3 Content-Type: multipart/mixed; boundary="MlnzEHbe9A7CQGKm1lr2VdFvO1ftWmtdo"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl> Subject: Subsection Server Push: unclear wording --MlnzEHbe9A7CQGKm1lr2VdFvO1ftWmtdo Content-Type: multipart/mixed; boundary="------------BB2F0AA6764645B90AC1C672" Content-Language: pl This is a multi-part message in MIME format. --------------BB2F0AA6764645B90AC1C672 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, The Server Push subsection now reads so: Before using DOH response data for DNS resolution, the client MUST establish that the HTTP request URI may be used for the DOH query. For HTTP requests initiated by the DNS API 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. The first sentence is very misleading. The intention here was supposedly = that the HTTP request URI is trusted by the client, not that it is working. Th= is is clear by reading the commit that introduced the sentence: https://github.com/dohwg/draft-ietf-doh-dns-over-https/commit/2a4b0b8353= 58d3c4517ae8a038bc86dcf0df04d2 Additionally, I do not understand it fully, but to me it seems that the situation described as "the pushed URI is one that the client would have directed the same query to if the client had initiated the request." woul= d be very rare. Suppose that the client connects to example.com, and example.com tries to= push a DNS resolution for foo.com. It seems (as I get it) that the client could = only use the DNS resolution of foo.com when example.com is configured by the c= lient as the chosen DNS API server. So, a pushed DNS resolution could only be u= sed when contacting a HTTP server that at the same time is configured as a DN= S API, which is exceedingly rare. Therefore, it would probably be better to specify that only a configured = DNS API server may push DNS responses. On the other hand, it may happen that the DNS API server pushes additiona= l responses to a DNS query. For example, when the DNS client requests an AA= AA record for milk-and-pie.deviantart.com and it happens to be an alias for www.deviantart.com, the DNS API server may push a DNS resolution for www.deviantart.com. [1] Am I reading the text correctly here? Greetings, Mateusz Jo=C5=84czyk [1] I have to admit I do not know DNS well enough to know whether such se= rver push could be beneficial and when. --------------BB2F0AA6764645B90AC1C672 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------BB2F0AA6764645B90AC1C672-- --MlnzEHbe9A7CQGKm1lr2VdFvO1ftWmtdo-- --FRC6xaA6BG7cz9RNU7yNxGLAFe9pbJ5t3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJa9Yn+AAoJEPvWWrhhCv7GjGUP/2P9dSGqLFXlB+XNH8n3pXmB ezrEHsCejMZ77PqbaSMOA0MKFLNDDzYNtq9xLNd4nQHOOsfIeK6dnYUIzAQPoK5q v9K5xRRUzy0fqGU2adk8QaxEuFP1x/zZs12qEXSl9iJnsKVz/jgFwi77IfNTo6ki hGBAb3eOFQmsPG2rH1hQnqlfQeYeknbdCfGVEsKvkVhK0GtKT6ZHsS+93eSz9kF2 1E8QuJxL6JPFpAKvZxn1VR8Qk2nIUwwCpBoG4mfefmXirQp2BpK9mcOjGxdkYCd5 iXdlCmjLd7iYoL2uYJ4f3+zDKHKm+XSSUOuHirzH/G9BIBn2GqHP31IH0bV1x8ue gl22VMq5io/USoj2YiNkvrRBoEVp7t16Gv2g+ugCkarrxRKkWCkbvvgv5hjP8lpL rQjJNmVgVVavhOCKgyD+IwZr0F/wD+OBEw2Ai6YcljT7QR4Q1swGTSO9M8Rioyus trMd3t6K2URRtuKt8ljUolzBmezQyVEi7bBOEZUJkNCOX8JDpkU2K6QpDwf0QMpV 3pI3OFgLzXI/ez+gszdYfr4yRpOoox/yrg+9LJvvfFfW7V1y18Zct2NRj2H3VPO+ vUKaBMKm7SQXLXCqRH7IuDWpdcPiVxQq48iNXVrUEdWHDlNpERg2bV0GE597j6uB 6VV13kCvtY4JjiVpi2ax =Yq7H -----END PGP SIGNATURE----- --FRC6xaA6BG7cz9RNU7yNxGLAFe9pbJ5t3-- From nobody Fri May 11 07:49: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 175D4127419 for ; Fri, 11 May 2018 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 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_LOW=-0.7, 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 G582dMN3wxak for ; Fri, 11 May 2018 07:49:11 -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 BB1361200C1 for ; Fri, 11 May 2018 07:49:11 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id n202-v6so2340384ita.1 for ; Fri, 11 May 2018 07:49:11 -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=6ShvWhHijB40CWQLl4m7mvMJkrz56/fOJW/50dEf2RQ=; b=Omtaq+C2M149BQuBSLnU19VAxZh+/G2iOTO6T0XWOBugIPNesIQjNDCmkjcE9JGgzM Vd0Xuj0czPepZ2C9Av6oQD8TzjRJVtf9miKPioiC1SK4MSXEMVyxQsfFBVdVVzrG89tW cNEGeDXecqXWh2fEpTaKR8oBhR0+TajbpuBncLUEB+yIhMTgSgLNUsPWtlld87M2zEGU PnHipjG9TmyMs9er3B2C6P/4fopCdSGfXFs3261gTIuMhXI5rFxUVu2vahwGiNMdih09 /WJReYg+xmFpKfc1wJwVuEGogKhnpbZJCl6LnNUU4MhESRL8CIGg0LBzRBLI+qQ/WBh5 5gqA== 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=6ShvWhHijB40CWQLl4m7mvMJkrz56/fOJW/50dEf2RQ=; b=i0Fg3dG+4+osyaEqqzjJ4BC/XhMzVHuDA4bkTsDE+q2jqRzb+RU23nB5e+Uzqj/A3S LGdE8AwK460NQeYm1GQe1kmFNZ71x9XkxcLiH8rUG1ctoD5ls/gW462INWeq5jxcxE4I 6YvJeOEIPNhUzItPKp7PRr5MSKc5+l5wODdTwNsnjZIUcXkvw2Sfr6VXYt2LfKaA8fIr uFcs3223Tix1aUr3/7iY3jwqXADq6V77jw08peAMPoClv6F56gYVRWHe3PaVKz+mxJ3v YCz7Y7nx25j6HrOY2ZQxdB48Dak2g0Yk/VThqGjlYBLxVHdMs/YqrRWFsLZQ9uB6g1VB GWvA== X-Gm-Message-State: ALKqPweZA3+mByJpyEhUKXPsp+ERNhwfUnxHhs/xccqqGXdmAhSuBEI7 +KbftLjfJ3PYTGkS1IOAKuIdBXP0wG1L/NQJVYV3mQ== X-Google-Smtp-Source: AB8JxZoesD81fZwahxHcAR/yP2Ez8H/VtrrX2mA8gB8s9dK6GxKCS9+3VMOPucQ9ngr2osFZd0FVOSokgNnaH2+e+/g= X-Received: by 2002:a24:5091:: with SMTP id m139-v6mr3549713itb.50.1526050150584; Fri, 11 May 2018 07:49:10 -0700 (PDT) MIME-Version: 1.0 References: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl> In-Reply-To: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl> From: Ben Schwartz Date: Fri, 11 May 2018 10:48:58 -0400 Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000002da787056bef3d45" Archived-At: Subject: Re: [Doh] Subsection Server Push: unclear wording X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 14:49:14 -0000 --0000000000002da787056bef3d45 Content-Type: multipart/alternative; boundary="000000000000232e97056bef3d37" --000000000000232e97056bef3d37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2018 at 8:18 AM Mateusz Jo=C5=84czyk wr= ote: > Hello, > The Server Push subsection now reads so: > > Before using DOH response data for DNS resolution, the client MUS= T > establish that the HTTP request URI may be used for the DOH query= . > For > HTTP requests initiated by the DNS API 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. > > The first sentence is very misleading. The intention here was supposedly > that > the HTTP request URI is trusted by the client, not that it is working. > This is > clear by reading the commit that introduced the sentence: > > https://github.com/dohwg/draft-ietf-doh-dns-over-https/commit/2a4b0b83535= 8d3c4517ae8a038bc86dcf0df04d2 Perhaps you are interpreting "may be used" to mean "is functional"? Its meaning here is "is permitted", i.e. permitted by the client configuration. I think that the following sentence makes this clear. > > Additionally, I do not understand it fully, but to me it seems that the > situation described as "the pushed URI is one that the client would have > directed the same query to if the client had initiated the request." woul= d > be > very rare. > > Suppose that the client connects to example.com, and example.com tries to > push a > DNS resolution for foo.com. It seems (as I get it) that the client could > only > use the DNS resolution of foo.com when example.com is configured by the > client > as the chosen DNS API server. So, a pushed DNS resolution could only be > used > when contacting a HTTP server that at the same time is configured as a DN= S > API, > which is exceedingly rare. > > Therefore, it would probably be better to specify that only a configured > DNS API > server may push DNS responses. > > I think that is both the intent and the effect of this text. The final sentence operationalizes the notion of configuration in a way that reduces ambiguity. > > On the other hand, it may happen that the DNS API server pushes additiona= l > responses to a DNS query. For example, when the DNS client requests an AA= AA > record for milk-and-pie.deviantart.com and it happens to be an alias for > www.deviantart.com, the DNS API server may push a DNS resolution for > www.deviantart.com. [1] > > > Am I reading the text correctly here? > > Greetings, > Mateusz Jo=C5=84czyk > > [1] I have to admit I do not know DNS well enough to know whether such > server > push could be beneficial and when. > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000232e97056bef3d37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri= , May 11, 2018 at 8:18 AM Mateusz Jo=C5=84czyk <mat.jonczyk@o2.pl> wrote:
Hello,
The Server Push subsection now reads so:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Before using DOH response data for DNS resoluti= on, the client MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 establish that the HTTP request URI may be used= for the DOH query. For
=C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP requests initiated by the DNS API client t= his is implicit in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 selection of URI. For HTTP server push ({{RFC75= 40}} Section 8.2) extra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 care must be taken to ensure that the pushed UR= I is one that the client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would have directed the same query to if the cl= ient had initiated the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 request.

The first sentence is very misleading. The intention here was supposedly th= at
the HTTP request URI is trusted by the client, not that it is working. This= is
clear by reading the commit that introduced the sentence:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/dohwg/draft-ietf-doh-dns-o= ver-https/commit/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2
<= div>
Perhaps you are interpreting "may be used" to = mean "is functional"?=C2=A0 Its meaning here is "is permitte= d", i.e. permitted by the client configuration.=C2=A0 I think that the= following sentence makes this clear.
=C2=A0

Additionally, I do not understand it fully, but to me it seems that the
situation described as "the pushed URI is one that the client would ha= ve
directed the same query to if the client had initiated the request." w= ould be
very rare.

Suppose that the client connects to example.com, and example.com tries to push a<= br> DNS resolution for foo.com. It seems (as I get it) that the client could only
use the DNS resolution of foo.com when example.com is configured by the client
as the chosen DNS API server. So, a pushed DNS resolution could only be use= d
when contacting a HTTP server that at the same time is configured as a DNS = API,
which is exceedingly rare.

Therefore, it would probably be better to specify that only a configured DN= S API
server may push DNS responses.


I th= ink that is both the intent and the effect of this text.=C2=A0 The final se= ntence operationalizes the notion of configuration in a way that reduces am= biguity.
=C2=A0

On the other hand, it may happen that the DNS API server pushes additional<= br> responses to a DNS query. For example, when the DNS client requests an AAAA=
record for milk-and-pie.deviantart.com and it happens to be an= alias for
= www.deviantart.com, the DNS API server may push a DNS resolution for = www.deviantart.com. [1]


Am I reading the text correctly here?

Greetings,
Mateusz Jo=C5=84czyk

[1] I have to admit I do not know DNS well enough to know whether such serv= er
push could be beneficial and when.
_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--000000000000232e97056bef3d37-- --0000000000002da787056bef3d45 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMQQEYGhiBYHIQuXGiMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MTIxMzE4MDA1OVoXDTE4MDYx MTE4MDA1OVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCzb38j9YDPiL9B55316U80hEufZ/Xvy8yo3b2/Hlg9DlOUS5/g pc/bPV/xjeY3pFTi26OXF+GADcXQNIYesICbjKZ2poqKyPSQPiHJAG8eGcTBacwVu5Iq+1wrWByq IlC5yQKH2symOmoI1tOUt3HmHvx6v6ZiafD8wzlr9q4gc71KMzGw16Syqn6BAlQqN1thbxYyCsLH MyeQHbrKC0SDTAnSuWajoUSwNFzmfOH/LJEdJKtrpqTjQAvuslI5qTUyeCTAi9hT1y5dWjEJ99nq x0flsIls/AK12NL1sd4mDSBiM0kTBTMU/3klX9erlNuhk/fczzOmDRvOJCuR1eC3AgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFMuqGt+svpvW9WjvmA/qH20SyMgEMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCycNlI1x7iQ4DAZIyb qgC1zhK07uA1x51wtkgwww3teP8P/EYOykp2CDJeXV5wVlSDnhDgvLnsBkZgI25QONeyJ4+wWFjU GonKB0FhhPn1/1bluWpkdex89g3v9DTQI25iFe30dMqM7gbAnBfLBqW7CqHJa2JFixEUHA2WP2Sc IcsHqKWD48JzSDoFST2tNdNdu3j4VhgaX+iggDDT4R7IC4rkJXhx4y3hnfVYs8pajDD4vU5ErLhd BBBc25uH+MfvdDYTogj8rstTNBCTkuwE6fct+zE/oT5PY6HSaiUt69Lp+/uRP1ijmmfIu3zFh6ZS 9Ye4z4czWTkTLH3BZ55hMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMQQEYGhiB YHIQuXGiMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCB3bUQxdwTDqg+9ufJCW15I hJuf4EgRhwIUiFcxck4TszAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MTExNDQ5MTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAbUv+ylvhCX6CdABQSBihe0xBj+uql8AvS5Hx/FcP ByNfmHVqIVA1k2SeN+JaUEwCUwSUBcaCtB2TC0zEBPHXDxEEPzmitHlqkLqmitdlI0Vndr/VVMCq gTg2OVD0oWtGllTzgQMGVf2NpjOqELwWodAFS/h7OBDd+tRLVUTmsvdU9JOzOKQzfpLhNQryJpza etY4P5GVxAZ6WeeAxskn2eyrfbXLCWeZ+/ctypEpyV5BSoWUaL3SUFydpXtUA3RrVblk1K15PdHo UWrRCSpexbUgcXpb1hs/ejmarQZTb94Ij29BkCX5BKNS1goGb0devpTx3/aM3PKHXlH1H2V0bA== --0000000000002da787056bef3d45-- From nobody Fri May 11 09:36:43 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 D7A9112E8DF for ; Fri, 11 May 2018 09:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBCpYfCIoJpy for ; Fri, 11 May 2018 09:36:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE021242F7 for ; Fri, 11 May 2018 09:36:40 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4BGWA7U012926; Fri, 11 May 2018 17:36:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Z+xZYcJXgHqjmSH4kuvUPIcqA3fLxBYBA4MIv7tez2A=; b=htY/hs+wQMzSzBYPbahvbzO/69LNK4Vx7rYSUIASQ2KbrEuhAYqBpg8cS1Ojp74AygSF Z7h9IYX+Se84vy/hst8/N2YB4I1FfnwlBPymeJKoVNsIZBhvAoGQLDkVihPKQK2UEwS3 sRRFDeFPW/6IJeY60OIOTK9lvcgETiOlMHA2naq7monugly/QPyz4uTx/55xdKmAIXjw t6N9boE6+4384TnHQ3oqdJHZO4AF6On09H5TTM6mTgk4whlaopVlCzIsn6hfvbhPu6vd yzhs2SdWeL1bhk7Oj+gF/C4ucSiLZ+PdJp0cI/cP787pTRxeOTlCl8cgfVhqDk0qWYHy 2A== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2hvkwtbs0n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 May 2018 17:36:39 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4BGaDuc015650; Fri, 11 May 2018 12:36:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2hs7xwrb40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 May 2018 12:36:38 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 11 May 2018 12:36:37 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Fri, 11 May 2018 12:36:37 -0400 From: "Hewitt, Rory" To: =?utf-8?B?TWF0ZXVzeiBKb8WEY3p5aw==?= , DoH WG Thread-Topic: [Doh] DNS API server trust Thread-Index: AQHT6Q0d2tinDQH0hESb5MHUwz2GD6Qqubiw Date: Fri, 11 May 2018 16:36:36 +0000 Message-ID: References: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl> In-Reply-To: <783722a3-1e08-acd2-c776-309d5745d378@o2.pl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.238] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04B6_01D3E90B.8DB49310" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-11_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=856 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-11_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=792 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805110156 Archived-At: Subject: Re: [Doh] DNS API server trust X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 16:36:42 -0000 ------=_NextPart_000_04B6_01D3E90B.8DB49310 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey Mateusz, Just as an FYI, I'm a he =F0=9F=98=8A Rory -----Original Message----- From: Mateusz Jo=C5=84czyk [mailto:mat.jonczyk@o2.pl]=20 Sent: Friday, May 11, 2018 2:47 AM To: DoH WG Subject: [Doh] DNS API server trust Hello, There was an interesting discussion on a Github pull request https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 It was discussed whether there should be an absolute requirement which = servers the client can use, i.e. the following text: In the absence of DNSSEC information about the authenticity of = responses a DNS API server can give a client invalid data in responses. A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration. This does not guarantee protection against invalid data but reduces the risk. User roryhewitt opposed this wording, He or She argued that usage of = MUST is unsuitable as it is used here to describe policy, not a = mechanism. I would side with His / Her. The concern is merely theoretical at the = time being as there is currently no other way to obtain a DNS API server = other then manual configuration (the usage of DNS responses obtained by = server push is dealt earlier in the specification). I would claim that = concerns "that DOH clients will spray queries to random webservers, or = otherwise violate security common sense." (as Benjamin M. Schwartz put = it) are unfounded. The policy should probably be defined after DNS API server discovery = will be standarized. At the very least, I would lower the requirement from MUST to SHOULD = here as trust is an intricate topic. Greetings, Mateusz Jo=C5=84czyk ------=_NextPart_000_04B6_01D3E90B.8DB49310 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDUxMTE2MzYzNVowIwYJKoZIhvcNAQkEMRYEFP0k0IYX0T2Y4YTfHV5AqGX/ZiEKMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAErW2BHClXF8vDi9fz5BLygRc6XG1HMRAiyV0HbI04q9oidYEPgu76HHvIhj C4pSGYGFVr9PQG/VfHayCv/+Rav6gAf3MNNwW/QNAik6mF4ASajR2KMaa815DIInPmlN3GiKXpFI oZqjgvWxbWVD1BIWiLcLOzxZVf8LJLKpURZdELQb1EcYH1wLwMsqnkwFoYLtB+x0g+qkBJlyo+OF /9RkNYrLxPPGg+4n8u2rs+nDwikttr/qG5e1jF4hn2xQxcN8ACKUHg+Z2PDhi3Losra4lt1Ow1mg 0V9y/+8WFpMVSoWoxqMw2pS7OH8aXVdUl4ZuGTZriD56XHM65HSw1RoAAAAAAAA= ------=_NextPart_000_04B6_01D3E90B.8DB49310-- From nobody Fri May 11 09:51: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 D101D126D05 for ; Fri, 11 May 2018 09:51:26 -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 hH-8OA7TZpvM for ; Fri, 11 May 2018 09:51:24 -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 C67D01242F7 for ; Fri, 11 May 2018 09:51:23 -0700 (PDT) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id EEA283A04B for ; Fri, 11 May 2018 12:51:19 -0400 (EDT) Received: by mail-oi0-f41.google.com with SMTP id v2-v6so5278836oif.3 for ; Fri, 11 May 2018 09:51:19 -0700 (PDT) X-Gm-Message-State: ALKqPwdVWshO/Zj9/mbnbbURgGypVjXj3xcRGUn0hWCgBGDrD87xr1/t n9VXKHJyOWpJAUF+BIpby0e50ZFbxStwb45eLcg= X-Google-Smtp-Source: AB8JxZripaYPxS2HK5qGEIB3cA0bQxpOqne2Y++Ao7835QkX+UxwFL9zmyX5+9IgbSu1x7aMt4WDrtVFgSjgQ1F7UhU= X-Received: by 2002:aca:f388:: with SMTP id r130-v6mr3514724oih.17.1526057479654; Fri, 11 May 2018 09:51:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.138.36 with HTTP; Fri, 11 May 2018 09:51:19 -0700 (PDT) In-Reply-To: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl> References: <8c412ef6-b92f-2547-d813-643e0e6d83e5@o2.pl> From: Patrick McManus Date: Fri, 11 May 2018 18:51:19 +0200 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000fb59c6056bf0f17b" Archived-At: Subject: Re: [Doh] Subsection Server Push: unclear wording X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 16:51:27 -0000 --000000000000fb59c6056bf0f17b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 11, 2018 at 2:17 PM, Mateusz Jo=C5=84czyk w= rote: > Hello, > The Server Push subsection now reads so: > > Before using DOH response data for DNS resolution, the client MUS= T > establish that the HTTP request URI may be used for the DOH query= . > For > HTTP requests initiated by the DNS API 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. > > The first sentence is very misleading. The intention here was supposedly > that > the HTTP request URI is trusted by the client, not that it is working. > This is > clear by reading the commit that introduced the sentence: > https://github.com/dohwg/draft-ietf-doh-dns-over-https/commi > t/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2 > > > Additionally, I do not understand it fully, but to me it seems that the > situation described as "the pushed URI is one that the client would have > directed the same query to if the client had initiated the request." woul= d > be > very rare. > > Its not necessarily rare One way is simply a persistent connection to a recursive resolver has some information it anticipates you would need - and so pushes it. Another possibility is that the recursive resolver is decomposing a DNS answer that contains multiple answers with different TTLS into a multiple HTTP responses with multiple HTTP freshness lifetimes. Yet another use case happens because HTTP supports multiple origins on a single connection. So its likely a CDN or hosting service (like AWS) could host your configured DOH server and also many other origins you are accessing. A pushed DOH entry under those circumstances meet the stated criteria. There are other scenarios as well. There is interest, of course, in updating this with looser criteria. But that's a future effort. > Suppose that the client connects to example.com, and example.com tries to > push a > DNS resolution for foo.com. It seems (as I get it) that the client could > only > use the DNS resolution of foo.com when example.com is configured by the > client > as the chosen DNS API server. close. A pushed DOH exchange contains an HTTP Response (obviously), a DNS Response in the body of the HTTP Response (obviously), and an HTTP Request (less obvious to people new to HTTP push). There are a bunch of reasons for this, but mostly its because HTTP only operates on exchanges (i.e. a request response pair) so parts of the specification fall apart if you don't have a request (e.g. the definition of the Vary response header). So the server makes up a request (known as a PUSH_PROMISE) and a response and pushes them both. The HTTP Request URI mentioned in the text refers to the URI in the pushed request (i.e. the PUSH_PROMISE). So in your example you need to inspect the pushed request URI and if that a DNS API server you would normally use and this is a valid push then you can you use the resolution of foo.com. (valid push is an important part of that - but that's just part of the 7540 machinery.. the tls certificates of the connection you are on dictate whether or not that origin can be pushed on that connection - the origin of the pushed request URI doesn't have to be the same as the SNI, but it does have to be covered by the cert.. SECONDARY_CERTIFICATES/tls-exported-authenticators are a works in progress that might be able to dynamically expand the scope of a connection by adding new certificates to it) > So, a pushed DNS resolution could only be used > when contacting a HTTP server that at the same time is configured as a DN= S > API, > which is exceedingly rare. > > I disagree about the rare part. > Therefore, it would probably be better to specify that only a configured > DNS API > server may push DNS responses. > > The security requirement falls on the recipient imo. > On the other hand, it may happen that the DNS API server pushes additiona= l > responses to a DNS query. For example, when the DNS client requests an AA= AA > record for milk-and-pie.deviantart.com and it happens to be an alias for > www.deviantart.com, the DNS API server may push a DNS resolution for > www.deviantart.com. [1] > > yep - or decomposition as mentioned above is a possibility. > > Am I reading the text correctly here? > > Greetings, > Mateusz Jo=C5=84czyk > > [1] I have to admit I do not know DNS well enough to know whether such > server > push could be beneficial and when. > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --000000000000fb59c6056bf0f17b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 11, 2018 at 2:17 PM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.= pl> wrote:
Hello,
The Server Push subsection now reads so:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Before using DOH response data for DNS resoluti= on, the client MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 establish that the HTTP request URI may be used= for the DOH query. For
=C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTP requests initiated by the DNS API client t= his is implicit in the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 selection of URI. For HTTP server push ({{RFC75= 40}} Section 8.2) extra
=C2=A0 =C2=A0 =C2=A0 =C2=A0 care must be taken to ensure that the pushed UR= I is one that the client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would have directed the same query to if the cl= ient had initiated the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 request.

The first sentence is very misleading. The intention here was supposedly th= at
the HTTP request URI is trusted by the client, not that it is working. This= is
clear by reading the commit that introduced the sentence:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://github.com/dohwg/draft-ietf-doh-= dns-over-https/commit/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2


Additionally, I do not understand it fully, but to me it seems that the
situation described as "the pushed URI is one that the client would ha= ve
directed the same query to if the client had initiated the request." w= ould be
very rare.




Yet another use case happens because HTTP supports multiple origins on a s= ingle connection. So its likely a CDN or hosting service (like AWS) could h= ost your configured DOH server and also many other origins you are accessin= g. A pushed DOH entry under those circumstances meet the stated criteria. T= here are other scenarios as well.

Suppose that the client connects to example.com, and example.com tries to push a<= br> DNS resolution for foo.com. It seems (as I get it) that the client could only
use the DNS resolution of foo.com when example.com is configured by the client
as the chosen DNS API server.

close. A push= ed DOH exchange contains an HTTP Response (obviously), a DNS Response in th= e body of the HTTP Response (obviously), and an HTTP Request (less obvious = to people new to HTTP push). There are a bunch of reasons for this, but mos= tly its because HTTP only operates on exchanges (i.e. a request response pa= ir) so parts of the specification fall apart if you don't have a reques= t (e.g. the definition of the Vary response header). So the server makes up= a request (known as a PUSH_PROMISE) and a response and pushes them both. <= br>

The HTTP Request URI mentioned in the text ref= ers to the URI in the pushed request (i.e. the PUSH_PROMISE).
So in your example you need to inspect the pushed request URI a= nd if that a DNS API server you would normally use and this is a valid push= then you can you use the resolution of foo.com. (valid push is an important part of that - but tha= t's just part of the 7540 machinery.. the tls certificates of the conne= ction you are on dictate whether or not that origin can be pushed on that c= onnection - the origin of the pushed request URI doesn't have to be the= same as the SNI, but it does have to be covered by the cert.. SECONDARY_CE= RTIFICATES/tls-exported-authenticators are a works in progress that mi= ght be able to dynamically expand the scope of a connection by adding new c= ertificates to it)

=C2=A0
So, a pushed DNS resolution could only be used
when contacting a HTTP server that at the same time is configured as a DNS = API,
which is exceedingly rare.

I disagree about the rare part.
=C2=A0<= /div>
Therefore, it would probably be better to specify that only a configured DN= S API
server may push DNS responses.

The security requirement falls on the recipient imo.<= br>

=C2=A0
On the other hand, it may happen that the DNS API server pushes additional<= br> responses to a DNS query. For example, when the DNS client requests an AAAA=
record for milk-and-pie.deviantart.com and it happens to be an= alias for
= www.deviantart.com, the DNS API server may push a DNS resolution for = www.deviantart.com. [1]


yep - or decomposition as mentioned ab= ove is a possibility.
=C2=A0

Am I reading the text correctly here?

Greetings,
Mateusz Jo=C5=84czyk

[1] I have to admit I do not know DNS well enough to know whether such serv= er
push could be beneficial and when.

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


--000000000000fb59c6056bf0f17b-- From nobody Sat May 12 16:24:19 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDAA128954 for ; Sat, 12 May 2018 16:24:17 -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 iYO96WErMIxC for ; Sat, 12 May 2018 16:24:15 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B151241F5 for ; Sat, 12 May 2018 16:24:15 -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.1178.4; Sat, 12 May 2018 16:24:14 -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.1178.000; Sat, 12 May 2018 16:24:14 -0700 From: Paul Hoffman To: Miek Gieben CC: DoH WG Thread-Topic: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? Thread-Index: AQHT5mEMbkO3Y2FrSECwXZLZvhlEfaQmC0KAgAcuAYA= Date: Sat, 12 May 2018 23:24:13 +0000 Message-ID: <71E8902F-9297-45D2-80E0-064EF75D5AFE@icann.org> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <20180508094545.itl6cvpsekzrpxs4@miek.nl> In-Reply-To: <20180508094545.itl6cvpsekzrpxs4@miek.nl> 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: <804E3E1C07FC424F844649B54D9BCB78@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 23:24:17 -0000 On May 8, 2018, at 2:45 AM, Miek Gieben wrote: > I like this text, but is the working-group OK with *not* mentioning DNSSE= C? >=20 > If you only look a the TTL and not the inception and expiry dates of RRSI= Gs you can easily serve BAD data. That's not how I read RFC 4033. It says: 8.1. TTL Values vs. RRSIG Validity Period It is important to note the distinction between a RRset's TTL value and the signature validity period specified by the RRSIG RR covering that RRset. DNSSEC does not change the definition or function of the TTL value, which is intended to maintain database coherency in caches. A caching resolver purges RRsets from its cache no later than the end of the time period specified by the TTL fields of those RRsets, regardless of whether the resolver is security-aware. The inception and expiration fields in the RRSIG RR ([RFC4034]), on the other hand, specify the time period during which the signature can be used to validate the covered RRset. The signatures associated with signed zone data are only valid for the time period specified by these fields in the RRSIG RRs in question. TTL values cannot extend the validity period of signed RRsets in a resolver's cache, but the resolver may use the time remaining before expiration of the signature validity period of a signed RRset as an upper bound for the TTL of the signed RRset and its associated RRSIG RR in the resolver's cache. To me, "may use the time remaining before expiration" does not sound a requ= irement, or even an expectation.=20 --Paul Hoffman= From nobody Sat May 12 16:26:38 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069C1128954 for ; Sat, 12 May 2018 16:26:37 -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 wxm_DKnv6QWf for ; Sat, 12 May 2018 16:26:35 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 3B1171241F5 for ; Sat, 12 May 2018 16:26:35 -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.1178.4; Sat, 12 May 2018 16:26:33 -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.1178.000; Sat, 12 May 2018 16:26:33 -0700 From: Paul Hoffman To: Tony Finch CC: DoH WG Thread-Topic: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? Thread-Index: AQHT5mEMbkO3Y2FrSECwXZLZvhlEfaQmC0KAgAAeyoCABw/cAA== Date: Sat, 12 May 2018 23:26:32 +0000 Message-ID: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <20180508094545.itl6cvpsekzrpxs4@miek.nl> 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: <60560D07A48B0D44872F14D162EED0E7@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 23:26:37 -0000 On May 8, 2018, at 4:35 AM, Tony Finch wrote: >=20 > Miek Gieben wrote: >> [ Quoting in "Re: [Doh] [Ext] Does the HTTP fresh..." ] >>>=20 >>> Cache Interaction {#caching} >>=20 >> I like this text, but is the working-group OK with *not* mentioning DNSS= EC? >>=20 >> If you only look a the TTL and not the inception and expiry dates of RRS= IGs >> you can easily serve BAD data. >=20 > Mark's suggestion is pretty comprehensive in other areas, so I think it > ought to mention RRSIG expiry dates. (The upstream DNS server should have > fixed up the TTLs, but if you're going through the DNS packet to work out > an expiry time you might as well do it properly.) See my previous message about why I don't think discussion of RRSIG expirat= ion time is appropriate for this discussion. > The other possible addition is a reference to draft-ietf-dnsop-serve-stal= e > alongside the HTTP staleness considerations. But serve-stale is still a > draft and you probably don't want to make DoH wait for it. Further, the early discussion of draft-ietf-dnsop-serve-stale in the DNSOP = WG indicates that it is pretty contentious, and we can't predict how the di= scussion will come out. --Paul Hoffman= From nobody Sat May 12 16:31: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 6B585129BBF for ; Sat, 12 May 2018 16:31:49 -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 jUxrl1zAnZ_A for ; Sat, 12 May 2018 16:31:48 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 0A73E1241F5 for ; Sat, 12 May 2018 16:31:48 -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.1178.4; Sat, 12 May 2018 16:31:46 -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.1178.000; Sat, 12 May 2018 16:31:46 -0700 From: Paul Hoffman To: Mark Nottingham CC: DoH WG Thread-Topic: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? Thread-Index: AQHT5mEMbkO3Y2FrSECwXZLZvhlEfaQmKoUAgAAEuACABwwhgA== Date: Sat, 12 May 2018 23:31:46 +0000 Message-ID: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> In-Reply-To: <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> 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] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2018 23:31:49 -0000 On May 8, 2018, at 4:54 AM, Mark Nottingham wrote: > It looks like you're using RFC2119 requirements to bring attention to imp= ortant parts of the specification ("we really mean that this could trip you= up"), rather than stating actual requirements for interoperability. I would like to see the RFC 2119 language for security. That is, if a resol= ver vendor says "eh, I don't see 2119 words here so I won't implement it", = their resolver will cause clients to use data that it would not have gotten= if it had been using DNS-over-port-53. > These MUSTs aren't testable, Agree. > and they may be too confining in some deployments. Such as...? > This stuff really is advice, of the "if it hurts, don't do that" sort -- = not requirements. The 2119 language being suggested is for DNS API servers, and there is no c= oncept of "if it hurts" for them. The hurt comes to their clients. Thus, th= e stronger language is warranted. --Paul Hoffman= From nobody Sun May 13 19:23: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 001661289B0 for ; Sun, 13 May 2018 19:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=uJzes1cJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=icYUjD4D 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 nMaQD592wpRY for ; Sun, 13 May 2018 19:23:02 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F60128954 for ; Sun, 13 May 2018 19:23:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 87B1F24E77; Sun, 13 May 2018 22:23:01 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 13 May 2018 22:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=3o0QyJkacXljXSkM6zMG/Rjwysjzy A8CRQA6+A6GJBw=; b=uJzes1cJ/tFRYHo97SwVruDBGZX5NS+W3aPd0eEUHeQIa 6yF3aOhWasSfIgDoNfv6nUG4UhcEIgj4L+MQUYVzk+KhzamlA2iA3xSd4uxDMtsa i7Wzmc8LTDtE9+Qd3w91xGbTvwdCD0/JXyfucFL+YPSDicTf0XPPa67FcXjH8PMN KjAQkY3wqQzVNdKh9WlmGR3Tr/udRQ4UpaMg6CQtHllGXJU729DtLTmnLN17wYTg E3tRaEyN3a+WU5ZL13hrrkJxePPsBEl1L9on1YJGoSKM+946a31xuUtz2Ia/Pv4l 9FCq1uEejdvSOs8rxuDR0teAuVU7IVR79I7h6UGPw== 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=fm2; bh=3o0QyJ kacXljXSkM6zMG/RjwysjzyA8CRQA6+A6GJBw=; b=icYUjD4DNgaokWYpK6YaIV SAbuKrF6xbJ85uYzu8MC+n7trMqAhBIruXXE3zD+lC1QmfljVDZNNCdp5lzg/+ww GjfzM+8X4UpmcxObg1H1yLOTdxKiwwWf636hEiZylXokmlAZjVPZRs6ITpDtcP/I qHhYXSj6xdCBdN5o9hfViL3QnHwi208CFQLy1wygipLzzbNOvJXFmlN1qa3yvAlf DqUnHwTgJg7RlEEj49Dj/umpnXJdv/0R+wY/EBQhgNxTvpakhAUM00SlOwZLDI1Q pi+df+jizERYVbw2eUiaZTuyXxqEE5bnOpiXMT1aG44/jjh9OPcshZfhvuOEIMWQ == X-ME-Sender: Received: from [192.168.1.25] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id EC3101027B; Sun, 13 May 2018 22:22:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: Date: Mon, 14 May 2018 12:22:57 +1000 Cc: Paul Hoffman , DoH WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <058CD4DD-28F3-44FD-B616-2544EBDB7676@mnot.net> To: Patrick McManus X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 02:23:05 -0000 Sorry, I had a weekend. I'm OK with the text that Patrick incorporated, it's not worth getting = too far into the weeds here. But, to answer a question / explain where = I'm coming from: > On 9 May 2018, at 2:25 am, Patrick McManus = wrote: >=20 >> > Is there another aspect to the question I'm missing? >>=20 >> It looks like you're using RFC2119 requirements to bring attention to = important parts of the specification ("we really mean that this could = trip you up"), rather than stating actual requirements for = interoperability. These MUSTs aren't testable, and they may be too = confining in some deployments. This stuff really is advice, of the "if = it hurts, don't do that" sort -- not requirements. >=20 > I must be misunderstanding what you mean by not testable - the = alignment of expiration information seems pretty observable. And there = is an operational impact to terminal clients without caches (either DNS = or HTTP) which simply want to lookup a record and use it having to retry = to get non-expired info (and the rather large risk of them not trying = and using old data instead). I don't understand how the location of the cache has anything to do with = this. If a client gets a stale response -- as I said, this is very = possible today despite the language in the draft -- they need to be able = to deal with it. If the client wants to act like that's not a = possibility, they're going to have a bad time. > So I guess you can argue that without 2119 language the DOH client and = server can communicate, but without normative provisions constraining = the server you can't interop well with the Internet.. seems 2119 in = scope to me. The style of requirements used doesn't tell consumers what to do when = they're violated, and -- as we've seen many times -- implementers tend = to read too much into them, e.g., refusing messages which violate them, = even though no such thing is specified.=20 In other words, specifying in terms of ideal requirements (e.g., "the = message MUST look like foo") hurts interop. It's much more effective to = specify requirements in terms of producer and consumer behaviours, and = to use those requirements sparingly.=20 E.g., in the previous text, it said: """ The response freshness lifetime MUST NOT be greater than that indicated = by the DNS resource record with the smallest TTL in the response. """ This is better stated as something like: """ The DNS API server MUST NOT generate messages containing DNS resource = records with a HTTP freshness lifetime greater than their smallest DNS = TTL. DNS API clients can retry requests when encountering messages that = violate the requirement above, or use the now-stale DNS records. """ That said, another reason to avoid requirements here is that, as = discussed, there might be future uses for stale responses, but now = they'll be forbidden by something that doesn't really need to be a = requirement, and so the document will have to be updated -- creating = friction against these uses. This is why I prefer something like: """ The DNS API server should typically generate messages containing DNS = resource records with a HTTP freshness lifetime greater than their = smallest DNS TTL. DNS API clients can retry requests when encountering = messages that violate the requirement above, or use the now-stale DNS = records. """ The current text isn't bad, but the SHOULDs are unqualified, and IME = SHOULDs like that just confuse people. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 14 04:15:43 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 4166C12DA16 for ; Mon, 14 May 2018 04:15:41 -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 Q_7t2SDtc3rL for ; Mon, 14 May 2018 04:15:38 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40.csi.cam.ac.uk [131.111.8.140]) (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 B435812DA14 for ; Mon, 14 May 2018 04:15:38 -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]:38724) by ppsw-40.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fIBS4-000y8R-kq (Exim 4.89_2) (return-path ); Mon, 14 May 2018 12:15:36 +0100 Date: Mon, 14 May 2018 12:15:36 +0100 From: Tony Finch To: Paul Hoffman cc: Miek Gieben , DoH WG In-Reply-To: <71E8902F-9297-45D2-80E0-064EF75D5AFE@icann.org> Message-ID: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <20180508094545.itl6cvpsekzrpxs4@miek.nl> <71E8902F-9297-45D2-80E0-064EF75D5AFE@icann.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 11:15:41 -0000 Paul Hoffman wrote: > > To me, "may use the time remaining before expiration" does not sound a > requirement, or even an expectation. RFC 4035, section 5.3.3 If the resolver accepts the RRset as authentic, the validator MUST set the TTL of the RRSIG RR and each RR in the authenticated RRset to a value no greater than the minimum of: o the RRset's TTL as received in the response; o the RRSIG RR's TTL as received in the response; o the value in the RRSIG RR's Original TTL field; and o the difference of the RRSIG RR's Signature Expiration time and the current time. Tony. -- f.anthony.n.finch http://dotat.at/ South Fitzroy: Northerly 4 or 5, occasionally 6 in southeast. Moderate, occasionally rough. Rain at times. Moderate or good. From nobody Mon May 14 06:04: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 AC76F12E034 for ; Mon, 14 May 2018 06:04:00 -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 wteWPDFSj4F3 for ; Mon, 14 May 2018 06:03:59 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357CE12E043 for ; Mon, 14 May 2018 06:03:59 -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.1178.4; Mon, 14 May 2018 06:03:57 -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.1178.000; Mon, 14 May 2018 06:03:57 -0700 From: Paul Hoffman To: Tony Finch , Miek Gieben CC: DoH WG Thread-Topic: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? Thread-Index: AQHT5mEMbkO3Y2FrSECwXZLZvhlEfaQmC0KAgAcuAYCAAlkXAIAAHkQA Date: Mon, 14 May 2018 13:03:56 +0000 Message-ID: <08CC2EF1-62EC-4D88-9C9D-1B7DE4ABE470@icann.org> References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <20180508094545.itl6cvpsekzrpxs4@miek.nl> <71E8902F-9297-45D2-80E0-064EF75D5AFE@icann.org> 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: <2A9BFE57CFF50842999DFBC12A2D1258@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 13:04:01 -0000 On May 14, 2018, at 4:15 AM, Tony Finch wrote: >=20 > Paul Hoffman wrote: >>=20 >> To me, "may use the time remaining before expiration" does not sound a >> requirement, or even an expectation. >=20 > RFC 4035, section 5.3.3 >=20 > If the resolver accepts the RRset as authentic, the validator MUST > set the TTL of the RRSIG RR and each RR in the authenticated RRset to > a value no greater than the minimum of: >=20 > o the RRset's TTL as received in the response; >=20 > o the RRSIG RR's TTL as received in the response; >=20 > o the value in the RRSIG RR's Original TTL field; and >=20 > o the difference of the RRSIG RR's Signature Expiration time and the > current time. Ouch. (Note to HTTP folks: you're not the only ones with RFCs whose text do= es not always line up.) Proposed addition: If the DNS API Server is also Security-Aware Resolver ([RFC4033] Section= 2), the explicit freshness time MUST be set based on [RFC4035] Section 5.3.3= . --Paul Hoffman= From nobody Mon May 14 06:15:38 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BD51270A7 for ; Mon, 14 May 2018 06:15:37 -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 yyrMqpWXIrb6 for ; Mon, 14 May 2018 06:15:34 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 9FD12127078 for ; Mon, 14 May 2018 06:15:34 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:59513) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fIDK8-000pVD-dQ (Exim 4.89_2) (return-path ); Mon, 14 May 2018 14:15:32 +0100 Date: Mon, 14 May 2018 14:15:32 +0100 From: Tony Finch To: Paul Hoffman cc: Miek Gieben , DoH WG In-Reply-To: <08CC2EF1-62EC-4D88-9C9D-1B7DE4ABE470@icann.org> Message-ID: References: <15A1809C-2CA3-4A3B-A5B1-279227C30223@icann.org> <3E34581E-E2DC-48B7-A4AD-6B9FDA418179@icann.org> <31900328-8813-47D3-9F89-0B863CE673B3@mnot.net> <20180508094545.itl6cvpsekzrpxs4@miek.nl> <71E8902F-9297-45D2-80E0-064EF75D5AFE@icann.org> <08CC2EF1-62EC-4D88-9C9D-1B7DE4ABE470@icann.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Doh] [Ext] Does the HTTP freshness lifetime need to match the TTL? X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 13:15:38 -0000 Paul Hoffman wrote: > > Ouch. (Note to HTTP folks: you're not the only ones with RFCs > whose text does not always line up.) I think the 4033 use of lower-case "may" is just a poor choice of informative / descriptive vocab, and it isn't supposed to mean "MAY" but in fact "can" or "might" (depending on context). There aren't any normative requirements in 4033. Tony. -- f.anthony.n.finch http://dotat.at/ fight poverty, oppression, hunger, ignorance, disease, and aggression From nobody Wed May 16 09:58:49 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 5930F124207; Wed, 16 May 2018 09:58:40 -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.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152648992031.31063.335862247086194554@ietfa.amsl.com> Date: Wed, 16 May 2018 09:58:40 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-08.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 16:58:41 -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-08.txt Pages : 18 Date : 2018-05-16 Abstract: This document describes how to make DNS queries over HTTPS. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-08 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 Sat May 19 07:48:14 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7212D892 for ; Sat, 19 May 2018 07:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.209 X-Spam-Level: X-Spam-Status: No, score=-18.209 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_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mP23RxE1OBhB for ; Sat, 19 May 2018 07:48:09 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2029A129515 for ; Sat, 19 May 2018 07:48:08 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id j186-v6so16568790ita.5 for ; Sat, 19 May 2018 07:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+plgiSRambOKtDwNmKa+LK/HfAZvmbquiufvr+EJVUM=; b=HSuLXrTMP8Knt1pcQ6F+ijcngXBDeOMZAtUV97tBLUUS5q5PHVeg54q88A+51dvl// pDK+yhcQoWTMgeSQD1Mk8zJ2LC0Cs65PhhavDBqJpthoto0Sp7IuBB204WMGN+akJs/2 ETV255YeVpH1OizuiXoqjtn2KXCSb3r27AfzznVBXbupGTdnCW19lEOUCXJ5waChwRQx ks1VJpYQzbGro+U5Dd50fVOafF/ZY4bpQMglu6iMAmRLCT8+10LzJy9yapFE1cNLXJCg LS3X8JCiqbpV1LEkk53/wkPclM3LlpggmA3zuPOB7IpLLQ8/WF/gC36VeIJBdDDZPj3g eFPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+plgiSRambOKtDwNmKa+LK/HfAZvmbquiufvr+EJVUM=; b=mtyuKhpj3QT+xGXiEUB816AgohLMDJYoP2d0Xiif3+xuyc0+y8ApwoVASrMU3rGBc7 JcHrpU2UsCD2WcZVgUrACZGTlvquFkgb4po28QTfjYXX0n8kLy3fs76C/OVztIbdZUoY TNkjb8Sg3P8apXyppYlJubyTChQkgX8Un3O6O50qlaoSGx0pySZ31T6tiNjpq/oipV+4 eWivGkbB6rPLmD9RLJDJDSioG+Nlnr02eulRrt6vaQPvXbsSNWIekCar26U2+p6rrgnt zJvBNwdGXOq3S0BIieLW1qoPvY4ZyGyMtgLNbiYUSWrZOuNJqVlo7olTkxJxeqCpkYus VtkQ== X-Gm-Message-State: ALKqPwfnz0dNmt6SP8mHKWLYaVcWhODjznadkTyT7+7qtFL5cVA4JtiN dttwnpvGtI73fSVOg6AQfS3TXdgg0/xDkNhwV929dKMYLr8= X-Google-Smtp-Source: AB8JxZp0taI2jFJ9badTcnlVip66Hn+3Kq6ynsQ5o3LMlgQwJJ/PE7zWmUBAyQ5tyOnWuQG9MebG+DL987vfI9KtXHQ= X-Received: by 2002:a24:5091:: with SMTP id m139-v6mr11164777itb.50.1526741287626; Sat, 19 May 2018 07:48:07 -0700 (PDT) MIME-Version: 1.0 From: Ben Schwartz Date: Sat, 19 May 2018 10:47:56 -0400 Message-ID: To: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000002711cb056c902872" Archived-At: Subject: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2018 14:48:11 -0000 --0000000000002711cb056c902872 Content-Type: multipart/alternative; boundary="0000000000001da3f5056c90286f" --0000000000001da3f5056c90286f Content-Type: text/plain; charset="UTF-8" DOH! The Working Group Last Call on draft-ietf-doh-dns-over-https-07 raised an excellent round of discussion. The chairs believe that all issues raised in that period have been satisfactorily addressed, and draft-08 reflects the working group consensus on these questions. However, to ensure that we reach the best possible consensus, we are opening a short Working Group Last Call on this latest draft. Please review the draft: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-08 or the changes https://tools.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-08.txt and attempt to resolve any remaining concerns on the list by Friday May 25th (one week). Sincerely, The Chairs --0000000000001da3f5056c90286f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
DOH!

The Working Group Last Call on draft-ietf-doh-dns-over-https-0= 7 raised an excellent round of discussion.=C2=A0 The chairs believe that al= l issues raised in that period have been satisfactorily addressed, and draf= t-08 reflects the working group consensus on these questions.=C2=A0 However= , to ensure that we reach the best possible consensus, we are opening a sho= rt Working Group Last Call on this latest draft.

Please review the draft:
or the changes
and attempt to resolve any remaining c= oncerns on the list by Friday May 25th (one week).

Sincerely,=
The Chairs
--0000000000001da3f5056c90286f-- --0000000000002711cb056c902872 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 fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCALtxT04Kn4i855RePLuWDN 7WTBlS3M2Ro1iVSZdjt9rjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MTkxNDQ4MDhaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAEvL+rvW0uJDh8UA7X8lOqdUrm0l/WsQ8ivU4qnXr bUjnSB9j73rzQcJw8X7rRAxgbYBs5I/+DZHGUS48oPr6rZiLy9gxpaNNw6Fwc5edwjqlUpI4SWgZ xXagIDuTCuDPhfCxRBRD0kDmLCgTXUdSrrvsicg0GvhxNA256qlkhcmlag6p+ZHFXDyyIPZ7y3Ls KElg6YgFv/wfL2jjzdPSOe4NPFiZLdA6nevwg3acwfZIRQSX+nXnAg3WDMosdi6xm+A08uVDhcFx 7oxvZCVPtZ9kwgVXkIurbgRTeiu1Sdj5TeIlJwGq7ezB3TASHG4pdVmID9uQSUGT0J2MIZX9uA== --0000000000002711cb056c902872-- From nobody Mon May 21 13:41: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 90D0612D881 for ; Mon, 21 May 2018 13:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLyBOz7AN85e for ; Mon, 21 May 2018 13:41:49 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9162D12D885 for ; Mon, 21 May 2018 13:41:49 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w4LKaW97018835 for ; Mon, 21 May 2018 21:41:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=s5U0HIO4KwKCwC79xJcb/pBdkQ/MWnvkiQM45U9l+Ww=; b=J80Gv3RiQhEYoHJ9moy2KZK66RiINaWtDfZxXinG4kEqRYNs4WrV5Pub+240mf3wDwJl cxNE9UT3Ms5QBqzt6FFIZsApPFTcpJEWSFRiDpiPYzRXdFxxe8pGSBd5+majIsGof5A5 Smna1tOO4BD9rD9qyeuYK/dTPmikpWpoWIg5jCwPcN0sn15bszOQJdZY3RuHiqNN9+Ll QJEbjVYejarvbKTbU3vr9cBFFNSi0eoo1piO9JmYzJwxlyPlr2bVcVbBpPXeJ1G+NEvJ GNV5T1pKYQnmlLqyhOCNWM+nQhlbvm0wCScPd5cgJ5kyEX8ZU+A9yjKQJbDmKuAGPODZ mw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2j290cqpbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 21 May 2018 21:41:48 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4LKaW4w017313 for ; Mon, 21 May 2018 16:41:47 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2j2f8u94tg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 21 May 2018 16:41:47 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.27.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 21 May 2018 15:41:46 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1365.000; Mon, 21 May 2018 15:41:46 -0500 From: "Hewitt, Rory" To: DoH WG Thread-Topic: [Doh] WGLC #2 Thread-Index: AQHT74Bupf/j2QbeDU2bbLl5BLZf8aQ6piLw Date: Mon, 21 May 2018 20:41:46 +0000 Message-ID: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.212.173] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0025_01D3F109.757B2240" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210245 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210245 Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 20:41:52 -0000 ------=_NextPart_000_0025_01D3F109.757B2240 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit I know I brought this up in https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and agreed to leave it, but I see that Mateusz subsequently brought it up in https://www.ietf.org/mail-archive/web/doh/current/msg00557.html... I would really like to see Section 4 (Selection of DNS API Server) moved to be within Section 9 (Security Considerations), perhaps as a subsection (9.1: Selection of DNS API Server) and have the normative MUST and SHOULD changed to be non-normative 'must' and 'should'. Specifically, my concern (as voiced in /pull/174) is that I don't believe we should be using normative terms outside of technical implementation details - as I said "typically a MUST/REQUIRED/SHALL specifies an action to take and there will be some obvious consequences for not taking that action (an error thrown). In this case, we're saying "You MUST check that the DNS server you want to connect to is trustworthy" without saying how they should do that. And since there will be no error message from an untrustworthy DNS server, how would they know? It feels like we're taking things that outside of the spec (whether/how to trust a DNS server) and making it part of the spec... " Ben and Patrick may have had valid reasons for disagreeing with me, but as I'm not sure if anyone else saw it, I'd like to be sure it's true consensus. This is the last time I'll bring it up, I swear... Rory ------=_NextPart_000_0025_01D3F109.757B2240 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDUyMTIwNDE0NVowIwYJKoZIhvcNAQkEMRYEFKheCmZvEDsDRPflJniC0vsopsRMMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBADFQFXrx9i22KDklahZ5eONkI1xpmcEnvaWO4hP2eddQJBiDg88SEVT4xG7o XdG0T535njEYIDi5JdCbE/dNFPE3ECqw9JkT9WWhtuuyDKvwpzatcII70vDGF9FokCi2hDPoQzd5 xiusSA/gKEzpKVnbJxepY4VaEWzTlWG8/nOKcG6z2yqXxyZrXXvOb4EBjeJQ8BUb79wNW0wLJ4Or 1NQduHe2YFdhSiAVPqY8MI11tbiWVzyclsLuWhUq9JreNPMpeXto1STDJAim0BDRYuaN1//RMCFW JwgP+8DDER6kt8bbCP5hCJTFPKU15ExWk7og9WRVbG+M8xkgq2q0V/8AAAAAAAA= ------=_NextPart_000_0025_01D3F109.757B2240-- From nobody Tue May 22 03:17:22 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD00126B72 for ; Tue, 22 May 2018 03:17:20 -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, FREEMAIL_FROM=0.001, 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 uA4K0LeXDwJf for ; Tue, 22 May 2018 03:17:18 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 F0EE2126CBF for ; Tue, 22 May 2018 03:17:17 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 35871 invoked from network); 22 May 2018 12:17:13 +0200 Received: from acnx253.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.177.253]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 May 2018 12:17:13 +0200 To: "Hewitt, Rory" , DoH WG References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <7606e9fa-7a11-34d0-b6a4-ae230dd3ac52@o2.pl> Date: Tue, 22 May 2018 12:16:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TinrPcs7AGfN6gQa3hXmDTWSO4ToJ3qYi" X-WP-MailID: 36a9fa7fe338277856a0113558181505 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [cbPk] Archived-At: Subject: [Doh] "Selection of DNS API Server": make it a copy of "Security Considerations" X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 10:17:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TinrPcs7AGfN6gQa3hXmDTWSO4ToJ3qYi Content-Type: multipart/mixed; boundary="ycd3QZkJJ4VmbougHwScBRN3iuaPFOkX2"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: "Hewitt, Rory" , DoH WG Message-ID: <7606e9fa-7a11-34d0-b6a4-ae230dd3ac52@o2.pl> Subject: "Selection of DNS API Server": make it a copy of "Security Considerations" References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> In-Reply-To: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> --ycd3QZkJJ4VmbougHwScBRN3iuaPFOkX2 Content-Type: multipart/mixed; boundary="------------45851A3B5A3A3669AAEE14E2" Content-Language: pl This is a multi-part message in MIME format. --------------45851A3B5A3A3669AAEE14E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 21.05.2018 o=C2=A022:41, Hewitt, Rory pisze: > I know I brought this up in=20 > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and agr= eed to=20 > leave it, but I see that Mateusz subsequently brought it up in=20 > https://www.ietf.org/mail-archive/web/doh/current/msg00557.html... >=20 > I would really like to see Section 4 (Selection of DNS API Server) move= d to be=20 > within Section 9 (Security Considerations), perhaps as a subsection (9.= 1:=20 > Selection of DNS API Server)=20 Hello, I was also planning to bring up something about these sections but I was = busy. Both section "Security Considerations" and section "Selection of DNS API = Server" specify which server the client may use but in a different way: [...] the client MUST establish that the HTTP request URI is a trusted service for the DOH query, in other words, a DNS API client MUST only use a DNS API server that is configured as trustworthy. vs A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration. Such discrepancy is confusing. If there should be a section "Selection of DNS API Server", the text ther= e should be just a repetition of what is said in "Security considerations" = with a reference to "Security considerations". So I would propose the following text for section "Selection of DNS API S= erver": As specified in the section "Security considerations", a client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration. I have sent a corresponding pull request: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/184 Greetings, Mateusz --------------45851A3B5A3A3669AAEE14E2 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------45851A3B5A3A3669AAEE14E2-- --ycd3QZkJJ4VmbougHwScBRN3iuaPFOkX2-- --TinrPcs7AGfN6gQa3hXmDTWSO4ToJ3qYi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbA+4oAAoJEPvWWrhhCv7G894P/1htkmB7mfoZH4fxV694olPL SM21Jp0va3pl76D4CduS0DL0wW4r7sLV390C5UexvNiSn/GZ1ocfSStPWV2ZVytx Z0sg2HmH3fWvY458Z0+JqGhvhtB7pwLKFgpmO8lSLwmqAN2oiEVILP8NlexPGVGR ED1t696qtoWM16fXWHvJNzAt1O32df5l2/cKBu2Z/nN8oHlPWQ385uW4mEVPFrfo gcvRVSN16M6omhhrINtLygYlu3PpD2rJlKttP1iAIDBC2E088P2rDL/6Qx3iUBIM qNKlKwRMFz0OtKBjy0SCeMRpzU0ekJVNZn4p//OaxgAaIBjgjLiZHhHUJNymJ3D5 Jlz1zWQTJGBWBIYt18pJCDNfbWsDN8ZQTNODrRNNGl4SXltMEiAzbtksgAgjkcNy znS2xwvhSvk/6EqeCXqsle1XTT2huuQYNpcRseNiOlN2/iRAaWbR5s3qTUoZcK7P ZGnfCFwHzofEhJnc/t8ke7w2EGpToYwaF3ikWSgwWTT1a1lSlzub/diuLgDhG1r1 k6FS895E9at1Qhs1pMy6naY9jiTpM4iV74yvEO6QCDCE14bBG4H+v5GtdOOPu1eO YXY+XxMdi5/V5t41TnROYG6anec//tVyAu1qlCPOjSdxqsqqfeYJWVaOCqN3apRn VaxjyYvSkOdc32LPQd1W =gBWt -----END PGP SIGNATURE----- --TinrPcs7AGfN6gQa3hXmDTWSO4ToJ3qYi-- From nobody Tue May 22 08:37: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 6CE4C12E894 for ; Tue, 22 May 2018 08:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjFZtl8yHm1e for ; Tue, 22 May 2018 08:37:34 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C2C12741D for ; Tue, 22 May 2018 08:37:34 -0700 (PDT) Received: from [2001:b98:204:102:fffa::] (port=63855) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fL9Lt-0007Tu-3e; Tue, 22 May 2018 16:37:33 +0100 From: Sara Dickinson Message-Id: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> Content-Type: multipart/signed; boundary="Apple-Mail=_85DDB95B-F19B-4A2B-A285-01CBAAFACB26"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 22 May 2018 16:37:23 +0100 In-Reply-To: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> Cc: DoH WG To: "Hewitt, Rory" References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 3 Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 15:37:37 -0000 --Apple-Mail=_85DDB95B-F19B-4A2B-A285-01CBAAFACB26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 May 2018, at 21:41, Hewitt, Rory = wrote: >=20 > I know I brought this up in > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and = agreed to > leave it, but I see that Mateusz subsequently brought it up in > https://www.ietf.org/mail-archive/web/doh/current/msg00557.html... >=20 > I would really like to see Section 4 (Selection of DNS API Server) = moved to be > within Section 9 (Security Considerations), perhaps as a subsection = (9.1: > Selection of DNS API Server) The reason I think it is useful to have Section 4 is that Section 6.3 = (Server Push) discusses which URI=E2=80=99s pushes should be accepted = from and so is implicitly talking about which servers to use. However = _if_ section 4 is moved I think there should at least be a reference in = section 6.3 to Section 9. 2 other comments: 1) I previously asked if this spec required that a DNS API Sever should = only be used if authentication of the TLS connection was successful. I = got conflicting answers from Paul and Martin (=E2=80=98No we can=E2=80=99t= say that=E2=80=99 vs =E2=80=98authentication is critical and = implicit=E2=80=99) and don=E2=80=99t see anything in this version that = resolves this. I know there is other work attempting to address this = issue (and more) but the lack of clarity in this document on the topic = is still an issue for me. I=E2=80=99d still like to see a single = sentence that either - makes clear the requirement (preferable) or - states that this is out of scope 2) =E2=80=9CIf a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client.=E2=80=9D What does authenticity mean here - data integrity or DNSSEC = authentication? If it is the latter I would argue to remove it because = DNSSEC and transport choice are orthogonal. Sara. --Apple-Mail=_85DDB95B-F19B-4A2B-A285-01CBAAFACB26 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEARfKBmwUrVFTxWi2+uOzGhY+Sp0FAlsEOTMACgkQ+uOzGhY+ Sp30/gf/Ts/5oXTlGVC8Rq1peJlZ99usiB/N8l2K2afIGNH44ranQkLAp66bj1TW H45o0m4eXYigiiHm0ghbiMkxYSMo4Sl4+KoaL1XTr05cg2eBf5YkLJg92usxdF+F weqNxzmjtFx0k5iTic57Tqystzh0UDmuqQfqF3fJrQECZwmJdQoDPqHd4Zwwe+6v jQF3HKy2Dp+v216rdxb5vOpFhDw/vgUJJk3s9TBmfacx+QUvIrCHA4mJIobHwmOL m6HKf9BDPFf/JsFczizT5jSbON1rhB7cooBOxFbcdzsukeMrDTrGu0MaPLx0VLyJ QL6f4FknPLqa2YU/NUNN5095A6V9TA== =K4G5 -----END PGP SIGNATURE----- --Apple-Mail=_85DDB95B-F19B-4A2B-A285-01CBAAFACB26-- From nobody Tue May 22 10:29:40 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3569128961 for ; Tue, 22 May 2018 10:29:39 -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, FREEMAIL_FROM=0.001, 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 flAQwtmknz9V for ; Tue, 22 May 2018 10:29:37 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.158]) (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 136021201F8 for ; Tue, 22 May 2018 10:29:36 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 20122 invoked from network); 22 May 2018 19:29:34 +0200 Received: from agsm225.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.90.225]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 22 May 2018 19:29:34 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> Openpgp: preference=signencrypt Message-ID: <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> Date: Tue, 22 May 2018 19:29:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GBrV3V0HorEJC8naajqj8604mmzk9Azla" X-WP-MailID: 5da07bdb2d87ee14e75629eb8e632510 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [gSO3] Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 17:29:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GBrV3V0HorEJC8naajqj8604mmzk9Azla Content-Type: multipart/mixed; boundary="BfaNYpdFgEJbUsgYeYT3x31ndiRvgSswF"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> Subject: Re: [Doh] WGLC #2 References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> --BfaNYpdFgEJbUsgYeYT3x31ndiRvgSswF Content-Type: multipart/mixed; boundary="------------366015C8379EF22B4653E22A" Content-Language: pl This is a multi-part message in MIME format. --------------366015C8379EF22B4653E22A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 22.05.2018 o=C2=A017:37, Sara Dickinson pisze: >=20 >=20 >> On 21 May 2018, at 21:41, Hewitt, Rory wrote: >> >> I know I brought this up in >> https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and ag= reed to >> leave it, but I see that Mateusz subsequently brought it up in >> https://www.ietf.org/mail-archive/web/doh/current/msg00557.html... >> >> I would really like to see Section 4 (Selection of DNS API Server) mov= ed to be >> within Section 9 (Security Considerations), perhaps as a subsection (9= =2E1: >> Selection of DNS API Server) >=20 > The reason I think it is useful to have Section 4 is that Section 6.3 (= Server Push) discusses which URI=E2=80=99s pushes should be accepted from= and so is implicitly talking about which servers to use. However _if_ se= ction 4 is moved I think there should at least be a reference in section = 6.3 to Section 9. I would argue that section 6.3 "Server Push" is poorly written and needs = to be clarified. I have asked several questions about it in the past: https://www.ietf.org/mail-archive/web/doh/current/msg00558.html in order to better understand it. (I would like to thank Patrick McManus = and Ben Schwartz for explanations I received.) I propose that it should be rewritten simply to: A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}} Section 8.2) whose pushed request URI does not match the configured DNS API server. >=20 >=20 > 2 other comments: >=20 > 1) I previously asked if this spec required that a DNS API Sever should= only be used if authentication of the TLS connection was successful. I g= ot conflicting answers from Paul and Martin (=E2=80=98No we can=E2=80=99t= say that=E2=80=99 vs =E2=80=98authentication is critical and implicit=E2= =80=99) and don=E2=80=99t see anything in this version that resolves this= =2E I know there is other work attempting to address this issue (and more= ) but the lack of clarity in this document on the topic is still an issue= for me. I=E2=80=99d still like to see a single sentence that either > - makes clear the requirement (preferable) or > - states that this is out of scope It may happen that the DNS API server is running on a local home router a= nd uses a self-signed certificate. (I have talked about running a local DNS API s= erver on a home router before.) I suppose that in this case the certificate could be supplied as part of = a configuration. >=20 >=20 > 2) =E2=80=9CIf a client of this protocol encounters an HTTP > error after sending a DNS query, and then falls back to a different > DNS retrieval mechanism, doing so can weaken the privacy and > authenticity expected by the user of the client.=E2=80=9D >=20 > What does authenticity mean here - data integrity or DNSSEC authenticat= ion? If it is the latter I would argue to remove it because DNSSEC and tr= ansport choice are orthogonal. I suppose that it means here data integrity: the server can provide bogus= responses to DNS requests and strip DNSSEC information. >=20 > Sara. Greetings, Mateusz --------------366015C8379EF22B4653E22A Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------366015C8379EF22B4653E22A Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------366015C8379EF22B4653E22A-- --BfaNYpdFgEJbUsgYeYT3x31ndiRvgSswF-- --GBrV3V0HorEJC8naajqj8604mmzk9Azla Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbBFN9AAoJEPvWWrhhCv7GzZsQALS1wCRjEenXpfZFHOpl3hvQ QGhZbE21WAIxOv/pE2FNA/xO9h6L0SvUWpvUST/FOuE1f5CjxmaT+icZWYxFyy8S y89F1YFzmkNwyZRnVrO+nwVQKNPkLRFI0eGoV+32pUSfCG93LJ+Rva332e088B9u 6Shfxx7iWO5W7OZAHcHGdNx0KTryRQKwEQ2c5c7HIikjN94QDT82D+HnRubSKTlr Ufm3pPXEsIl9LXATpl2XfiBB27hbp8f75n0S9JwWD9rjmLSDVcbgfU6qktpc/rSX yg8ml0dCCxz4r9VHnMrs/qQ8umjCTyko9CitHwvBpjFDX2Hyy/HObcqCaGPraTjd Ct3q+ZYOWhPVcPZPETVQ7vXmksHmzrTXyqDP3Sn4uxjsdv1d968jlSLjk2QB4qIu oZkM9alESWAgINNNOTYQvKCW9bIIZubrsBGZyfFA8OXjqcqUjWowgszw9wmtPC4d TC4RycY58pdYSnJdQPEyNdbE8vZ8DyQI+OD/HQBzFIh207XPAjaxKTKVmHcZGM9J sWUqSfvUZdl58Kpk/ck+ADkRWB76p6tIAEIL2XZfNEbDUtdzGx/hahSY6J59znxt bf/jIemy1rkzRbtpADlgB+R041q8HlvW+oiW3lC5rre0aoO9SJmMHPyYRDt2VQ+x 3bcf71/VErykt6iQefsg =VsTW -----END PGP SIGNATURE----- --GBrV3V0HorEJC8naajqj8604mmzk9Azla-- From nobody Wed May 23 00:12: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 CAA15124319 for ; Wed, 23 May 2018 00:12:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxNMWPUN-dCD for ; Wed, 23 May 2018 00:12:28 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.145]) (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 227A512DA19 for ; Wed, 23 May 2018 00:12:26 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 15295 invoked from network); 23 May 2018 09:12:23 +0200 Received: from agsm225.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.90.225]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 23 May 2018 09:12:23 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> Openpgp: preference=signencrypt Message-ID: Date: Wed, 23 May 2018 09:12:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="70nJ0SZDRZ7oF4xCMuUtIfIJbuvRNBBVB" X-WP-MailID: cddc77b0ef136fa7d97c6a92b6639ba7 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [QUNk] Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 07:12:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --70nJ0SZDRZ7oF4xCMuUtIfIJbuvRNBBVB Content-Type: multipart/mixed; boundary="TPnjxiG5dolXkfJOxSkSukUrgkkPqvjph"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: Subject: Re: [Doh] WGLC #2 References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> In-Reply-To: <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> --TPnjxiG5dolXkfJOxSkSukUrgkkPqvjph Content-Type: multipart/mixed; boundary="------------DD04B1BDC046400793B27650" Content-Language: pl This is a multi-part message in MIME format. --------------DD04B1BDC046400793B27650 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable W dniu 22.05.2018 o=C2=A019:29, Mateusz Jo=C5=84czyk pisze: > W dniu 22.05.2018 o=C2=A017:37, Sara Dickinson pisze: >> The reason I think it is useful to have Section 4 is that Section 6.3 = (Server Push) discusses which URI=E2=80=99s pushes should be accepted fro= m and so is implicitly talking about which servers to use. However _if_ s= ection 4 is moved I think there should at least be a reference in section= 6.3 to Section 9. >=20 > I would argue that section 6.3 "Server Push" is poorly written and need= s to be > clarified. I have asked several questions about it in the past: > https://www.ietf.org/mail-archive/web/doh/current/msg00558.html > in order to better understand it. (I would like to thank Patrick McManu= s and Ben > Schwartz for explanations I received.) >=20 > I propose that it should be rewritten simply to: >=20 > A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}} > Section 8.2) whose pushed request URI does not match the configured DN= S > API server. >=20 I have received no response, so have sent a pull request: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/185 Greetings, Mateusz Jo=C5=84czyk --------------DD04B1BDC046400793B27650 Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------DD04B1BDC046400793B27650-- --TPnjxiG5dolXkfJOxSkSukUrgkkPqvjph-- --70nJ0SZDRZ7oF4xCMuUtIfIJbuvRNBBVB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbBRRWAAoJEPvWWrhhCv7GpCAP/26VUn8N1ZmIfIQq4X0R3/57 JVxYfFNK6+jXr5KI7VpHhliQ5X5nTiCUewYCRuyGIev/g0UFcdW+LjybFGei+vrz 9V7LsA/nkLyoQ1ggRaLHHkW7cl6ATCvOSacTFOrAg/gS4DJuyLx0pY0YRawL9bpN 4lvNTDwPoVEz7goFXQCIr06urJbut7bdJ50ICZBySOdDqUiTYBYboZmcdQyaDKFz 1G19p1pqwBmFmXFvqziT7fLIxKpIs8bUWA7XtCleAnpiQiAI0OgnXtqwKGCa6ZHD 40hk52+8HRtPRg6xOFgGiqVxte0NiFamE/X54Tk5gWb/aG2697nowxHmokP8YTW1 6eX76k2zkz3y48BTRPGWCDE3SB2h6tKVuhKQmnaIAoPhBGXCLsswcJ3xWT24sdY3 zHm3QLxdbnKCGSVpHuHQNYdvORcS+Mj5mg/2lgC4YYnWDKqc+74XW7fOX1FPvqDk It5DfKUnxXBw7Ap/QpJzjPQ/C63Y5uqEGqztK+BWH1Judzw6ptdBpwfTGPFE05ox bfbVDpdFY5fvnWjzb3UW1kS3oI1mTvZj3dgLwyWyj7U+fyX6xUzydE4xC4kTjO9s WT8gqrLf45IH5fQz0ewistOfRVuXDXzdPgZBhtjH9x7RaqNyOBTdM+r+sB55hXg8 92T9sdGawVU+sKuLY7cl =bbvC -----END PGP SIGNATURE----- --70nJ0SZDRZ7oF4xCMuUtIfIJbuvRNBBVB-- From nobody Wed May 23 02:40: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 4FBBD12DA68 for ; Wed, 23 May 2018 02:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVCq3IEI5Pko for ; Wed, 23 May 2018 02:40:36 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.140]) (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 085E012DA49 for ; Wed, 23 May 2018 02:40:35 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 27883 invoked from network); 23 May 2018 11:40:32 +0200 Received: from agsm225.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.90.225]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 23 May 2018 11:40:32 +0200 To: DoH WG From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> Date: Wed, 23 May 2018 11:40:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hGDx7CwmlFNUMEej5Ifr6nbVp6aO45Lxl" X-WP-MailID: df03ceb466991badfaac68350b07a800 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [0eM0] Archived-At: Subject: [Doh] HTTP/2 and constrained environments X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 09:40:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hGDx7CwmlFNUMEej5Ifr6nbVp6aO45Lxl Content-Type: multipart/mixed; boundary="gQncwtDEi8XinfXis6Ypo5Afifnmnqwus"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> Subject: HTTP/2 and constrained environments --gQncwtDEi8XinfXis6Ypo5Afifnmnqwus Content-Type: multipart/mixed; boundary="------------A5AC7FD5F10181AEB971EE1C" Content-Language: pl This is a multi-part message in MIME format. --------------A5AC7FD5F10181AEB971EE1C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I have been thinking about the possibility of running a DOH API server on= a home router - mostly for resolution of names of local devices. Currently, most (if not a vast majority) of home routers are capable of w= orking as a DNS forwarder. One of my routers (FunBox 2.0, provided by my ISP - Orange) has a DNS ser= ver with the capability to resolve names of local devices. As we all know, IP= s of local devices may be assigned via DHCP, so they change from time to time.= To have static names, it is possible to assign DNS names to MAC addresses so= that irrespectively of the IP address the device gets, it may be resolved by t= he DNS name by the local DNS/DHCP server. Performance in this case would not be critical, as requests would be rare= =2E I am not sure if this is currently supported by dnsmasq. How difficult it would be to implement HTTP/2 on a home router with 8 MB = of flash and 32 MB of RAM? Would it at all be possible? Would it be much mor= e difficult to implement than HTTP/1.0? All of my routers support only HTTP= /1.0 in the management interface. Would it be beneficial to specify that DNS API clients SHOULD support DNS= API servers that only talk HTTP/1.0 or HTTP/1.1? We may ask for input from dnsmasq developers. Greetings, Mateusz Jo=C5=84czyk --------------A5AC7FD5F10181AEB971EE1C Content-Type: application/pgp-keys; name="0xFBD65AB8610AFEC6.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0xFBD65AB8610AFEC6.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (GNU/Linux) mQINBFqMDyQBEAC2VYhOvwXdcGfmMs9amNUFjGFgLixeS2C1uYwaC3tYqjgDQNo/ qDoPh52fExoTMJRqx48qvvY/i6iwia7wOTBxbYCBDqGYxDudjtL41ko8AmbGOSkx Jww5X/2ZAtFjUJxOQjNESFlRscMfDv5vcCvtH7PaJJob4TBZvKxdL4VCDCgEsmOa dTy5hvwv0rjNjohau1y4XfxUDdvOcl6LpWMEezsHGc/PbSHNAKtVht4BZYg66kSE Ahs2rOTN6pnWJVd7ErauehrET2xo2JbO4lAv0nbXmCpPj37ZvURswCeP8PcHoA1Q QKWsCnHU2WeVw+XcvR/hmFMI2QnE6V/ObHAb9bzgjxSYVZRAWVsdNakfT7xhkaeH jEQMVRQYBL6bqrJMFFXyh9YDj+MALjyb5hDG3mUcB4Wg7ylnDRrda+1EVObfszfB Wm2pC9Vz1QUQ4CD88FcmrlC7n2witke3gr38xmiYBzDqi1hRmrSj2WnSRP/s9t+C 8M8SweQ2WuoVBLWUvcULYMzwy6mte0aSA8XV6+02a3VuBjP/6Y8yZUd0aZfAHyPi Rf60WVjYNRSeg27lZ9DJmHjSfZNn1FrtZi3W9Ff6bry/SY9D136qXBQxPYxXQfaG DhVeLUVFQ+NIZ6NEjqrLQ07LEvUW2Qzk2q851/IaXZPtP6swx0gqrpjNrwARAQAB tCRNYXRldXN6IEpvxYRjenlrIDxtYXQuam9uY3p5a0BvMi5wbD6JAj4EEwECACgF AlqMDyQCGwMFCRLMAwAGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEPvWWrhh Cv7Gb0MQAJVIpJ1KAOH6WaT8e65xZulI1jkwGwNp+3bWWc5eLjKUnXtOYpa9oIsU UAqvh/L8MofGtM1V11kSX9dEloyqlqDyNSQk0h52hZxMsCQyzjGOcBAi0zmWGYB4 xu6SXj4LpVpIPW0sogduEOfbC0i7uAIyotHgepQ8RPGmZoXU9bzFCyqZ8kAqwOoC Cx+ccnXtbnlAXQmDb88cIprAU+Elk4k4t7Bpjn2ek4fv35PsvsBdRTq3ADg8sGuq 4KQXhbY53n1tyiab3M88uv6Cv//Ncgx+AqMdXq2AJ7amFsYdvkTC98sx20qk6Cul oHggmCre4MBcDD4S0qDXo5Z9NxVR/e9yUHxGLc5BlNj+FJPO7zwvkmIaMMnMlbyd WVke0FSRAzJaEV/NNZKYctw2wYThdXPiz/y7aKd6/sM1jgPlleQhs3tZAIdjPfFj Gdeeggv668M7GmKl+SEzpeFQ4b0x64XfLfLXX8GP/ArTuxEfJX4L05/Y9w9AJwXC VEwW4q17v8gNsPyVUVEdIroKcve6cgNNSWoxTaYcATePmkKnrAPqfg+6qFM4TuOW myzCLQ1YoUZMxH+ddivDQtlKCp6JgGCzc9YCESxVii0vo8TsHdIAjQ/px9KsuYBm OlKnHXKbj6BsE/pkMMKQg/L415dvKzhLm2qVih7IU16IAtK5b7RpuQINBFqMDyQB EACclVvbzpor4XfU6WLUofqnO3QSTwDuNyoNQaE4GJKEXA+pBw5/D2ruHhj1Bgs6 Qx7G4XL3odzO1xT3Iz6w26ZrxH69hYjeTdT8VW4EoYFvliUvgye2cC01ltYrMYV1 IBXwJqSEAImU0Xb+AItAnHA1NNUUb9wKHvOLrW4Y7Ntoy1tp7Vww2ecAWEIYjcO6 AMoUX8Q6gfVPxVEQv1EpspSwww+x/VlDGEiiYO4Ewm4MMSP4bmxsTmPb/f/K3rv8 30ZCQ5DsU0rzUMG2CkyF45qXVWZ974NqZIeVCTE+liCTU7ARX1bN8VlU/yRs/nP2 ISO0OAAMBKea7slrmu93to9gXNt3LEt+5aVIQdwEwPcqR09vGvTWdRaEQPqgkOJF yiZ0vYAUTwtITyjYxZWJbKJhJFaHpMds9kZLF9bH45SGb64uZrrE2eXTyI3DSeUS 1YvMlJwKGumRTPXIzmVQ5PHiGXr2/9S416W9lBDJeHhmcVOsn+04x5KIxHtqAP3m kMjDBYa0A3ksqD84qUBNuEKkZKgibBbs4qT35oXfkgWJtW+JziZf6LYx4WvRa80V DIIYCcQM6TrpsXIJI+su5qpzON1XJQG2iswY8PJ40pkRI9SmkfTFrHOgiTpwZnI9 saWqJh2ABavtnKZ1CtAY2VA8gmEqQeqs2hjdiNHAmRxR2wARAQABiQIlBBgBAgAP BQJajA8kAhsMBQkSzAMAAAoJEPvWWrhhCv7GhpYP/1tH/Kc35OgWu2lsgJxR9Z49 4q+yYAuu11p0aQidL5utMFiemYHvxh/sJ4vMq65uPQXoQ3vo8lu9YR/p8kEt8jbl jJusw6xQiKA1Cc68xtseiKcUrjmN/rk3csbT+Qj2rZwkgod8v9GlKo6BJXMcKGbH b1GJtLF5HyI1q4j/zfeu7G1gVjGTx8e2OLyuBJp0HlFXWs2vWSMesmZQIBVNyyL9 mmDLEwO4ULK2quF6RYtbvg+2PMyomNAaQB4s1UbXAO87s75hM79iszIzak2am4dE jTx+uYCWpvcw3rRDz7aMs401CphrlMKrWndS5qYcdiS9fvAfu/Jp5KIawpM0tVro jnKWCKHG4UnJIn+RF26+E7bjzE/Q5/NpkMblKD/Y6LHzJWsnLnL1o7MUARU++ztO l2Upofyuj7BSath0N632+XCTXk9m5yeDCl/UzPbP9brIChuwgF7DbkdscM7fkYzk UVRJM45rKOupy5Z03EtAzuT5Z/If3qJPU0txAJsquDohppFsGHrzn/X20nI2LedL nIMUWwLRT4EvdYzsbP6im/7FXps15jaBOreobCaWTWtKtwD2LNI0l9LU9/RF+4Ac gwYu1CerMmdFbSo8ZdnaXlbEHinySUPqKmLHmPgDfxKNhfRDm1jJcGATkHCP80Fw w8Ihl8aSTANkZ3QqXNX2 =3DhwvP -----END PGP PUBLIC KEY BLOCK----- --------------A5AC7FD5F10181AEB971EE1C-- --gQncwtDEi8XinfXis6Ypo5Afifnmnqwus-- --hGDx7CwmlFNUMEej5Ifr6nbVp6aO45Lxl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbBTcPAAoJEPvWWrhhCv7Gb9wP/1smVejlojf/nLexrpDA2HkT d5C/2cNzQmlFmqe2hmShkSHzhc8aAD0UJmM9BdbJwKtmDss4JIsdpQyWSkDlNTTC zruuLdpcx5OpicYrV3K1xzdy3egeNt3f+VyKrQBIOPjtLraa0zmiQ2fx2GyAjruH bRXb+ZjGzotSR0PCEbeywgFMxaqlslvPSNHH5Mt0WsqVr3INGfk/VYakUmZssHI6 qPfkD5Ej3z5k09oqz2Ak1ntafCxph7rSO9ySB4AM/wkz00SL1pvyxEU4Ig9vwjTL XglrRGCurxzPnsiTac9bVVjsif7ZTPrFtWR7kR//hyNl/x+n2aJiusv4bcOh25lz RGbFCrGFcaT0sA7K5QM+gqEixfj4A9OLRptCG+GWtBMrQA6W+Yr6B5Q/ECHMLi9/ Z7LNcY9U1XJwA84A3wTo+iXBt3L+/rn9LhDHM/DcWv2xW6atOreBDwbK6JPE5u3X GbVDYL25x2k2Q7oUkKk/aXAaDl0BAHJEBtMKFF6i+9ZpjDOoEYLKcm49bGf6qigQ IkXM5jSHL05CSlcQXDHa/Sn1A0LnZswLeL40tfdwlbzLYc1L6thAAoD+rvpSzj1U BeCVnWYiYNCa1QECuWOs8hhxAJvhdcg36vq37+TJdshMtd66d8KQtSR+JfHwrRym OpGAZiLIBtA5bie8FV86 =M7lf -----END PGP SIGNATURE----- --hGDx7CwmlFNUMEej5Ifr6nbVp6aO45Lxl-- From nobody Wed May 23 09:18: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 58F01127241 for ; Wed, 23 May 2018 09:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qezWshYiWTBx for ; Wed, 23 May 2018 09:18:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C7512711D for ; Wed, 23 May 2018 09:18:38 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w4NGH0c1008966; Wed, 23 May 2018 17:18:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=lbJoTC0Gdl5SydJqk5w0XBrO9jMQLDHRH6+XxLuvWkg=; b=YzkW/oynqoPXFzCe1DRTzsX+zRGgqP3MJL2S/eLPxJW/PR/4/i7byEu/wBGgBLo7aEQV KjgAXSt0A4TDyy2v716XuRl6lU9dG9kqGpSVXMlgQWjCFfHsyqaKoMx6Rxs0RyGnvdn7 PNBImbYG8AEVt4rEUxU8fRxpjNmAhHBd7qjHDucZTTCfAUgzDXULcp0fo+r6UnbqU/aK Cw0B18LCbgyIo4SLrCMhAMbftwHn/e7ONzbk4LZGqOcq/7ksjF9xHckKY5SabkYQIzJy AwSzqz660NT95p6QTyXjpttlrPb7yksr4lqbN8pAftiEuby3fBUDTeJBaOs54PEaR666 1Q== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2j4u75u20d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 17:18:37 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4NGGjg6014231; Wed, 23 May 2018 12:18:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint4.akamai.com with ESMTP id 2j2f8vt7pq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 May 2018 12:18:36 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.27.103) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 23 May 2018 11:18:35 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.27.103]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.27.103]) with mapi id 15.00.1365.000; Wed, 23 May 2018 11:18:35 -0500 From: "Hewitt, Rory" To: Sara Dickinson CC: DoH WG Thread-Topic: [Doh] WGLC #2 Thread-Index: AQHT74Bupf/j2QbeDU2bbLl5BLZf8aQ6piLwgAGUPYCAAUmG4A== Date: Wed, 23 May 2018 16:18:35 +0000 Message-ID: <189a46786d574c79af469c77717ad624@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.121] Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_003A_01D3F277.05FCA5F0" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230161 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805230161 Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 16:18:42 -0000 ------=_NextPart_000_003A_01D3F277.05FCA5F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > However _if_ section 4 is moved I think there should at least be a = reference in section 6.3 to Section 9. Oh, that sounds like an excellent idea to me - I'd just really prefer to = have all the "security considerations" stuff be in one place (Section 9) = and ideally non-normative. But there should certainly be references to = that section in many other places in the document. Thanks, Rory -----Original Message----- From: Sara Dickinson [mailto:sara@sinodun.com]=20 Sent: Tuesday, May 22, 2018 8:37 AM To: Hewitt, Rory Cc: DoH WG Subject: Re: [Doh] WGLC #2 > On 21 May 2018, at 21:41, Hewitt, Rory = wrote: >=20 > I know I brought this up in > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/174 and=20 > agreed to leave it, but I see that Mateusz subsequently brought it up=20 > in https://www.ietf.org/mail-archive/web/doh/current/msg00557.html... >=20 > I would really like to see Section 4 (Selection of DNS API Server)=20 > moved to be within Section 9 (Security Considerations), perhaps as a = subsection (9.1: > Selection of DNS API Server) The reason I think it is useful to have Section 4 is that Section 6.3 = (Server Push) discusses which URI=E2=80=99s pushes should be accepted = from and so is implicitly talking about which servers to use. However = _if_ section 4 is moved I think there should at least be a reference in = section 6.3 to Section 9. 2 other comments: 1) I previously asked if this spec required that a DNS API Sever should = only be used if authentication of the TLS connection was successful. I = got conflicting answers from Paul and Martin (=E2=80=98No we = can=E2=80=99t say that=E2=80=99 vs =E2=80=98authentication is critical = and implicit=E2=80=99) and don=E2=80=99t see anything in this version = that resolves this. I know there is other work attempting to address = this issue (and more) but the lack of clarity in this document on the = topic is still an issue for me. I=E2=80=99d still like to see a single = sentence that either - makes clear the requirement (preferable) or - states that this is out of scope 2) =E2=80=9CIf a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client.=E2=80=9D What does authenticity mean here - data integrity or DNSSEC = authentication? If it is the latter I would argue to remove it because = DNSSEC and transport choice are orthogonal. Sara. ------=_NextPart_000_003A_01D3F277.05FCA5F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISBDCCA60w ggKVoAMCAQICEHzz/GscXD6OTELtkPAFBCIwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWth bWFpUEtJUm9vdDAeFw0wOTA0MjgxNDQzMjNaFw0yOTA0MjgxNDUzMjJaMBgxFjAUBgNVBAMTDUFr YW1haVBLSVJvb3QwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHg35oORsqSDVtKlXN BH3kTPboZGPKhL6cxaBOAsPMu1icWBeIC+0u/7bPxNOIuToDkx2pVqEAjPpCfgsmv3Xx2UY9wKwj XE3Vu/M0YLSOgA64D/JDSkTb9nSYg2DzPTfH10DoKg/kU0SEt3sa1k2T6Ku3s9tZIon1BJcNFTAG nx+WF8+NQQbLMaR2EzGkVF2RY7HBIXNrjWy5/tN00u7jJbN0hOoYl3oSjhdigsJ+tn0Ge0CcrHId rFZle+C8uiYc8msazzDKCsTMnLdvXt2jWPM1Xc7UgoZ/en4UgmDj871gX8r+CtgOuA/bHLGkP6Dp FikbdxUCPT3XoQletC8pAgMBAAGjgfIwge8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8w HQYDVR0OBBYEFNg9O/P+HDpCd+Bcyi9mE+TaoAUMMBAGCSsGAQQBgjcVAQQDAgEAMIGdBgNVHSAE gZUwgZIwgY8GCSoDBAUGBwgJDzCBgTBYBggrBgEFBQcCAjBMHkoAQQBrAGEAbQBhAGkAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABQAHIAYQBjAHQAaQBjAGUAIABTAHQAYQB0AGUAbQBlAG4AdDAl BggrBgEFBQcCARYZaHR0cDovL2FrYW1haXBraS9jcHMuaHRtbDANBgkqhkiG9w0BAQUFAAOCAQEA NHT0cXtlfszRk0tbIPfDrXOMnvgW+N3NuJxW5ZhYQODM7KRiJQAgqynYhfFwXb0S94nAunGzzIa9 xCEDY6b98WDXM2Rr2bDaIcJS1OxWCH6J87/cEMZQf6gO4veseaveHjTiC4EDeWZ4nyYbUgT+6Rbz 3xsxdfEhze49yLrqCtUYsG3FCrix5y9xLMy0YVMWRzp0T7I34buJCvBIyOsdIMErQQptNpmlRspl 6B7MrV0AYY/FIxh8V3hHLu8HfrMQNsjRy08s9EiuKPe/1CFx5yZQOOt+8sn8EJ1NdXGUYTKBphD7 u/lazncPr6fpcmKidmk6+H8i+9E7o44WpaaV6DCCBjYwggUeoAMCAQICChsbaFcAAAAAAAQwDQYJ KoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJUm9vdDAeFw0wOTA2MDMxMzE2MjFaFw0x OTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2Ft YWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cL kVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN 70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq+A9zFcxABosmmYDCSJ1+B6noMarjHG62 AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN/ianrjc/AKi2vzRETb98qvv3h2GWdif7 nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Npi7+GsYLcmB0b63L02cs9QCXA4oOeawID AQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB+y0jq9nhlSI772zFFdJz4JM vxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgECMCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7 FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz /hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEjMIIBH6CCARugggEXhiJodHRwOi8vYWth bWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWth bWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11 c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBTgYIKwYBBQUHAQEEggFA MIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTBfQWthbWFpUEtJ Um9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWku Y29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNydDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8v L0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNl cnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNl P29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggEBADkq msMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfWaAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6 oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDvNQSSApRMHQ0VYRuMC1HruQexFvqDBoqj J1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjEri+aO0XVBdRaNiZyB50kmhNelgWRPT5O sDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0IMP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv 6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggVMIIG/aADAgECAgoUzWmVAAIACChiMA0GCSqG SIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkx FDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nMB4XDTE3MTAy NjE3MDA0OVoXDTE4MTAyMTE3MDA0OVowazEcMBoGA1UEChMTQWthbWFpIFRlY2hub2xvZ2llczEW MBQGA1UECwwNU1NMX1NGTy1XUFJCNjEQMA4GA1UEAxMHcmhld2l0dDEhMB8GCSqGSIb3DQEJARYS cmhld2l0dEBha2FtYWkuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8ZrLp7uo Bl6EeLP7azlVbvRQ0aGNrgu//+nOZ9aFu2xi3Lx9nfrHuYt+4X3jLD+FEA4AJ+y+cBpzbvfFljAQ kc/fgjCDpZmw+GrERsuFnhPMN9Hjo/CA9POkkbCrvUB/uo/9wUErigv/L0+DBYC7cVWfDBhhc34l zYsFmPGeIQsj0NF+pNUtFMFI1iQ0ie9vl5fQiRo0+xx6Hm0jX1MT0K7zkPSRpkUo4d1FZ3zuKmHn wQXF/02kU4/bqV6zJYqtRTq4tOHkZ9Sc4F9nxeNB0jzazwW7UHn6zhA1L7KR5b1EfESkD1wuLXQc gL8JvhmN8bs69LuGigEOh4J9DaOBUwIDAQABo4IExjCCBMIwCwYDVR0PBAQDAgWgMDMGA1UdJQQs MCoGCCsGAQUFBwMHBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQweAYJKoZIhvcNAQkP BGswaTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNV HQ4EFgQU5/MdpBSthNmvhd34FjPaXo7Q08wwRgYDVR0RBD8wPYEScmhld2l0dEBha2FtYWkuY29t oCcGCisGAQQBgjcUAgOgGQwXcmhld2l0dEBjb3JwLmFrYW1haS5jb20wHwYDVR0jBBgwFoAUB+y0 jq9nhlSI772zFFdJz4JMvxQwggE5BgNVHR8EggEwMIIBLDCCASigggEkoIIBIIYlaHR0cDovL2Fr YW1haXBraS9Ba2FtYWlQS0lJc3N1aW5nLmNybIY7aHR0cDovL2FrYW1haXBraS5kZncwMS5jb3Jw LmFrYW1haS5jb20vQWthbWFpUEtJSXNzdWluZy5jcmyGgblsZGFwOi8vL0NOPUFrYW1haVBLSUlz c3VpbmcsQ049dXNtYTFjYS1wa2kxLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NlcnRpZmljYXRlUmV2 b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAbwGCCsG AQUFBwEBBIIBrjCCAaowWQYIKwYBBQUHMAKGTWh0dHA6Ly9ha2FtYWlwa2kvdXNtYTFjYS1wa2kx LmtlbmRhbGwuY29ycC5ha2FtYWkuY29tX0FrYW1haVBLSUlzc3VpbmcoMikuY3J0MG8GCCsGAQUF BzAChmNodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS91c21hMWNhLXBraTEu a2VuZGFsbC5jb3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwgawGCCsGAQUF BzAChoGfbGRhcDovLy9DTj1Ba2FtYWlQS0lJc3N1aW5nLENOPUFJQSxDTj1QdWJsaWMlMjBLZXkl MjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWZyLERDPWFkc3ZjP2NB Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MC0GCCsG AQUFBzABhiFodHRwOi8vYWthbWFpb2NzcC5ha2FtYWkuY29tL29jc3AwPAYJKwYBBAGCNxUHBC8w LQYlKwYBBAGCNxUIgs7lOoe41C2BhYsHouMhhtIPgUmE5N8FgZD6FAIBZAIBGzBBBgkrBgEEAYI3 FQoENDAyMAoGCCsGAQUFBwMHMAoGCCsGAQUFBwMCMAwGCisGAQQBgjcKAwQwCgYIKwYBBQUHAwQw DQYJKoZIhvcNAQEFBQADggEBAEKrMiilkcM5ZLE4Ge/AbHUdZg4/bk+0kno/x2s+O54/Ul0C+cRY Zbgj8FzIoaCY4IFLg2Rnld9RE66dy8UMiKijLMC9yvmFZQ9Q0yvwj6TwL7NQ7ZAD92M4MnhLN5Ew 4Tzz+U8848BlyZE3S4xhBRLae0HNA/EK78D2BkkhNXGBbX9zzxRwIhBVQy1/0CauetJn4iIUsIfy UUiGbljhPXcd4u7R7DMTB4k29D6K6E1k5erfbZoECiwZGRQkdtkeQP4lQgkYQLDRU0VHV2aaCeiR LpxjRNAQGNe/YTWRmxDCols8jqJX+a7elpgP/ffZiMn3ij0xRuqZk2MaGP40+XQxggOGMIIDggIB ATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJ kiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgoUzWmVAAIACChiMAkG BSsOAwIaBQCgggHvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4 MDUyMzE2MTgzM1owIwYJKoZIhvcNAQkEMRYEFKy9J9rXe5aUx52K6x2ZycggDV7cMHsGCSsGAQQB gjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1haTEU MBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCChTNaZUAAgAI KGIwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/Is ZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1 aW5nAgoUzWmVAAIACChiMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBANphpk3wTzRUJphjAHMtOMi/ToahQu0i6NDd6wnfkiV/dbe/g9NvlXLC/Bv6 r+B/po6Av0gwPY2c9hxWIshJ3NtzZOiHcQLhpjcC11w8nIgNTHDjxiNz9YPIQu/kaZk06GEuG80g jFrdujfg3wG9rGOiCKu2arfLZrytbOcPA9dyh5o+/QajPdx+pK4mMLQ7WSsYwWY9e9BBkOmJ2hgh gqx0liLamHTBbfzjm5ko9VJdcK73KjhaS09yEsZuaiANDfphh0xYvyR17bGoUErzGFnI0zv05xr7 OyY+eRBmBBLa3kpAIOrVqZsctzWCRG5ZrdD28orfRaBBOb66CyYXC+wAAAAAAAA= ------=_NextPart_000_003A_01D3F277.05FCA5F0-- From nobody Wed May 23 14:13: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 E6F9112D7E6 for ; Wed, 23 May 2018 14:13:26 -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 thEmtmvbZnR5 for ; Wed, 23 May 2018 14:13:25 -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 176CE129C51 for ; Wed, 23 May 2018 14:13:25 -0700 (PDT) Received: from mail-ot0-f175.google.com (mail-ot0-f175.google.com [74.125.82.175]) by linode64.ducksong.com (Postfix) with ESMTPSA id 47F1C3A043 for ; Wed, 23 May 2018 17:13:24 -0400 (EDT) Received: by mail-ot0-f175.google.com with SMTP id l22-v6so26934417otj.0 for ; Wed, 23 May 2018 14:13:24 -0700 (PDT) X-Gm-Message-State: ALKqPweyETjH1dkUZebOxa5fz+OHe88oXq8VE9NiRN5eSJYMt2ygVNYb z+Bh3PylNaPGLNAMITh2FCp1lFroIoOMW6sSPtc= X-Google-Smtp-Source: AB8JxZoMgocgoukCeJ8eX812haXuc14F1TIVFjlG66mtTXnnxCcY+44Sz5htHwOi3EXNA7KUIauOx+sG8BEXkM9Uf6c= X-Received: by 2002:a9d:4181:: with SMTP id p1-v6mr3078078ote.2.1527110004043; Wed, 23 May 2018 14:13:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:13:23 -0700 (PDT) In-Reply-To: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> References: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> From: Patrick McManus Date: Wed, 23 May 2018 17:13:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000052f5ed056ce601de" Archived-At: Subject: Re: [Doh] HTTP/2 and constrained environments X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:13:27 -0000 --00000000000052f5ed056ce601de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 23, 2018 at 5:40 AM, Mateusz Jo=C5=84czyk w= rote: > > How difficult it would be to implement HTTP/2 on a home router with 8 MB = of > flash and 32 MB of RAM? Would it at all be possible? no problem really. HTTP/2 provides a number of mechanisms for either peer to scale things down (e.g.reducing state in the compression dictionary, limiting the number of outstanding streams , small flow control windows, etc ). searching for nginx and dd-wrt yields lots of howto's https://www.dd-wrt.com/phpBB2/viewtopic.php?t=3D312701&sid=3Ddfc6638ad8a57c= 7d3540d4b3aae828d3 .. nginx has http/2 support. > Would it be much more > difficult to implement than HTTP/1.0? All of my routers support only > HTTP/1.0 in > the management interface. > > I'm just speculating, but I suspect that has more to do with https and the challenges of provisioning certs on that kind of device than anything else. > Would it be beneficial to specify that DNS API clients SHOULD support DNS > API > servers that only talk HTTP/1.0 or HTTP/1.1? > > imo we shouldn't be explicitly encouraging older protocols. --00000000000052f5ed056ce601de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 5:40 AM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.= pl> wrote:

How difficult it would be to implement HTTP/2 on a home router with 8 MB of=
flash and 32 MB of RAM? Would it at all be possible?

=
no problem really. HTTP/2 provides a number of mechanisms for ei= ther peer to scale things down (e.g.reducing state in the compression dicti= onary, limiting the number of outstanding streams , small flow control wind= ows, etc ).

searching for nginx and dd-wrt yields = lots of howto's https://www.dd-wrt.c= om/phpBB2/viewtopic.php?t=3D312701&sid=3Ddfc6638ad8a57c7d3540d4b3aae828= d3=C2=A0 .. nginx has http/2 support.
=C2=A0
Would it be much more
difficult to implement than HTTP/1.0? All of my routers support only HTTP/1= .0 in
the management interface.


I'm just speculating, but I suspec= t that has more to do with https and the challenges of provisioning certs o= n that kind of device than anything else.
=C2=A0
Would it be beneficial to specify that DNS API clients SHOULD support DNS A= PI
servers that only talk HTTP/1.0 or HTTP/1.1?


imo we shouldn't be explicitly enc= ouraging older protocols.



--00000000000052f5ed056ce601de-- From nobody Wed May 23 14:44: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 2F77212D77C for ; Wed, 23 May 2018 14:44:44 -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 in8LWcs9X0HY for ; Wed, 23 May 2018 14:44:42 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5AB127010 for ; Wed, 23 May 2018 14:44:42 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id BFDFA3A043 for ; Wed, 23 May 2018 17:44:40 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id y15-v6so20875204oia.13 for ; Wed, 23 May 2018 14:44:40 -0700 (PDT) X-Gm-Message-State: ALKqPwefBFN2qK6LDAlDAGGWJnzk80Xpd81E8G9N/GAID2AwKm3kydhS RY+5UayDbBuZEsbOebvEeln+rg5BPk7oUDqzoRk= X-Google-Smtp-Source: AB8JxZptqgoe+ASv55ylhfyBmLBkLvNZkhb9RE+Ku8wQonIqNJTQOxpy+L1RFmLRtTVDbRM0bYc0hczB8YB8TDwfVdk= X-Received: by 2002:aca:cd0b:: with SMTP id d11-v6mr2386422oig.337.1527111880474; Wed, 23 May 2018 14:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:44:39 -0700 (PDT) In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> From: Patrick McManus Date: Wed, 23 May 2018 17:44:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: "Hewitt, Rory" , DoH WG Content-Type: multipart/alternative; boundary="0000000000002b07a3056ce671f3" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:44:44 -0000 --0000000000002b07a3056ce671f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson wrote: > > 1) I previously asked if this spec required that a DNS API Sever should > only be used if authentication of the TLS connection was successful. I go= t > conflicting answers from Paul and Martin (=E2=80=98No we can=E2=80=99t sa= y that=E2=80=99 vs > =E2=80=98authentication is critical and implicit=E2=80=99) and don=E2=80= =99t see anything in this > version that resolves this. I know there is other work attempting to > address this issue (and more) but the lack of clarity in this document on > the topic is still an issue for me. I=E2=80=99d still like to see a singl= e sentence > that either > - makes clear the requirement (preferable) or > - states that this is out of scope > > Martin is right - I'm not sure where the confusion originated. Authentication is part of HTTPS. I know dprive went down the road of opportunistic security, but that's not something HTTPS does. (plaintext http:// might, but we're pretty clear about doh steering clear of that.) https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186 does this work? -DNS API client MUST only use a DNS API server that is configured as trustworthy. +DNS API client MUST only use a DNS API server that is configured as +trustworthy. {{RFC2818}} defines how HTTPS verifies the identity of +a connection with the trusted service. --0000000000002b07a3056ce671f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson <= sara@sinodun.com&= gt; wrote:

1) I previously asked if this spec required that a DNS API Sever should onl= y be used if authentication of the TLS connection was successful. I got con= flicting answers from Paul and Martin (=E2=80=98No we can=E2=80=99t say tha= t=E2=80=99 vs =E2=80=98authentication is critical and implicit=E2=80=99) an= d don=E2=80=99t see anything in this version that resolves this. I know the= re is other work attempting to address this issue (and more) but the lack o= f clarity in this document on the topic is still an issue for me. I=E2=80= =99d still like to see a single sentence that either
- makes clear the requirement (preferable) or
- states that this is out of scope


Martin is right - I'm not sure whe= re the confusion originated. Authentication is part of HTTPS. I know dprive= went down the road of opportunistic security, but that's not something= HTTPS does. (plaintext http:// might, but we're pretty clear about doh= steering clear of that.)


<= /div>
does this work?

=C2=A0-DNS API clien= t MUST only use a DNS API server that is configured as trustworthy.
+DNS= API client MUST only use a DNS API server that is configured as
+trustw= orthy. {{RFC2818}} defines how HTTPS verifies the identity of
+a connect= ion with the trusted service.



=C2=A0
--0000000000002b07a3056ce671f3-- From nobody Wed May 23 14:53: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 8299A12D7F0 for ; Wed, 23 May 2018 14:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 CqbTTW5cyiKU for ; Wed, 23 May 2018 14:53:34 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD85912D7E6 for ; Wed, 23 May 2018 14:53:34 -0700 (PDT) Received: from [172.16.25.109] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 180C58B6; Wed, 23 May 2018 17:52:00 -0400 (EDT) From: Tom Pusateri Message-Id: <64EB3BCA-64D2-47DB-8F0E-D323451F0025@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_136F8290-5062-436C-9E3C-69978EE11E5D" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 23 May 2018 17:53:32 -0400 In-Reply-To: Cc: Sara Dickinson , DoH WG , "Hewitt, Rory" To: Patrick McManus References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:53:38 -0000 --Apple-Mail=_136F8290-5062-436C-9E3C-69978EE11E5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 23, 2018, at 5:44 PM, Patrick McManus = wrote: >=20 >=20 >=20 > On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson > wrote: >=20 > 1) I previously asked if this spec required that a DNS API Sever = should only be used if authentication of the TLS connection was = successful. I got conflicting answers from Paul and Martin (=E2=80=98No = we can=E2=80=99t say that=E2=80=99 vs =E2=80=98authentication is = critical and implicit=E2=80=99) and don=E2=80=99t see anything in this = version that resolves this. I know there is other work attempting to = address this issue (and more) but the lack of clarity in this document = on the topic is still an issue for me. I=E2=80=99d still like to see a = single sentence that either > - makes clear the requirement (preferable) or > - states that this is out of scope >=20 >=20 > Martin is right - I'm not sure where the confusion originated. = Authentication is part of HTTPS. I know dprive went down the road of = opportunistic security, but that's not something HTTPS does. (plaintext = http:// might, but we're pretty clear about doh steering clear of that.) >=20 > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186 = >=20 > does this work? >=20 > -DNS API client MUST only use a DNS API server that is configured as = trustworthy. > +DNS API client MUST only use a DNS API server that is configured as > +trustworthy. {{RFC2818}} defines how HTTPS verifies the identity of > +a connection with the trusted service. How do you define trustworthy? This seems like it would vary for = different clients and servers in different environments. Trustworthiness isn=E2=80=99t binary although somewhere along a sliding = scale, it crosses a threshold where you are willing to configure it. But = that threshold is different for each client / user. I don=E2=80=99t think trustworthiness is something the document can = require,. especially with RFC 2119 language. Tom --Apple-Mail=_136F8290-5062-436C-9E3C-69978EE11E5D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 23, 2018, at 5:44 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:



On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson = <sara@sinodun.com> wrote:

1) I previously asked if this spec required that a DNS API Sever should = only be used if authentication of the TLS connection was successful. I = got conflicting answers from Paul and Martin (=E2=80=98No we can=E2=80=99t= say that=E2=80=99 vs =E2=80=98authentication is critical and = implicit=E2=80=99) and don=E2=80=99t see anything in this version that = resolves this. I know there is other work attempting to address this = issue (and more) but the lack of clarity in this document on the topic = is still an issue for me. I=E2=80=99d still like to see a single = sentence that either
- makes clear the requirement (preferable) or
- states that this is out of scope


Martin is right - I'm not sure where the confusion = originated. Authentication is part of HTTPS. I know dprive went down the = road of opportunistic security, but that's not something HTTPS does. = (plaintext http:// might, but we're pretty clear about doh steering = clear of that.)

https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/186=

does this work?

 -DNS API client MUST only use a = DNS API server that is configured as trustworthy.
+DNS API = client MUST only use a DNS API server that is configured as
+trustworthy. {{RFC2818}} defines how HTTPS verifies the = identity of
+a connection with the trusted service.

How do you define trustworthy? This seems like it = would vary for different clients and servers in different = environments.

Trustworthiness = isn=E2=80=99t binary although somewhere along a sliding scale, it = crosses a threshold where you are willing to configure it. But that = threshold is different for each client / user.

I don=E2=80=99t think trustworthiness is something = the document can require,. especially with RFC 2119 = language.

Tom


= --Apple-Mail=_136F8290-5062-436C-9E3C-69978EE11E5D-- From nobody Wed May 23 14:54:06 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFE5127010 for ; Wed, 23 May 2018 14:54:04 -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 zdwCXikIrKXh for ; Wed, 23 May 2018 14:54:02 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id BD25A1201F8 for ; Wed, 23 May 2018 14:54:02 -0700 (PDT) Received: from mail-ot0-f177.google.com (mail-ot0-f177.google.com [74.125.82.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6F5CC3A069 for ; Wed, 23 May 2018 17:54:02 -0400 (EDT) Received: by mail-ot0-f177.google.com with SMTP id h8-v6so27041969otb.2 for ; Wed, 23 May 2018 14:54:02 -0700 (PDT) X-Gm-Message-State: ALKqPwd7iX08fERw0VY+q2gB7Byg71rVqGYuee0ahv7jNN+7UmtpkxyA qs2mAxiqZFhnMu2SSZaRS1AlkyEC909iqjmj7DU= X-Google-Smtp-Source: AB8JxZreEOWAEankpNAEIaJiKOIQHmrGSVT1yFGXS+8j+V3u6Wvo4t2jxvmZvTsC1rIYOtPGB1iCeEkIm+JXSyQwqSs= X-Received: by 2002:a9d:1ba8:: with SMTP id z37-v6mr3120352otd.85.1527112442124; Wed, 23 May 2018 14:54:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:54:01 -0700 (PDT) In-Reply-To: <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> From: Patrick McManus Date: Wed, 23 May 2018 17:54:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: "Hewitt, Rory" , DoH WG Content-Type: multipart/alternative; boundary="000000000000a51f08056ce692de" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:54:05 -0000 --000000000000a51f08056ce692de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson wrote: > > 2) =E2=80=9CIf a client of this protocol encounters an HTTP > error after sending a DNS query, and then falls back to a different > DNS retrieval mechanism, doing so can weaken the privacy and > authenticity expected by the user of the client.=E2=80=9D > > What does authenticity mean here - data integrity or DNSSEC > authentication? If it is the latter I would argue to remove it because > DNSSEC and transport choice are orthogonal. > > I'm not a big fan of that text. What it says is true (essentially - if you don't use HTTPS you don't get the properties of HTTPS), but that's not really much of a security consideration of this protocol. I'm going to propose removing the paragraph. thoughts? --000000000000a51f08056ce692de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 22, 2018 at 11:37 AM, Sara Dickinson <= sara@sinodun.com&= gt; wrote:

2) =E2=80=9CIf a client of this protocol encounters an HTTP
=C2=A0 =C2=A0error after sending a DNS query, and then falls back to a diff= erent
=C2=A0 =C2=A0DNS retrieval mechanism, doing so can weaken the privacy and =C2=A0 =C2=A0authenticity expected by the user of the client.=E2=80=9D

What does authenticity mean here - data integrity or DNSSEC authentication?= If it is the latter I would argue to remove it because DNSSEC and transpor= t choice are orthogonal.


I'm not a big fan of that text. Wh= at it says is true (essentially - if you don't use HTTPS you don't = get the properties of HTTPS), but that's not really much of a security = consideration of this protocol.

I'm going = to propose removing the paragraph. thoughts?

<= br>
=C2=A0

--000000000000a51f08056ce692de-- From nobody Wed May 23 14:57: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 762DA12E8C5 for ; Wed, 23 May 2018 14:57:18 -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 jds1CxaiK9Da for ; Wed, 23 May 2018 14:57:17 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7E12E8C6 for ; Wed, 23 May 2018 14:57:16 -0700 (PDT) Received: from mail-ot0-f177.google.com (mail-ot0-f177.google.com [74.125.82.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8FA2A3A043 for ; Wed, 23 May 2018 17:57:16 -0400 (EDT) Received: by mail-ot0-f177.google.com with SMTP id l22-v6so27059333otj.0 for ; Wed, 23 May 2018 14:57:16 -0700 (PDT) X-Gm-Message-State: ALKqPwc0uOvKlS3Y9ClEsdmHpiS0CpycRKozaGMDBP+ecSPqenZYkz7K wtCEPpLyYAJKmUY/dptaneWlA0LdKGHPuwINtmY= X-Google-Smtp-Source: AB8JxZpDv78dTOkh9+IIqhhBPWwSGXxve8fJIa2JDOopNq0LOJtIcgr1SJycKRyJMSrbJobkYP2my//eEVjmjMJiAbk= X-Received: by 2002:a9d:5014:: with SMTP id a20-v6mr2760097oth.205.1527112636346; Wed, 23 May 2018 14:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:57:15 -0700 (PDT) In-Reply-To: <64EB3BCA-64D2-47DB-8F0E-D323451F0025@bangj.com> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <64EB3BCA-64D2-47DB-8F0E-D323451F0025@bangj.com> From: Patrick McManus Date: Wed, 23 May 2018 17:57:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Tom Pusateri Cc: Patrick McManus , Sara Dickinson , DoH WG , "Hewitt, Rory" Content-Type: multipart/alternative; boundary="00000000000038bbe9056ce69e40" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 21:57:28 -0000 --00000000000038bbe9056ce69e40 Content-Type: text/plain; charset="UTF-8" On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri wrote: > > -DNS API client MUST only use a DNS API server that is configured as > trustworthy. > > > How do you define trustworthy? This seems like it would vary for different > clients and servers in different environments. > that paragraph says you do it through the configuration. That's not being changed here. The addition describes, briefly, that verification of the identity of the trusted service is something HTTPS does. --00000000000038bbe9056ce69e40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri <pusateri@bangj.com= > wrote:

=
=
=C2=A0-DNS API client MUST only use a DNS A= PI server that is configured as trustworthy.

How do you define trustworthy? T= his seems like it would vary for different clients and servers in different= environments.


t= hat paragraph says you do it through the configuration. That's not bein= g changed here.

The addition describes, briefly, = that verification of the identity of the trusted service is something HTTPS= does.


--00000000000038bbe9056ce69e40-- From nobody Wed May 23 15:03:50 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2C512D7F5 for ; Wed, 23 May 2018 15:03:48 -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, HTML_MESSAGE=0.001, 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 S3-QUkjSLJGd for ; Wed, 23 May 2018 15:03:47 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129DA12D7F0 for ; Wed, 23 May 2018 15:03:47 -0700 (PDT) Received: from [172.16.25.109] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id BC92E8C4; Wed, 23 May 2018 18:02:13 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C3B68ACB-77C9-43D4-B902-6B05C5022ECA" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Wed, 23 May 2018 18:03:45 -0400 In-Reply-To: Cc: DoH WG , Sara Dickinson , "Hewitt, Rory" To: Patrick McManus References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <64EB3BCA-64D2-47DB-8F0E-D323451F0025@bangj.com> X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 22:03:49 -0000 --Apple-Mail=_C3B68ACB-77C9-43D4-B902-6B05C5022ECA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 23, 2018, at 5:57 PM, Patrick McManus = wrote: >=20 >=20 >=20 > On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri > wrote: >=20 >> -DNS API client MUST only use a DNS API server that is configured as = trustworthy. >=20 > How do you define trustworthy? This seems like it would vary for = different clients and servers in different environments. >=20 >=20 > that paragraph says you do it through the configuration. That's not = being changed here. But how does an implementor of the spec ensure something is = =E2=80=9Cconfigured as trustworthy=E2=80=9D? All the implementor can do is allow it to be configured. Tom --Apple-Mail=_C3B68ACB-77C9-43D4-B902-6B05C5022ECA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 23, 2018, at 5:57 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:



On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

 -DNS API client MUST only = use a DNS API server that is configured as trustworthy.

How do you define = trustworthy? This seems like it would vary for different clients and = servers in different environments.


that paragraph says you do it through the configuration. = That's not being changed = here.

But how does an implementor of the spec ensure = something is =E2=80=9Cconfigured as trustworthy=E2=80=9D?

All the implementor can do is allow it to be = configured.

Tom


= --Apple-Mail=_C3B68ACB-77C9-43D4-B902-6B05C5022ECA-- From nobody Wed May 23 15:36:54 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA14124D37 for ; Wed, 23 May 2018 15:36:44 -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 ff6XXM5YXyMB for ; Wed, 23 May 2018 15:36:43 -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 8A108127369 for ; Wed, 23 May 2018 15:36:43 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id CCB063A069 for ; Wed, 23 May 2018 18:36:42 -0400 (EDT) Received: by mail-oi0-f49.google.com with SMTP id k5-v6so21018955oiw.0 for ; Wed, 23 May 2018 15:36:42 -0700 (PDT) X-Gm-Message-State: ALKqPwfn297y42WftgBdthIinYzcr7t2UFMCn9ReYPGLRCR2ZycBnFf8 NbwXI9O9ptHTproY6grFZNHpZZyQve7DV+DiWCs= X-Google-Smtp-Source: AB8JxZpPEw9HTbaXRPjzXQq2muEji+TV7AWcrgGtN5xMaRxq5hscxu4CvWgOa34khO6SOIsWo1r5INXwEAEQcKk91LA= X-Received: by 2002:a54:4e8a:: with SMTP id c10-v6mr2460390oiy.155.1527115002450; Wed, 23 May 2018 15:36:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 15:36:41 -0700 (PDT) In-Reply-To: References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <64EB3BCA-64D2-47DB-8F0E-D323451F0025@bangj.com> From: Patrick McManus Date: Wed, 23 May 2018 18:36:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Tom Pusateri Cc: Patrick McManus , DoH WG , Sara Dickinson , "Hewitt, Rory" Content-Type: multipart/alternative; boundary="000000000000409af6056ce72bec" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 22:36:45 -0000 --000000000000409af6056ce72bec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't find the text confusing at all. If you're asking how someone making a configuration decision decides something is trustworthy, that's not in scope here (just as the selection of PKI roots are not in scope for HTTPS). >From the pov of the protocol, a URI is designated as trustworthy via configuration. The explicit point being made here is that URIs discovered in some other fashion are not considered trusted by this spec. On Wed, May 23, 2018 at 6:03 PM, Tom Pusateri wrote: > > > On May 23, 2018, at 5:57 PM, Patrick McManus wrote= : > > > > On Wed, May 23, 2018 at 5:53 PM, Tom Pusateri wrote: > >> >> -DNS API client MUST only use a DNS API server that is configured as >> trustworthy. >> >> >> How do you define trustworthy? This seems like it would vary for >> different clients and servers in different environments. >> > > > that paragraph says you do it through the configuration. That's not being > changed here. > > > But how does an implementor of the spec ensure something is =E2=80=9Cconf= igured as > trustworthy=E2=80=9D? > > All the implementor can do is allow it to be configured. > > Tom > > > --000000000000409af6056ce72bec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't find the text confusing at all. If you= 9;re asking how someone making a configuration decision decides something i= s trustworthy, that's not in scope here (just as the selection of PKI r= oots are not in scope for HTTPS). From the pov of the protocol, a URI is de= signated as trustworthy via configuration. The explicit point being made he= re is that URIs discovered in some other fashion are not considered trusted= by this spec.



On Wed, May 23, 2018 at 6:03 PM, Tom= Pusateri <pusateri@bangj.com> wrote:


On May 23,= 2018, at 5:57 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:


=

On Wed, May 23, 2= 018 at 5:53 PM, Tom Pusateri <pusateri@bangj.com> wrote:

=
=
=C2=A0-DNS API client MUST only use a DNS A= PI server that is configured as trustworthy.

How do you define trustworthy? T= his seems like it would vary for different clients and servers in different= environments.


t= hat paragraph says you do it through the configuration. That's not bein= g changed here.

=
But how does an implementor of the spec ensure something is =E2=80=9Cc= onfigured as trustworthy=E2=80=9D?

All the impleme= ntor can do is allow it to be configured.

Tom


<= /span>

--000000000000409af6056ce72bec-- From nobody Wed May 23 15:41: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 95A3F12D86D for ; Wed, 23 May 2018 15:41:16 -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 EeFqWWrTbqHV for ; Wed, 23 May 2018 15:41:12 -0700 (PDT) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B74212E8E4 for ; Wed, 23 May 2018 15:41:08 -0700 (PDT) Received: by mail-ot0-x231.google.com with SMTP id g7-v6so27141286otj.11 for ; Wed, 23 May 2018 15:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8EheOuRpw4wpXt7x9eulozrlnLfXHQALF/C1lB6dcGQ=; b=fSPQQClr8weswQJ69qBZW3PV8vF+idyjtg3qKJiGKMvT8QvT8Aw4WRORhMEWJwDe6q 7Cu37DSbN6bmVdc43ET0OVpBBHy49XeJoOne6+nYVoGdc6irctw3PGQYR/+zy8gHOY6T FeqA5TKEaPks6W185L7K3W2KM+GgjRW/6PoL47dwPNq1wofiWIbl+TBsD/k6AGwPuTVp V2YtKpOBah2ykRjYwEITEmmuD27blrsDwJNlQeH7j0lFvvlR2i+ibbwyXlP1G6c+TYCQ zxideXigCBc9RLShV2BQYAWYw6uuDXw0U69FppMEaGlHLIGzUxntXNJmEB6VaAs1KL+t Ewnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8EheOuRpw4wpXt7x9eulozrlnLfXHQALF/C1lB6dcGQ=; b=mM8IrG/gXjlT0r9BXdMHhjDlXI3znlyowXnmNK9cpzu3FYn7Kz3fpsUOOepz2JMiY5 vRjhTEWkFX7cfpb6s52UiCEcBGO9n5NFdtV/jPJfHBWJlRye2+IsxmrzIUVjNRik5ezR iaUVzjmQCVO4WnsgiTkqddNP8gN62VyXbMQBg4PFROLJsoUBUj6iblJYorG7Thzs1H1N PNe5xoqq5KgnIP9XnkfivNe7ZczKABvzh4Ki+KtRpMrxtTqruP5fXN4gItnMB6mLr2z3 X8cG5TZ0CO6Wd+OOgKStbzLYXeXeIvfq0k9PK9bTTTQVFRPmEGr5IodJhKu/eRvncDnK /jZw== X-Gm-Message-State: ALKqPwcTs6UZyFLkmXeEUcJ4f2Ixg95ErUjqh7+fhCUlRToWWBl+WCoA 0Z9xy4065HA0YkbWQC7BcImV2pUIbj7s+bmCmlY= X-Google-Smtp-Source: AB8JxZqcmKLM6MbOkLNFAdpp7OJrixAMhJkp7zXUBB4LN0tTRiTUIfvIgtLd25BF3uydZOTlfOuFpF26GCNzpsGhPds= X-Received: by 2002:a9d:354a:: with SMTP id l10-v6mr3210549ote.15.1527115267567; Wed, 23 May 2018 15:41:07 -0700 (PDT) MIME-Version: 1.0 References: <4b620bc5-9445-f3b0-cc3d-2ad2b9ac154a@o2.pl> In-Reply-To: From: Martin Thomson Date: Thu, 24 May 2018 08:40:56 +1000 Message-ID: To: patrick mcmanus Cc: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= , DoH WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Doh] HTTP/2 and constrained environments X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 22:41:24 -0000 See also https://tools.ietf.org/html/draft-montenegro-httpbis-h2ot-00 On Thu, May 24, 2018 at 7:13 AM Patrick McManus wrote: > On Wed, May 23, 2018 at 5:40 AM, Mateusz Jo=C5=84czyk wrote: >> How difficult it would be to implement HTTP/2 on a home router with 8 MB of >> flash and 32 MB of RAM? Would it at all be possible? > no problem really. HTTP/2 provides a number of mechanisms for either peer to scale things down (e.g.reducing state in the compression dictionary, limiting the number of outstanding streams , small flow control windows, etc ). > searching for nginx and dd-wrt yields lots of howto's https://www.dd-wrt.com/phpBB2/viewtopic.php?t=3D312701&sid=3Ddfc6638ad8a57c= 7d3540d4b3aae828d3 .. nginx has http/2 support. >> Would it be much more >> difficult to implement than HTTP/1.0? All of my routers support only HTTP/1..0 in >> the management interface. > I'm just speculating, but I suspect that has more to do with https and the challenges of provisioning certs on that kind of device than anything else. >> Would it be beneficial to specify that DNS API clients SHOULD support DNS API >> servers that only talk HTTP/1.0 or HTTP/1.1? > imo we shouldn't be explicitly encouraging older protocols. > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Wed May 23 15:57: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 A03E012D7F9 for ; Wed, 23 May 2018 15:57:40 -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 ytqLLyFmd2t9 for ; Wed, 23 May 2018 15:57:38 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id B1E7112D7F0 for ; Wed, 23 May 2018 15:57:38 -0700 (PDT) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by linode64.ducksong.com (Postfix) with ESMTPSA id 626D43A043 for ; Wed, 23 May 2018 18:57:38 -0400 (EDT) Received: by mail-ot0-f171.google.com with SMTP id 15-v6so27173604otn.12 for ; Wed, 23 May 2018 15:57:38 -0700 (PDT) X-Gm-Message-State: ALKqPwfdi+FQm1KG8/xnjR05dfDsy1Ofeg+pln69oB7KbBA7Bopd3D5E dMH6wxbkzE6AukEeCXrkrC6LMzEWaO9Rh5B/7Pw= X-Google-Smtp-Source: AB8JxZpBY2k39/Zs7G3XN7bEIiOr0PUl686sIdQUfRG1CEdMx9QQAHkKtJIVW2lvcrCgfgou148foug4TYGgkHSIc3k= X-Received: by 2002:a9d:2c64:: with SMTP id f91-v6mr2878894otb.263.1527116258048; Wed, 23 May 2018 15:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Wed, 23 May 2018 15:57:37 -0700 (PDT) In-Reply-To: <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> From: Patrick McManus Date: Wed, 23 May 2018 18:57:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: DoH WG Content-Type: multipart/alternative; boundary="00000000000017837f056ce7762a" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 22:57:41 -0000 --00000000000017837f056ce7762a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 22, 2018 at 1:29 PM, Mateusz Jo=C5=84czyk w= rote: > > I would argue that section 6.3 "Server Push" is poorly written and needs > to be > clarified. I have asked several questions about it in the past: > https://www.ietf.org/mail-archive/web/doh/current/msg00558.html > in order to better understand it. (I would like to thank Patrick McManus > and Ben > Schwartz for explanations I received.) > > I propose that it should be rewritten simply to: > > A DNS API client MUST ignore pushed DNS API requests (see > {{RFC7540}} > Section 8.2) whose pushed request URI does not match the > configured DNS > API server. > > a URI does not match a server - it must match a URI. and there need not be only one configured uri. I think the existing text covers those cases. --00000000000017837f056ce7762a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 22, 2018 at 1:29 PM, Mateusz Jo=C5=84czyk <mat.jonczyk@o2.= pl> wrote:

I would argue that section 6.3 "Server Push" is poorly wri= tten and needs to be
clarified. I have asked several questions about it in the past:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://w= ww.ietf.org/mail-archive/web/doh/current/msg00558.html
in order to better understand it. (I would like to thank Patrick McManus an= d Ben
Schwartz for explanations I received.)

I propose that it should be rewritten simply to:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A DNS API client MUST ignore pushed DNS API req= uests (see {{RFC7540}}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 8.2) whose pushed request URI does not = match the configured DNS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 API server.


a URI does not match a se= rver - it must match a URI. and there need not be only one configured uri. = I think the existing text covers those cases.

= =C2=A0

--00000000000017837f056ce7762a-- From nobody Thu May 24 14:07:47 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 E145512E87F; Thu, 24 May 2018 14:07:39 -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.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152719605985.5140.15513916632067391624@ietfa.amsl.com> Date: Thu, 24 May 2018 14:07:39 -0700 Archived-At: Subject: [Doh] I-D Action: draft-ietf-doh-dns-over-https-09.txt X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 21:07: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-09.txt Pages : 17 Date : 2018-05-24 Abstract: This document describes how to make DNS queries over HTTPS. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-doh-dns-over-https-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-09 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 May 24 14:09: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 3E8A612D7F4 for ; Thu, 24 May 2018 14:09:50 -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 KYdhVsvkyTJU for ; Thu, 24 May 2018 14:09:47 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 9EFEB12D77D for ; Thu, 24 May 2018 14:09:47 -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; Thu, 24 May 2018 14:09:46 -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; Thu, 24 May 2018 14:09:46 -0700 From: Paul Hoffman To: DoH WG Thread-Topic: Draft -09 and WGLC #2 Thread-Index: AQHT86OK+ACazYxRTkSlHCe86LplMw== Date: Thu, 24 May 2018 21:09:45 +0000 Message-ID: References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> 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: [Doh] Draft -09 and WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2018 21:09:50 -0000 Greetings. WGLC #2 generated some good discussion and overlapping pull requ= ests. We have issued draft -09 to deal with the discussion and make clear t= he current wording. Please see the diffs and let the WG know if there are s= till any outstanding issues on which there might be general agreement. --Paul Hoffman= From nobody Mon May 28 09:10:52 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23212DA6D for ; Mon, 28 May 2018 09:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=Y7yIqq9R; dkim=pass (1024-bit key) header.d=yitter.info header.b=j3Qq3dQt 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 gFC6jEzfw9xn for ; Mon, 28 May 2018 09:10:47 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844AE12DA69 for ; Mon, 28 May 2018 09:10:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id BF964BDEF9 for ; Mon, 28 May 2018 16:10:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527523846; bh=emgSOxBEkDgOeS8DbYPpQwNUXRuXvCDlaAcN4LHw2PI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Y7yIqq9Rr/d8/vKs/gQyz328rNxtk0h2szBHafFWUqA9WJ4lI94APSSrndYZSK+zD opD0G2y5lP7wprBGHOKG6ec3tzAGLfeaDYj+qcJC+lkcSSP3O2RYuN636+kUvmIQwW YnGgTFZLUufM5jIJ5pkWYZRwA5zI4OZv5jkpatb8= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20Jh_bRl_1Qs for ; Mon, 28 May 2018 16:10:45 +0000 (UTC) Date: Mon, 28 May 2018 12:10:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527523845; bh=emgSOxBEkDgOeS8DbYPpQwNUXRuXvCDlaAcN4LHw2PI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=j3Qq3dQtboldsA+pGwkFbOxa7FjTdOwy7wcwXRNmi6SFlbnMV5HCmT7Z1jYweJ7Xi JqOxilTaJp12OEfyOG0GsrYX5mm6wL7zIFAahEVrXbeuhpTLStXsmEwIPeWpL/fvdi 30pcTtoC3UKn7zW0l22IF3cigLUNtm8oq5Qxleg4= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180528161043.GB12038@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Draft -09 and WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 16:10:50 -0000 On Thu, May 24, 2018 at 09:09:45PM +0000, Paul Hoffman wrote: > Greetings. WGLC #2 generated some good discussion and overlapping pull requests. We have issued draft -09 to deal with the discussion and make clear the current wording. Please see the diffs and let the WG know if there are still any outstanding issues on which there might be general agreement. > Hi, I've been a little negligent in keeping up with this work lately, so I thought I'd take this opportunity to do a complete review. The editors are free to take this input, ignore it, hold anything that crops up for post-WG action, or whatever. By and large, I find the document clear and easy to read, so congratulations are due to the editors. This bit in section 4 strikes me as strange: A client MUST NOT use a DNS API server simply because it was discovered, or because the client was told to use the DNS API server by an untrusted party. This feels like it's crying out for a definition of "trusted", and yet that seems to me like a bad idea. Today, when you use an open wifi, you probably don't actually _trust_ the network operator, but you accept the default DNS server you get from DHCP anyway (unless you're the sort of nerd who thinks about this sort of thing). I can't tell from the text whether that kind of "trust" is supposed to be permitted by this or not. I recall some discussion about this in the past, but if the WG thinks that was resolved the resolution is totally opaque to an uninformed reader. Section 5.1 might want to note that the very fact of dependence on HTTPS means that the spoofing-resilience advantage of random DNS IDs do not apply to this case, but that DNS API servers are expected to deliver maximal spoofing resilence in performing any (normal) DNS resolution they themselves must do. Maybe this goes without saying, however. This text in section 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. ought to come with a note that this may be dangerous -- that is, if DNS operators are expecting their TTLs to be respected, this is a (new) way by which stale data might get re-used. So, DNS API server administrators ought to be careful with such a server policy. Maybe the warning ought to go in section 10, though it's hard to be sure: it's partially a warning for everyone _else_ on the Internet, including people who don't support DOH. In the same section, DNS API clients MUST account for the Age response header's value ([RFC7234]) when calculating the DNS TTL of a response. For example, if a RRset is received with a DNS TTL of 600, but the Age header indicates that the response has been cached for 250 seconds, the remaining lifetime of the RRset is 350 seconds. makes something plain by implication that might not obviously be clear otherwise. In the DNS environment today, many "clients" are stubs, and they're not very smart. One thing they do not always do is much cache control: they get the value from the full-service resolver and, if there is any local caching at all, it's straight decrementing of the TTL. What this passage means is that the data that comes in to a DNS API client _is not_ suitable to hand straight to the local stub subsystem: instead, some additional processing MUST be performed in order to ensure that TTLs are not accidentally extended by accident. Given the quality of a lot of DNS code in the world, I think this point should be made quite explicit somewhere in the document. Again, it might go in section 10, though it's not obvious to me that this is an operational consideration. It's more an architectural one. -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon May 28 17:23: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 72FAC12421A for ; Mon, 28 May 2018 17:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7_UZJyQJPPJ0 for ; Mon, 28 May 2018 17:23:38 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83D371270B4 for ; Mon, 28 May 2018 17:23:38 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id b130-v6so11550299oif.12 for ; Mon, 28 May 2018 17:23:38 -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=rzRhZU9hdXYLgu1GcXXoeS3TNAE+m6HDKKwoqpC0aJE=; b=X9MyF6ZI3WKBUIjbxpvH8DQVt95sLNqD/kdwgsNb7vl8U5ARgprodxXsF133QqTPyz zvpjxz0MlHpM96pbgcB+0mYukcyDpuE0io018eRHr3Neq9cvb6JPGfnhiWCEQdOM8ldn Qp69kKd9muFNncqmIzsWDengAjL5V2iwguNOTbgB921X/rR2zKu93q4/HhadhmxtB2mB iorAdajwjLBEZtmGDTUmqQvOx45oa81jEOW313jy6ikaM9WqionCKz6QXsTDKT66TOfc dq4eh9WtS4L+C2e5dedvJE8fe9DkG1SpitxsUBgJGTlnV+AJ3loNRoN8O9U1JzjrhkvO oGOA== 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=rzRhZU9hdXYLgu1GcXXoeS3TNAE+m6HDKKwoqpC0aJE=; b=faJdD0/b2tFrx6nPFDfZ//nBEfHYYdmyDgqL7Au8I9Vi8GXw1S/QyJMoKbWqdsmKh3 SgzPnGzw9iRDVp2hlBH21RJ9r+3gAGtvZK945Q9QV7jJn5tU04jCHp3APOf/OITzS7jz Xh0DI+3QwG/zu4fno+8q/0pfZaG2Un41lPG2S/o+oqWVhbpeau/ch1NTkyU7IUsreQqn ipcnXioPkFB/cIuy/bXXOk+H8kWF/K7TGHI8AB8Nlqdk3TRkX9oFLGXxilGdkqzq5mkg Ia1WbkgmBtc+FuVTVm7ZtcV6S+V5zTZl41n8M8I1uMqG653+hEoA8gLFJdxOG0Dvc4U5 DBIA== X-Gm-Message-State: ALKqPwf3Arb5qQwKs7TVPzxiVlNFczhtbWjecZ7Wy8MzCWxhnNgfmRu1 bERt2pg27BDO1bq0WLeY5GAxUaYcLtN2IE+Nqaqdea9a X-Google-Smtp-Source: ADUXVKJgJPS0nte9vQ1Y41pkiDNxVxzzSg3spjSnEoEMu5psNAFutsAY3xHgh2Y3rINOcv6gdIulE/Lw3tPyw/NT0OA= X-Received: by 2002:aca:4e15:: with SMTP id c21-v6mr7957893oib.254.1527553417566; Mon, 28 May 2018 17:23:37 -0700 (PDT) MIME-Version: 1.0 References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> In-Reply-To: <20180528161043.GB12038@mx4.yitter.info> From: Martin Thomson Date: Tue, 29 May 2018 10:23:27 +1000 Message-ID: To: DoH WG Cc: Andrew Sullivan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 00:23:40 -0000 On Tue, May 29, 2018 at 2:10 AM Andrew Sullivan wrote: > This bit in section 4 strikes me as strange: > A client MUST NOT use a DNS API > server simply because it was discovered, or because the client was > told to use the DNS API server by an untrusted party. > This feels like it's crying out for a definition of "trusted", and yet > that seems to me like a bad idea. Today, when you use an open wifi, > you probably don't actually _trust_ the network operator, but you > accept the default DNS server you get from DHCP anyway (unless you're > the sort of nerd who thinks about this sort of thing). I can't tell > from the text whether that kind of "trust" is supposed to be permitted > by this or not. I recall some discussion about this in the past, but > if the WG thinks that was resolved the resolution is totally opaque to > an uninformed reader. Thanks to Andrew for highlighting this little piece. His comment emphasizes the problem we're having here. And there has been a lot of back-and-forth on this subject. I suspect that we might have to tackle the "trust" question to make progress here. I've always been unhappy with this text, but understand that the text exists because other people are nervous about having arbitrary servers provide DNS responses. But as Andrew observes, that is precisely what happens in a lot of scenarios. Let's not pretend that the tiny few who override DNS configuration are relevant here; those people are best accommodated better with specific configuration options that control defaults. That's why I originally proposed a change to use "authorization" rather than trust. That is, it does not imply a value judgment. But that's not getting at the crux of the matter either. The problem with accepting arbitrary DNS answers is grounded in two pieces of trust that clients confer on servers: The first is that stub resolvers frequently offload DNSSEC processing, relying instead on the AD bit. Such a resolver is entirely at the mercy of the DNS API server in this case for answers that might be DNSSEC authenticated. That implies a degree of authorization. The second is that DNSSEC doesn't secure the protocol completely. DNSSEC allows for multiple valid answers for a query and the choice of answer can be important. DNS-based load balancing uses this, and performance and security can depend on the answer being selected correctly (at least in the aggregate). Here, there's a degree of authorization involved: we assume that a client picks a server that forwards queries and answers faithfully. On this latter point, there's a consideration that might be more pertinent: we assume that the client directs queries to the same server and thereby gains a consistent set of answers over time. If we change the text, I think that we could avoid the MUST and say that this document assumes that DNS API clients configure a single DNS API server and do not send queries to, or accept answers from, other servers. Then explain the consequences of configuring a DNS API server in terms of what "trust" is conferred to that server, as I described above. That is, no 2119 language, but more along the lines of an applicability statement; making it clear that the use of any other style of configuration is not advisable, or at least making the risks known. From nobody Mon May 28 18:30: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 DFDD812E86E for ; Mon, 28 May 2018 18:30:47 -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 3lipBRSY6Pe5 for ; Mon, 28 May 2018 18:30: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 4FEE612E88F for ; Mon, 28 May 2018 18:30:45 -0700 (PDT) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 681FE3A024 for ; Mon, 28 May 2018 21:30:42 -0400 (EDT) Received: by mail-ot0-f176.google.com with SMTP id g7-v6so15180989otj.11 for ; Mon, 28 May 2018 18:30:42 -0700 (PDT) X-Gm-Message-State: ALKqPwebfQvQwK3r1dNxoybV9ImLPv4rSDq4d5Mn3pPWw9QQTaQt10g0 DLLYZGVSj8swsweW1MQ0O+6inspJkmtRpXg0Iec= X-Google-Smtp-Source: ADUXVKJEIfy9KmR35yhguaVr5DdVcO3LSCICjnD5mwb/kn2AITBhhGy9ERAhqZ9EYCfAlB4MbWbK1K18pFU/RhYImkM= X-Received: by 2002:a9d:5014:: with SMTP id a20-v6mr9320223oth.205.1527557442138; Mon, 28 May 2018 18:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Mon, 28 May 2018 18:30:41 -0700 (PDT) In-Reply-To: References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> From: Patrick McManus Date: Mon, 28 May 2018 21:30:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: DoH WG , Andrew Sullivan Content-Type: multipart/alternative; boundary="000000000000b67580056d4e2e48" Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 01:30:48 -0000 --000000000000b67580056d4e2e48 Content-Type: text/plain; charset="UTF-8" > > > If we change the text, I think that we could avoid the MUST and say that > this document assumes that DNS API clients configure a single DNS API > server and do not send queries to, or accept answers from, other servers. > I don't think 'single' is the operative part there - and I don't think the document assumes that beyond a single request needing a single URI. But, yes, its the "others" that it is looking to exclude. I also think you're right to imply that we have a tension here between what we want to exclude now (stumbling across websites offering to be recursives) and what we want to enable exploring later (stumbling across websites offering to be recursives :)) in a more comprehensive manor. I'll offer up some text inspired by 7540's handling of client certs which has a somewhat similar profile. This might not be hard to solve - the section is really just using configuration and trust synonymously and a bit redundanty, but people are reading more into trust. So perhaps we can just use one term. wdyt of: "A DNS API client uses configuration to select the URI, and thus the DNS API server, used for resolution. [RFC2818] defines how HTTPS verifies the server's identity. A client MUST NOT use a different URI simply because it was discovered outside of configuration. Specifically, this specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as configured URIs. A future specification may support this case." --000000000000b67580056d4e2e48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If we change the text, I think that we could avoid the MUST and say that this document assumes that DNS API clients configure a single DNS API
server and do not send queries to, or accept answers from, other servers.

=C2=A0I don't think 'single'= is the operative part there - and I don't think the document assumes t= hat beyond a single request needing a single URI. But, yes, its the "o= thers" that it is looking to exclude.

I also = think you're right to imply that we have a tension here between what we= want to exclude now (stumbling across websites offering to be recursives) = and what we want to enable exploring later (stumbling across websites offer= ing to be recursives :)) in a more comprehensive manor. I'll offer up s= ome text inspired by 7540's handling of client certs which has a somewh= at similar profile.

This might not be hard to = solve - the section is really just using configuration and trust synonymous= ly and a bit redundanty, but people are reading more into trust. So perhaps= we can just use one term. wdyt of:

"A D= NS API client uses configuration to select the URI, and thus the DNS API se= rver, used for resolution. [RFC2818] defines how HTTPS verifies the server&= #39;s identity.

A client MUST NOT use a different = URI simply because it was discovered outside of configuration. Specifically= , this specification does not extend DNS resolution privileges to URIs that= are not recognized by the DNS API client as configured URIs. A future spec= ification may support this case."


<= br>






--000000000000b67580056d4e2e48-- From nobody Mon May 28 18:35:29 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0012E8A9 for ; Mon, 28 May 2018 18:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=m+bv5BJD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hn0JwAo+ 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 bcE2v0bB9JdE for ; Mon, 28 May 2018 18:35:21 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6502412DB71 for ; Mon, 28 May 2018 18:35:21 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D3D7521CB8; Mon, 28 May 2018 21:35:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 28 May 2018 21:35:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Lzo9bAwq1hI2y00fRQ6lCSQ6lp4bU ZAwltA2iRBHUVc=; b=m+bv5BJD9iq72us53qTrl8hWjFIZIWayKpxyeNXpFbFTj LdKh3J55q6A26JDpkRvloYcyrJPLKu3cjACHtisPaaHn3XKM0aAal9ltsH3CktCi o6Ys+O+ZkeG98k9HLD7JoahGpCDaHQxNKdsJsKRG6DwYVc62kEnDVmBVIJOmIu1M W/QshXCfw19+0hUquTy6SkflPEXtpU4sLS+AVekxjSbesuVwaHymfm2Syq8gMJx6 vWaZq+I7ghGZYuVM+5yOljdq20b7+xqhBCBZRl5ZAUzpd8Am3xAhy3qMTjTCnvXF +Z2ZH0Eg9ZaRPBsXBcgH5nFoP2KmU3oMOqiVD5LUw== 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=fm2; bh=Lzo9bA wq1hI2y00fRQ6lCSQ6lp4bUZAwltA2iRBHUVc=; b=hn0JwAo+euF0W44tyjx2sF GiQ+Fgrh/xwLM/INescNTA35ruUlAsYwqh/T22DdQYDTTstHcaC4a5PbcbKDmoFw 5VQ1L+RqxRMQOoZWEyN2kKayt+rOQnWphJVnRycXf481bR6wcKex0aJKtAjBiBoP jPT/1rGtm8eGi7e4gQyODPNcte34qWPIyIy/BZCerfDThzj7/hGAmJZqaDBeQ1TW JAlBBp/gtd06eCcqxazC0SMSnZmmEDNc2mo6g4FGihtk7C/c3WBysf1wOxKBzdIT Z6xbNIZ9Yhr4BacIcnrbxtaq6UZyuTOrKdGvrC77x0zhNM5s6+ssmeknmdWyRJyg == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 3B45CE4117; Mon, 28 May 2018 21:35:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Mark Nottingham In-Reply-To: Date: Tue, 29 May 2018 11:35:14 +1000 Cc: Martin Thomson , DoH WG , Andrew Sullivan Content-Transfer-Encoding: quoted-printable Message-Id: References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> To: Patrick McManus X-Mailer: Apple Mail (2.3445.6.18) Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 01:35:27 -0000 On 29 May 2018, at 11:30 am, Patrick McManus = wrote: >=20 > "A DNS API client uses configuration to select the URI, and thus the = DNS API server, used for resolution. [RFC2818] defines how HTTPS = verifies the server's identity. >=20 > A client MUST NOT use a different URI simply because it was discovered = outside of configuration. Specifically, this specification does not = extend DNS resolution privileges to URIs that are not recognized by the = DNS API client as configured URIs. A future specification may support = this case." I was thinking along the same lines, so +1 (although we could have a = conversation about whether a MUST NOT is appropriate here...). -- Mark Nottingham https://www.mnot.net/ From nobody Mon May 28 18:35: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 EB74212DFDB for ; Mon, 28 May 2018 18:35:53 -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 qlOfyCM6eZce for ; Mon, 28 May 2018 18:35:52 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 7090F12DA18 for ; Mon, 28 May 2018 18:35:52 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id i5-v6so15221171otf.1 for ; Mon, 28 May 2018 18:35:52 -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=CH7uHX3E7PSZ/eWQ7PJ/++OI2EisnuBba1yOmjG6aqM=; b=n+E27ZU96rfwQZSh/eBbkaGHeF77TxKbnO9QPK3zo0pGGq8wD/8ihlMXM4Pl3hai2V godzWmeKRxJj66H2fxasl0srDPSVtG6pHGMLo/gVOKeUFvnC47ZrM4uz0/nryOtAyoLu OrAXGgKx2nQNWTY0DTCJdEJAMLcQVbeDiuvGgb+ke3hQZkzjks6WxsHXyouNDja9RkyM QFQCe2RnUx4Vf1XOLS+6Svmi1lNdTmx+CJ/tsV0WWo6StjqXMhHua7eTaZBLmE3+4ZuR yGCNcMlZ3HNgQvdX+EkqOgl+lFgQ+cWJZH4iqOPj3cV75s078GJ4NNEIyXisLa/3M32h M03w== 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=CH7uHX3E7PSZ/eWQ7PJ/++OI2EisnuBba1yOmjG6aqM=; b=JDYFyOspWPHwoVrfKfLQiMKBIiLPyCfXBFFK294eDwQg2MvFl/NoZu41JKXp1ikHcw xWTPjzlqy232M2U3H3HYMtotv7WLqXsEy4o1Te1lkMa3H1HEulNUilYDk+H9wkglq2yw myb/pSj2zQKhboGhanK6r0OaPImDV3g5z+ZsTcUJMq4oT8hBtpHW+kdohBWJFRkQ8btm Fsaq3oEwBFc1hLswkPZGX+57mOoWM+HsR/JIFqYyedrXKd8K1/WerPEgyKAQ/J8Ws8Ar yfdZqLOetgqrKkuekZ+S7ccQpGaCZCKhxr6H8PhSKY0AZ55U6gsFnCv0JADBga3IRhUu o5Ng== X-Gm-Message-State: ALKqPwc5IBMOelHpFkNpLy3DJxbfqENr4zfWNRHlM55b2WHSIW4qYY7n pIKMdpC5+3TVs1AyIt8PJKfkiwSGrS5AaNh1ZrA= X-Google-Smtp-Source: ADUXVKIpTIvNnUoif6F+sS7NdWRAXqx03DHcZQmAOXg5q/2LtTkzUhDopE7jEJMwPMnRb9d+L0Tzi5onuXNuH8Awb8k= X-Received: by 2002:a9d:3ea5:: with SMTP id b34-v6mr9341929otc.283.1527557751708; Mon, 28 May 2018 18:35:51 -0700 (PDT) MIME-Version: 1.0 References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> In-Reply-To: From: Martin Thomson Date: Tue, 29 May 2018 11:35:41 +1000 Message-ID: To: patrick mcmanus Cc: DoH WG , Andrew Sullivan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 01:35:54 -0000 On Tue, May 29, 2018 at 11:30 AM Patrick McManus wrote: >> If we change the text, I think that we could avoid the MUST and say that >> this document assumes that DNS API clients configure a single DNS API >> server and do not send queries to, or accept answers from, other servers. > I don't think 'single' is the operative part there - and I don't think the document assumes that beyond a single request needing a single URI. But, yes, its the "others" that it is looking to exclude. > I also think you're right to imply that we have a tension here between what we want to exclude now (stumbling across websites offering to be recursives) and what we want to enable exploring later (stumbling across websites offering to be recursives :)) in a more comprehensive manor. I'll offer up some text inspired by 7540's handling of client certs which has a somewhat similar profile. > This might not be hard to solve - the section is really just using configuration and trust synonymously and a bit redundanty, but people are reading more into trust. So perhaps we can just use one term. wdyt of: > "A DNS API client uses configuration to select the URI, and thus the DNS API server, used for resolution. [RFC2818] defines how HTTPS verifies the server's identity. > A client MUST NOT use a different URI simply because it was discovered outside of configuration. ... or that resources offers a response that is apparently a valid answer to a DNS API query... > Specifically, this specification does not extend DNS resolution privileges to URIs that are not recognized by the DNS API client as configured URIs. A future specification may support this case." In my mail, I suggested that we hit the reasons for this restriction, so that it is clear why this "MUST" appears (I also suggested not using a MUST). I think that explaining what the client leans on the server for is important for understanding the decision to use the big guns here. From nobody Mon May 28 18:40: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 DC4FE12D9FF for ; Mon, 28 May 2018 18:40:05 -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 9qtxEsl-F_lf for ; Mon, 28 May 2018 18:40:03 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7882212DA2B for ; Mon, 28 May 2018 18:40:03 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id 05C133A01E for ; Mon, 28 May 2018 21:40:03 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id t22-v6so8249299oih.6 for ; Mon, 28 May 2018 18:40:03 -0700 (PDT) X-Gm-Message-State: ALKqPwfbn7sS8a4AO0QfgH40imygQ+Xo9DoBWDHEKd5klqi7gOntHvIe YYn0LX/HDenocLhhP40w1UJF13M4MyJAw4kVwN4= X-Google-Smtp-Source: ADUXVKIdn9gCU2iMSlZ/tsTt3J28waaxFPHeg6/x6EHLQNoFbp1Hg7p/Nit6iG1GSfVypHg/lZ2jsh4p4J4ivdGCEzc= X-Received: by 2002:aca:bec6:: with SMTP id o189-v6mr7842958oif.337.1527558002707; Mon, 28 May 2018 18:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a24:0:0:0:0:0 with HTTP; Mon, 28 May 2018 18:40:02 -0700 (PDT) In-Reply-To: <20180528161043.GB12038@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> From: Patrick McManus Date: Mon, 28 May 2018 21:40:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="0000000000002014b7056d4e5064" Archived-At: Subject: Re: [Doh] Draft -09 and WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 01:40:06 -0000 --0000000000002014b7056d4e5064 Content-Type: text/plain; charset="UTF-8" , > > DNS API clients MUST account for the Age response header's value > ([RFC7234]) when calculating the DNS TTL of a response. For example, > if a RRset is received with a DNS TTL of 600, but the Age header > indicates that the response has been cached for 250 seconds, the > remaining lifetime of the RRset is 350 seconds. > > > the TTL. What this passage means is that the data that comes in to a > DNS API client _is not_ suitable to hand straight to the local stub > subsystem: instead, some additional processing MUST be performed in > order to ensure that TTLs are not accidentally extended by accident. > That's not only what it means, it seems to me that's what it says :).. What other words would help here? (Noting that this is not always a gateway. Sometimes the HTTP client is the terminal client.) --0000000000002014b7056d4e5064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
,

=C2=A0 =C2=A0DNS API clients MUST account for the Age response header's= value
=C2=A0 =C2=A0([RFC7234]) when calculating the DNS TTL of a response.=C2=A0 = For example,
=C2=A0 =C2=A0if a RRset is received with a DNS TTL of 600, but the Age head= er
=C2=A0 =C2=A0indicates that the response has been cached for 250 seconds, t= he
=C2=A0 =C2=A0remaining lifetime of the RRset is 350 seconds.


the TTL.=C2=A0 What this passage means is that the data that comes in to a<= br> DNS API client _is not_ suitable to hand straight to the local stub
subsystem: instead, some additional processing MUST be performed in
order to ensure that TTLs are not accidentally extended by accident.

That's not only what it means, it seem= s to me that's what it says :).. What other words would help here? (Not= ing that this is not always a gateway. Sometimes the HTTP client is the ter= minal client.)


--0000000000002014b7056d4e5064-- From nobody Mon May 28 20:35: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 C1F4F12DA15 for ; Mon, 28 May 2018 20:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=GfUmbeSP; dkim=pass (1024-bit key) header.d=yitter.info header.b=JPYidV5+ 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 5sQF7Y7DuGHo for ; Mon, 28 May 2018 20:35:24 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1235B12D945 for ; Mon, 28 May 2018 20:35:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 54A24BDEF9 for ; Tue, 29 May 2018 03:35:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527564923; bh=52pPK49dARdkzTrg5rWs2n/U8UcmsiAnnJ1SLWEN8LE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=GfUmbeSPjYzjVfPNesQ2a5+AbCv7YnRnxbwU1+gcqBgsutuml25URI+Z+G8IFVFzg HUpwxV1FXSLVKl1eUrgPCthSNM7arhM4F7qrFzekeFx76MHziJNiJf8bm4hgpu05V6 haueluT2QbAb4+e2xEKJxOiSaXpRc/DYKV7nzthA= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP50NzTZc_AZ for ; Tue, 29 May 2018 03:35:22 +0000 (UTC) Date: Mon, 28 May 2018 23:35:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527564922; bh=52pPK49dARdkzTrg5rWs2n/U8UcmsiAnnJ1SLWEN8LE=; h=Date:From:To:Subject:References:In-Reply-To:From; b=JPYidV5+JJ1IGKmVpugPk29bT0DT8TEj+IuG6MZav1Qf4gbM9W9er8dlwuOr9+kMW 1cIIZi1NL6hW9FsUR+bQIAk3nDdMBEu+qXcuJZE/ydmi9JhnApqxgaD+pmAweErtjj 9nzt8BkmC/II6qva7qavfrDwjwW6NqIc3/p7rYyQ= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180529033519.GB18049@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Doh] Draft -09 and WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 03:35:26 -0000 On Mon, May 28, 2018 at 09:40:02PM -0400, Patrick McManus wrote: > , > > >    DNS API clients MUST account for the Age response header's value >    ([RFC7234]) when calculating the DNS TTL of a response.  For example, >    if a RRset is received with a DNS TTL of 600, but the Age header >    indicates that the response has been cached for 250 seconds, the >    remaining lifetime of the RRset is 350 seconds. > > > the TTL.  What this passage means is that the data that comes in to a > DNS API client _is not_ suitable to hand straight to the local stub > subsystem: instead, some additional processing MUST be performed in > order to ensure that TTLs are not accidentally extended by accident. > > > That's not only what it means, it seems to me that's what it says :) No, that's what it implies, but it's not what it says. That's actually what I'm complaining about. The DNS is the swamp it is partly because of the number of places in STD13 that depend on implication rather than instruction for people to do the right thing. A contract programmer with an alloted 18 hours will spend exactly 18 hours, at most, to do this. So let's make it explicit. Perhaps this: "remaining lifetime …seconds. DNS API clients SHOULD NOT pass along the received DNS RRset without decrementing the TTL to match the remaining lifetime. Doing so may accidentally prolong the lifetime of a cached DNS RRset, and therefore ought not to be passed along without strong evidence that the requesting client will process the resulting cached entries correctly." That's awkward and needs some work. But it's at least explicit. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue May 29 02:27:38 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1E8126BFD for ; Tue, 29 May 2018 02:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLsjBkiE_3x7 for ; Tue, 29 May 2018 02:27:34 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2A812421A for ; Tue, 29 May 2018 02:27:34 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=50889) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fNaue-0001vq-9T; Tue, 29 May 2018 10:27:32 +0100 From: Sara Dickinson Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_53654ECA-53AE-42D2-B4DD-8B5AF81EF375" Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Date: Tue, 29 May 2018 10:27:15 +0100 In-Reply-To: Cc: Martin Thomson , DoH WG , Andrew Sullivan To: Patrick McManus References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 09:27:37 -0000 --Apple-Mail=_53654ECA-53AE-42D2-B4DD-8B5AF81EF375 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 May 2018, at 02:30, Patrick McManus = wrote: >=20 >=20 > If we change the text, I think that we could avoid the MUST and say = that > this document assumes that DNS API clients configure a single DNS API > server and do not send queries to, or accept answers from, other = servers. >=20 > I don't think 'single' is the operative part there - and I don't = think the document assumes that beyond a single request needing a single = URI. But, yes, its the "others" that it is looking to exclude. +1 Do not limit this to a single configured server.=20 >=20 > I also think you're right to imply that we have a tension here between = what we want to exclude now (stumbling across websites offering to be = recursives) and what we want to enable exploring later (stumbling across = websites offering to be recursives :)) in a more comprehensive manor. = I'll offer up some text inspired by 7540's handling of client certs = which has a somewhat similar profile. >=20 > This might not be hard to solve - the section is really just using = configuration and trust synonymously and a bit redundanty, but people = are reading more into trust. So perhaps we can just use one term. wdyt = of:=20 >=20 > "A DNS API client uses configuration to select the URI, and thus the = DNS API server, used for resolution. [RFC2818] defines how HTTPS = verifies the server's identity. >=20 > A client MUST NOT use a different URI simply because it was discovered = outside of configuration. Specifically, this specification does not = extend DNS resolution privileges to URIs that are not recognized by the = DNS API client as configured URIs. A future specification may support = this case.=E2=80=9D I much prefer the approach of just discussing configuration but I = don=E2=80=99t think this goes far enough in answering Andrews question = or helping implementors work out exactly what to to. So=E2=80=A6. What does =E2=80=98configuration=E2=80=99 cover? - Just direct configuration e.g. via a client API or config file - Or also dynamic configuration e.g. via DHCP, assuming a future option = for this (which raises the question of trust again=E2=80=A6.)?=20 I support only specifying direct configuration in this document but = either way making it more explicit. Sara.=20= --Apple-Mail=_53654ECA-53AE-42D2-B4DD-8B5AF81EF375 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 29 May 2018, at 02:30, Patrick McManus <pmcmanus@mozilla.com> wrote:


If we change the text, I think that we could avoid the MUST and say = that
this document assumes that DNS API clients configure a single DNS API
server and do not send queries to, or accept answers from, other = servers.

 I don't think 'single' is the = operative part there - and I don't think the document assumes that = beyond a single request needing a single URI. But, yes, its the "others" = that it is looking to = exclude.

+1 Do not limit this to a single configured = server. 


I also think you're right to imply that = we have a tension here between what we want to exclude now (stumbling = across websites offering to be recursives) and what we want to enable = exploring later (stumbling across websites offering to be recursives :)) = in a more comprehensive manor. I'll offer up some text inspired by = 7540's handling of client certs which has a somewhat similar profile.

This= might not be hard to solve - the section is really just using = configuration and trust synonymously and a bit redundanty, but people = are reading more into trust. So perhaps we can just use one term. wdyt = of:

"A DNS API client uses configuration to select the URI, and = thus the DNS API server, used for resolution. [RFC2818] defines how = HTTPS verifies the server's identity.

A client MUST NOT use a different URI = simply because it was discovered outside of configuration. Specifically, = this specification does not extend DNS resolution privileges to URIs = that are not recognized by the DNS API client as configured URIs. A = future specification may support this = case.=E2=80=9D

I much prefer the approach of just discussing = configuration but I don=E2=80=99t think this goes far enough in = answering Andrews question or helping implementors work out exactly what = to to. So=E2=80=A6.

What does = =E2=80=98configuration=E2=80=99 cover?
- Just direct = configuration e.g. via a client API or config file
- Or also = dynamic configuration e.g. via DHCP, assuming a future option for this = (which raises the question of trust again=E2=80=A6.)? 

I support only specifying direct configuration in = this document but either way making it more explicit.

Sara. 
= --Apple-Mail=_53654ECA-53AE-42D2-B4DD-8B5AF81EF375-- From nobody Tue May 29 11:00:11 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E30812EBD4 for ; Tue, 29 May 2018 11:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3aH8brusduR for ; Tue, 29 May 2018 11:00:07 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 D621B12EAC4 for ; Tue, 29 May 2018 11:00:06 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id d22-v6so4078037iof.13 for ; Tue, 29 May 2018 11:00:06 -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; bh=68YdVmfeKdLfbvcwOKSb3p5YLUQVHqEZkETdnAAqS4E=; b=k83Q4x+1LyYxPTGfZUUHFlEaAzDO95Ur29x8bTrI7FqXrSXe9mCU3a2fyGAnRDQL8G grJFxjwvKOG7oV9v1CgtjpFVaFZUfiDgybuAMwiPJ3ypJqnC2iIEc2UnnWcWs1rEMPcM WX9lvP3L54j7feEPx4ER0LbMAzrPtYVnG3SfSrTRT3WSnKQ+wdiNKqpaHc/d0B9IMtXN c79jaj3Q7jDedaf+qp4D9o8WkhFMshmdRy8IxyhsIb/6TiMEjzmwF/ISoqijK4+UPmZo 1MTcwF9RpkKqgXDvYblJ2i3oF5KFOLiSc7GCDGdW5iM+TWkKdFXyEYAFRPeYlGU44Du5 bFBw== 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; bh=68YdVmfeKdLfbvcwOKSb3p5YLUQVHqEZkETdnAAqS4E=; b=Bf3vTaKBROEZPGvYVGDeQGTk7B7QYIU1cL/cKfttjFqwTfpv4RyAKndUtY1ZH3qxTt +RPhymCl9+oQmDLQIioh69yhxgofoa9ihzrqsCnrNfXg7KDVwQt09JK0jHsADkW34rX2 QqsXeF71CyYkRHyrzShPlH2oEB5ezJ9KZgnFr9IWO+RnxWujshzT779swz4HloLMrm4Z W2ReHnv3HZrU9ei2UtiuptUxuUpVHUGvh1NJ1ikQlp0J1G0DpZmdjB853x4Ig8vJmLvI LulMbmpcr6PCHWst+GdjmFcJGHtJCC3gEEMEhNoe802QsV99bROQj3dqAAL6KXIEA7Cf wlsw== X-Gm-Message-State: ALKqPwePFJhhq6K4SO5e3CrW+z0QTmaA65BHj5h3daZQl26ECjch2BPy 2VK5iTEVut4nehirXgFZOP6xMPOGVfsuTskU/XOAytdf X-Google-Smtp-Source: ADUXVKIRdUHIomBxInJIKZamNniLwFhxCmaVPD9RuNXfBqEZIw+k4m9jdWbUkbFFtMuObIwKlZiwLZv8tWMCXaGKSxw= X-Received: by 2002:a6b:d117:: with SMTP id l23-v6mr14888999iob.3.1527616805504; Tue, 29 May 2018 11:00:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 29 May 2018 13:59:54 -0400 Message-ID: To: DoH WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000015cdf2056d5c01b6" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:00:09 -0000 --00000000000015cdf2056d5c01b6 Content-Type: multipart/alternative; boundary="0000000000000c316b056d5c0131" --0000000000000c316b056d5c0131 Content-Type: text/plain; charset="UTF-8" Thanks for everyone who participated in this WGLC #2, and thanks to the authors for engaging and making good changes in response to input from the working group. The last call is now closed. In the opinion of the chairs, the group has reached technical consensus, and invested considerable effort in the clarity and precision of the text. The chairs ask the authors to incorporate any outstanding input on the latest draft as they are able, and publish a new draft, which we will pass to our Area Director and the IESG. Thanks again to everyone who has helped throughout the process to make this an excellent draft. On Sat, May 19, 2018 at 10:47 AM Ben Schwartz wrote: > DOH! > > The Working Group Last Call on draft-ietf-doh-dns-over-https-07 raised an > excellent round of discussion. The chairs believe that all issues raised > in that period have been satisfactorily addressed, and draft-08 reflects > the working group consensus on these questions. However, to ensure that we > reach the best possible consensus, we are opening a short Working Group > Last Call on this latest draft. > > Please review the draft: > https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-08 > or the changes > https://tools.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-08.txt > and attempt to resolve any remaining concerns on the list by Friday May > 25th (one week). > > Sincerely, > The Chairs > --0000000000000c316b056d5c0131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for everyone who participated in this WGLC #2, and = thanks to the authors for engaging and making good changes in response to i= nput from the working group.

The last call is now closed= .=C2=A0 In the opinion of the chairs, the group has reached technical conse= nsus, and invested considerable effort in the clarity and precision of the = text.=C2=A0 The chairs ask the authors to incorporate any outstanding input= on the latest draft as they are able, and publish a new draft, which we wi= ll pass to our Area Director and the IESG.

Thanks = again to everyone who has helped throughout the process to make this an exc= ellent draft.

On= Sat, May 19, 2018 at 10:47 AM Ben Schwartz <bemasc@google.com> wrote:
DOH!

The Working Group Last Call on draft-ietf-doh-dns-over= -https-07 raised an excellent round of discussion.=C2=A0 The chairs believe= that all issues raised in that period have been satisfactorily addressed, = and draft-08 reflects the working group consensus on these questions.=C2=A0= However, to ensure that we reach the best possible consensus, we are openi= ng a short Working Group Last Call on this latest draft.

Please review the = draft:
or the changes
and attempt to resolve any rem= aining concerns on the list by Friday May 25th (one week).

Si= ncerely,
The Chairs
--0000000000000c316b056d5c0131-- --00000000000015cdf2056d5c01b6 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 fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCA0KrvpwMymuThgCt8gsJ/x 8KFYChzjj/Cy1PWHZgfWJTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA1MjkxODAwMDZaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAxECk+pYODNFBkWCpQx7OqJrioaYd+nB7m0fwxkJk sRmh1KmZuzk0gz4/amHELMCN9kmm/3CRMhCPmXPpXn3AczXm7wHX4ZfKqwSpj+Btla79FwuTq7ZN SpLUQcnJ5yqSUspREfv7kNRZJ4pqYZ3RF5C1UIOWz6eRoj7b1/MqCaaQ85/mD9dpocJhj9kwgsId kkE3DBRltD08kv2JKmYDTnzHk+JfNqgt/uXwR33hx2weebDwCkQQR3IzscdDpongw4yZ+Xj97X0e U2TtnWU6YLuc2bVDGKHnCcFaTVpVZ9V0Tit93+0VEGuIw/61h8mr5bJTJzHC1SeKudRAcZUIoA== --00000000000015cdf2056d5c01b6-- From nobody Tue May 29 11:28: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 2835E12E03D for ; Tue, 29 May 2018 11:28:46 -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, FREEMAIL_FROM=0.001, 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 hZHPvmR5vNQc for ; Tue, 29 May 2018 11:28:42 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 749C312EB5A for ; Tue, 29 May 2018 11:28:42 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 29100 invoked from network); 29 May 2018 20:28:38 +0200 Received: from agkc173.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.130.173]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 29 May 2018 20:28:38 +0200 To: Sara Dickinson , DoH WG , Martin Thomson , Patrick McManus References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <2efb065a-6c77-7eac-c7d1-a34e08399bda@o2.pl> Date: Tue, 29 May 2018 20:28:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82kpRHMDgtpr0ysAVxwRBduC4tN7WHI7A" X-WP-MailID: 2b7a16f7591dca9445a4bd9e6b10cc32 X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [QYO0] Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:28:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --82kpRHMDgtpr0ysAVxwRBduC4tN7WHI7A Content-Type: multipart/mixed; boundary="MX4OIgiQvyF1VubjLxR2xufvMyENOYaOa"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Sara Dickinson , DoH WG , Martin Thomson , Patrick McManus Message-ID: <2efb065a-6c77-7eac-c7d1-a34e08399bda@o2.pl> Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> In-Reply-To: --MX4OIgiQvyF1VubjLxR2xufvMyENOYaOa Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable Hello, W dniu 29.05.2018 o 03:30, Patrick McManus pisze: > "A DNS API client uses configuration to select the URI, and thus the DN= S API > server, used for resolution. [RFC2818] defines how HTTPS verifies the s= erver's > identity. > > A client MUST NOT use a different URI simply because it was discovered = outside > of configuration. Specifically, this specification does not extend DNS > resolution privileges to URIs that are not recognized by the DNS API cl= ient as > configured URIs. A future specification may support this case." This does not differ much from the following text: "A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST = only use DNS API servers specified using mechanisms such as explicit configura= tion." which happens to be what is specified by the current draft. I think that the misunderstanding here stems from the fact that server tr= ust is specified in two distinct places in the document ("Security Consideration= s" and "Selection of DNS API Server") and in each place differently. I've been proposing over and over to unify both specifications. It is OK = if Paul (if I remember correctly) wants to have server trust defined in a separat= e section outside "Security Considerations", but we should make both specifications similar and make one of them refer to the other. -------------------------------------------------------------------------= ---- I have also been thinking about the following mechanism: A DNS API client would have a list of "trustworthy" DNS API servers, but = which DNS API server from that list is used could be selected using DHCP. I sent this to the DRIU list [1], as I supposed it is more appropriate th= ere. But now such topics are being discussed on the DOH mailing list and so I = am posting it here. It would have the following benefits: 1. Using one's own ISP's DNS server would allow DNS64. 2. It would give network administrators an easy way to choose a DNS provi= der across a whole network (using DHCP) and configure it in one place instead= of on multiple machines. 3. It would also enable use of ISP's DNS API server (as a main server or = as a fallback), which would make it possible to share global DNS load across m= any ISP's DNS servers. For details, see the quoted mail. At the same time, it would provide protection against phishing and rogue = actors. Greetings, Mateusz [1] https://www.ietf.org/mail-archive/web/driu/current/msg00009.html --MX4OIgiQvyF1VubjLxR2xufvMyENOYaOa-- --82kpRHMDgtpr0ysAVxwRBduC4tN7WHI7A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbDZvUAAoJEPvWWrhhCv7G+bQQAJ//WKEQgsQzfzp1JJDvuxti 0/Q7yUdQyKF2Ru+gPvKiMcS5GsiGTEXF5KU8yKtxAwMDNsonY3hHxP6ZLdPftrZE 8HkeVKQI/umoNF16npM5Z8HUHShOw8xF7t+dNPTVGjPKynJtFg8Pwp7G9DDQGwsl EuIre8VywEPUxH3LDQqedt2SbWEgRBUV7DeczZgy7VCZqfeQBf5n/5Hqf305cPow YBv+Q+MctXVSW9eGktaroo484z2gp7h5nu/vunHFvR+b+m+KCVh+SZzlfJz+BM6u +z/AcSaa5g2f5c3m+/0FvRGt4x0u7cEZYHqMG98oN3bQKiC40Vm21kokTC0lLbd7 7WqWMAO4cCXglAGfDXlnc7JaDVz+laN0nHodUbzS1vtNJ0jfVEkRsjuOumu5jIjP wCCP+OtpisRJrxbNFXHoLZ8Xez0WZSZSUIa1xv/3j16jnLv7KVdXMNmWY4jcWkqZ LMND/r1zAGYqVnEKG9lyWH/eyK94NxOAIaIDOHekjRdABZ2SpIoD+dSAMa7Vi/u3 jrOo5JzWIUvl3yzhRg7gYIQz+kdRIxhaDd8VFzVJKX8PBsvM0dFj17fEdHUQVFS/ Nfh9f94GaU20HdrztyboUR+TKUkpXZ0ciGX0JPwY9prvgTgJMJVf2g1zwlRg9QMj iNAY1PbNHxmoxY5k9/AP =dgLU -----END PGP SIGNATURE----- --82kpRHMDgtpr0ysAVxwRBduC4tN7WHI7A-- From nobody Tue May 29 18:10:43 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 2773B12FA7A for ; Tue, 29 May 2018 18:10:41 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6zcPUZnND1a for ; Tue, 29 May 2018 18:10:36 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205C212F280 for ; Tue, 29 May 2018 18:10:36 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id 14-v6so6823373oie.3 for ; Tue, 29 May 2018 18:10:36 -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=olD6XOZlQ08ELVkjQ6MyRvkTtJyrfEfY5Q6NGltTFZs=; b=elYVydD/4IDZw+6JVXG8RRAUIMPb3sY7IDiP45DLVy4JgvjjhMYmpi5VtFYMYGliTt 21tuID02Qz4+HLamI6sVesDwxjjlbdjswe1f1gW/W3mE7q5q4UvxXxVog8LXpgw3NzbS E/EzKqU8TjmzgBmoKmraHiriXZaB1eFxE4Y9d66fi+tzCyqRURtHNSSue5EkIuFTJe6x K5p/oHLKIRxFdI9l/ENoxR3Yf84KMweE1CEzdkKqfZ9uTIuyPsYJy6VeRrsNoIPIXcz3 /iizlge2OlbtDDntB05yOEjFaqgNLgmj1DC6PTkEaDOYpqeN53cti4l2AKXJ87wZi1hU gqxA== 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=olD6XOZlQ08ELVkjQ6MyRvkTtJyrfEfY5Q6NGltTFZs=; b=evY5naWTnLwUdxoYlChBivRFY3OXBTBjSJJPY+A2bqEBv8cGoF0oeOJ9PEqB/U+mxp x4TpbaSSQEj38FqL2YX1TQR8KNka4nlNX+MW0J0iSRHAIYJ5jveeoW5bydT50ZJeKP+t 2mdRsXoJbbBblDiwXIMM5Yv70kPnxSFZ9KXMUFo+5xufGqLvQGkpuG7+Ubwu85Ww4KKw WIdUQJQc+x4Q4D7wFziaT0n7b+Xq2PIw1jgzO36gfYAlc9XL3TPmbyjrGdv/F8W6QPz0 jJV/d/ceH0m9uQvF0euZF+2wPJr8fswLL8P1hyD01041ds2O3eun1Fl1dxj426Fa3lBC ZYNg== X-Gm-Message-State: APt69E0v6fszGyg4AF0ENHTjbU0mpwWb8ToGyw1O6mrDzmqRG6WhZ3NG AiSSGvv8vvE0h0890FFOMRttmiWtBkZT0XIJmWVEYA== X-Google-Smtp-Source: ADUXVKJtkwNZlls6T/4SZHb5Lm0sCgrJ3m9COSHXgbQ6VzdfRKMQKyOjgTDbpkdNKDqUA6/GPUcwlPKA4UQkZeDm/JM= X-Received: by 2002:aca:1218:: with SMTP id 24-v6mr382670ois.144.1527642635435; Tue, 29 May 2018 18:10:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Wed, 30 May 2018 11:10:25 +1000 Message-ID: To: bemasc=40google.com@dmarc.ietf.org Cc: DoH WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:10:41 -0000 We have a parallel discussion running. Are the chairs declaring that dead? On Wed, May 30, 2018 at 4:00 AM Ben Schwartz wrote: > Thanks for everyone who participated in this WGLC #2, and thanks to the authors for engaging and making good changes in response to input from the working group. > The last call is now closed.. In the opinion of the chairs, the group has reached technical consensus, and invested considerable effort in the clarity and precision of the text. The chairs ask the authors to incorporate any outstanding input on the latest draft as they are able, and publish a new draft, which we will pass to our Area Director and the IESG. > Thanks again to everyone who has helped throughout the process to make this an excellent draft. > On Sat, May 19, 2018 at 10:47 AM Ben Schwartz wrote: >> DOH! >> The Working Group Last Call on draft-ietf-doh-dns-over-https-07 raised an excellent round of discussion. The chairs believe that all issues raised in that period have been satisfactorily addressed, and draft-08 reflects the working group consensus on these questions. However, to ensure that we reach the best possible consensus, we are opening a short Working Group Last Call on this latest draft. >> Please review the draft: >> https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-08 >> or the changes >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-doh-dns-over-https-08.txt >> and attempt to resolve any remaining concerns on the list by Friday May 25th (one week). >> Sincerely, >> The Chairs > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Tue May 29 18:23: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 41A3812EB45 for ; Tue, 29 May 2018 18:22:58 -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 8TDpJiO5EHru for ; Tue, 29 May 2018 18:22:56 -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 F316612EBAA for ; Tue, 29 May 2018 18:22:55 -0700 (PDT) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6DE7D3A042 for ; Tue, 29 May 2018 21:22:55 -0400 (EDT) Received: by mail-ot0-f169.google.com with SMTP id t1-v6so19231372ott.13 for ; Tue, 29 May 2018 18:22:55 -0700 (PDT) X-Gm-Message-State: ALKqPwdXReH33L14dy9Sflwmg3ApWAGRA8k5+x9npLTnwQc7JAO7s/rC yMWz5KGp/ph97F2q1bYhMIGUFRuWL3HnqcewiRg= X-Google-Smtp-Source: ADUXVKIUXAR6xqPVSfrbjVmGZ43jbL+XdPdfAcBrQf/U40yNuJkwWkJejEwncA7B+4BS83YBRsX5ImiFkAo+4Ig8mqQ= X-Received: by 2002:a9d:419c:: with SMTP id p28-v6mr513088ote.2.1527643375115; Tue, 29 May 2018 18:22:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 29 May 2018 18:22:54 -0700 (PDT) In-Reply-To: References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> From: Patrick McManus Date: Tue, 29 May 2018 21:22:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Sara Dickinson Cc: Patrick McManus , Martin Thomson , DoH WG , Andrew Sullivan Content-Type: multipart/alternative; boundary="000000000000b7a4d1056d623001" Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:23:04 -0000 --000000000000b7a4d1056d623001 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sara, On Tue, May 29, 2018 at 5:27 AM, Sara Dickinson wrote: > > > I much prefer the approach of just discussing configuration but I don=E2= =80=99t > think this goes far enough in answering Andrews question or helping > implementors work out exactly what to to. So=E2=80=A6. > > What does =E2=80=98configuration=E2=80=99 cover? > - Just direct configuration e.g. via a client API or config file > - Or also dynamic configuration e.g. via DHCP, assuming a future option > for this (which raises the question of trust again=E2=80=A6.)? > > I support only specifying direct configuration in this document but eithe= r > way making it more explicit. > I would describe [in]direct (or not) as one aspect of discovery, and the working group has chosen to stay away from discovery in this document. OTOH as I understand it discovery is the core topic of the DRIU bof, and is also on topic for this WG in a different document should someone propose such a thing. DoH isn't trying to solve that problem with the text under discussion - its just trying to say that the server(s) need to be bootstrapped and not discovered via linking and pushing during unrelated HTTP activities. Using the word "untrusted" was a mistake because it indicated more than that. -Patrick --000000000000b7a4d1056d623001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sara,
<= br>
On Tue, May 29, 2018 at 5:27 AM, Sara Dickins= on <sara@sinodun.com> wrote:


I much prefer the approach of just discussing configuration= but I don=E2=80=99t think this goes far enough in answering Andrews questi= on or helping implementors work out exactly what to to. So=E2=80=A6.
<= div>
What does =E2=80=98configuration=E2=80=99 cover?
- Just direct configuration e.g. via a client API or config file
- Or also dynamic configuration e.g. via DHCP, assuming a future option = for this (which raises the question of trust again=E2=80=A6.)?=C2=A0
<= div>
I support only specifying direct configuration in this d= ocument but either way making it more explicit.

I would describe [in]direct (or not) as= one aspect of discovery, and the working group has chosen to stay away fro= m discovery in this document.

OTOH as I under= stand it discovery is the core topic of the DRIU bof, and is also on topic = for this WG in a different document should someone propose such a thing.

DoH isn't trying to solve that problem with the = text under discussion - its just trying to say that the server(s) need to b= e bootstrapped and not discovered via linking and pushing during unrelated = HTTP activities. Using the word "untrusted" was a mistake because= it indicated more than that.

-Patrick
<= br>




<= br>

--000000000000b7a4d1056d623001-- From nobody Tue May 29 19:14:22 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC94012EB98 for ; Tue, 29 May 2018 19:14:20 -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 I9OHYGS2Jvyf for ; Tue, 29 May 2018 19:14:18 -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 6B69212EB62 for ; Tue, 29 May 2018 19:14:18 -0700 (PDT) Received: from mail-ot0-f173.google.com (mail-ot0-f173.google.com [74.125.82.173]) by linode64.ducksong.com (Postfix) with ESMTPSA id DC59A3A041 for ; Tue, 29 May 2018 22:14:17 -0400 (EDT) Received: by mail-ot0-f173.google.com with SMTP id q17-v6so8782049otg.2 for ; Tue, 29 May 2018 19:14:17 -0700 (PDT) X-Gm-Message-State: ALKqPwe3zEG3Gy+Nbg6j3uRk7f9qmtdLZ1ZAFI8mOup+S59H4d69lYnw btQOJZ9vsg5Si9pxYSXgMY2JIad0RU5C3bOQL2A= X-Google-Smtp-Source: ADUXVKJnlONB0FIZdfPr0bCnMM+uoAS6FVqKnCK3zl8Zwi38tXTcQk4duHIT6JG1I6UCYj214EHyuaUVcFYHXg2+Lvs= X-Received: by 2002:a9d:419c:: with SMTP id p28-v6mr592663ote.2.1527646457598; Tue, 29 May 2018 19:14:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 29 May 2018 19:14:17 -0700 (PDT) In-Reply-To: References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> From: Patrick McManus Date: Tue, 29 May 2018 22:14:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus Cc: Sara Dickinson , Martin Thomson , DoH WG , Andrew Sullivan Content-Type: multipart/alternative; boundary="00000000000072979d056d62e85b" Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 02:14:21 -0000 --00000000000072979d056d62e85b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've proposed https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/189 Mateusz, it also harmonizes with the security considerations a bit. On Tue, May 29, 2018 at 9:22 PM, Patrick McManus wrote: > Hi Sara, > > On Tue, May 29, 2018 at 5:27 AM, Sara Dickinson wrote: > >> >> >> I much prefer the approach of just discussing configuration but I don=E2= =80=99t >> think this goes far enough in answering Andrews question or helping >> implementors work out exactly what to to. So=E2=80=A6. >> >> What does =E2=80=98configuration=E2=80=99 cover? >> - Just direct configuration e.g. via a client API or config file >> - Or also dynamic configuration e.g. via DHCP, assuming a future option >> for this (which raises the question of trust again=E2=80=A6.)? >> >> I support only specifying direct configuration in this document but >> either way making it more explicit. >> > > I would describe [in]direct (or not) as one aspect of discovery, and the > working group has chosen to stay away from discovery in this document. > > OTOH as I understand it discovery is the core topic of the DRIU bof, and > is also on topic for this WG in a different document should someone propo= se > such a thing. > > DoH isn't trying to solve that problem with the text under discussion - > its just trying to say that the server(s) need to be bootstrapped and not > discovered via linking and pushing during unrelated HTTP activities. Usin= g > the word "untrusted" was a mistake because it indicated more than that. > > -Patrick > > > > > > > > --00000000000072979d056d62e85b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mateusz, it also= harmonizes with the security considerations a bit.

On Tue, May 29, 2018 at 9= :22 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
=
Hi Sara,

On Tue, May 29, 2018 at 5:27 AM, Sara Dickinson <sara@sinodun.com>= ; wrote:


I much pref= er the approach of just discussing configuration but I don=E2=80=99t think = this goes far enough in answering Andrews question or helping implementors = work out exactly what to to. So=E2=80=A6.

What doe= s =E2=80=98configuration=E2=80=99 cover?
- Just direct configurat= ion e.g. via a client API or config file
- Or also dynamic config= uration e.g. via DHCP, assuming a future option for this (which raises the = question of trust again=E2=80=A6.)?=C2=A0

I suppor= t only specifying direct configuration in this document but either way maki= ng it more explicit.

I would describe [in]direct (or not) = as one aspect of discovery, and the working group has chosen to stay away f= rom discovery in this document.

OTOH as I und= erstand it discovery is the core topic of the DRIU bof, and is also on topi= c for this WG in a different document should someone propose such a thing.<= /div>

DoH isn't trying to solve that problem with th= e text under discussion - its just trying to say that the server(s) need to= be bootstrapped and not discovered via linking and pushing during unrelate= d HTTP activities. Using the word "untrusted" was a mistake becau= se it indicated more than that.

-Patrick








--00000000000072979d056d62e85b-- From nobody Tue May 29 19:19:29 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEA112E8C3 for ; Tue, 29 May 2018 19:19:27 -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 A2eqZ1EPy35V for ; Tue, 29 May 2018 19:19:25 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 3D743127419 for ; Tue, 29 May 2018 19:19:25 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id A75BC3A02A for ; Tue, 29 May 2018 22:19:24 -0400 (EDT) Received: by mail-oi0-f49.google.com with SMTP id d5-v6so11933526oib.5 for ; Tue, 29 May 2018 19:19:24 -0700 (PDT) X-Gm-Message-State: ALKqPwdJ/UWQHdaXb2vxhWJ02aMRbtdsjplU3JjgN8AH4k4rR2nOgKPi eXPVxRrWmC0z1vzwwnoCuUe7x+x2u6vXyUSCrso= X-Google-Smtp-Source: ADUXVKLy4FrBxsf9WnNUGLhS/JknhF2cRgXbO6asZu94NpKSVre9UDM2YJxx9lFdDBM6UMq8QIq2mxYJiSddodRkRDE= X-Received: by 2002:aca:1a06:: with SMTP id a6-v6mr486526oia.213.1527646764380; Tue, 29 May 2018 19:19:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Tue, 29 May 2018 19:19:23 -0700 (PDT) In-Reply-To: <20180529033519.GB18049@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <20180529033519.GB18049@mx4.yitter.info> From: Patrick McManus Date: Tue, 29 May 2018 22:19:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000bbb78b056d62fabd" Archived-At: Subject: Re: [Doh] Draft -09 and WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 02:19:28 -0000 --000000000000bbb78b056d62fabd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think my objection is that there is no assumption a client is passing anything along - much less passing it along in dns wireformat. It might cache it terminally, it might pass it along in http (in which case it would modify the Age response header as 7234 defines..), etc.. what all of these cases have in common is they need to know what the TTL of the RRset is at the time it is received, and that's what the text describes= . On Mon, May 28, 2018 at 11:35 PM, Andrew Sullivan wrote: > On Mon, May 28, 2018 at 09:40:02PM -0400, Patrick McManus wrote: > > , > > > > > > DNS API clients MUST account for the Age response header's value > > ([RFC7234]) when calculating the DNS TTL of a response. For > example, > > if a RRset is received with a DNS TTL of 600, but the Age header > > indicates that the response has been cached for 250 seconds, the > > remaining lifetime of the RRset is 350 seconds. > > > > > > the TTL. What this passage means is that the data that comes in to= a > > DNS API client _is not_ suitable to hand straight to the local stub > > subsystem: instead, some additional processing MUST be performed in > > order to ensure that TTLs are not accidentally extended by accident= . > > > > > > That's not only what it means, it seems to me that's what it says :) > > No, that's what it implies, but it's not what it says. That's > actually what I'm complaining about. The DNS is the swamp it is > partly because of the number of places in STD13 that depend on > implication rather than instruction for people to do the right thing. > A contract programmer with an alloted 18 hours will spend exactly 18 > hours, at most, to do this. So let's make it explicit. > > Perhaps this: "remaining lifetime =E2=80=A6seconds. DNS API clients SHOU= LD > NOT pass along the received DNS RRset without decrementing the TTL to > match the remaining lifetime. Doing so may accidentally prolong the > lifetime of a cached DNS RRset, and therefore ought not to be passed > along without strong evidence that the requesting client will process > the resulting cached entries correctly." > > That's awkward and needs some work. But it's at least explicit. > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000bbb78b056d62fabd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think my objection is that there is no assumption a= client is passing anything along - much less passing it along in dns wiref= ormat. It might cache it terminally, it might pass it along in http (in whi= ch case it would modify the Age response header as 7234 defines..), etc..

what all of these cases have in common is they = need to know what the TTL of the RRset is at the time it is received, and t= hat's what the text describes.

On Mon, May 28, 2018 at 11:35 PM, Andrew S= ullivan <ajs@anvilwalrusden.com> wrote:
On Mon, May 28, 2018 at 09:40:02PM -040= 0, Patrick McManus wrote:
> ,
>
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0DNS API clients MUST account for the A= ge response header's value
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0([RFC7234]) when calculating the DNS T= TL of a response.=C2=A0 For example,
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0if a RRset is received with a DNS TTL = of 600, but the Age header
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0indicates that the response has been c= ached for 250 seconds, the
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0remaining lifetime of the RRset is 350= seconds.
>
>
>=C2=A0 =C2=A0 =C2=A0the TTL.=C2=A0 What this passage means is that the = data that comes in to a
>=C2=A0 =C2=A0 =C2=A0DNS API client _is not_ suitable to hand straight t= o the local stub
>=C2=A0 =C2=A0 =C2=A0subsystem: instead, some additional processing MUST= be performed in
>=C2=A0 =C2=A0 =C2=A0order to ensure that TTLs are not accidentally exte= nded by accident.
>
>
> That's not only what it means, it seems to me that's what it s= ays :)

No, that's what it implies, but it's not what it says.=C2=A0= That's
actually what I'm complaining about.=C2=A0 The DNS is the swamp it is partly because of the number of places in STD13 that depend on
implication rather than instruction for people to do the right thing.
A contract programmer with an alloted 18 hours will spend exactly 18
hours, at most, to do this.=C2=A0 So let's make it explicit.

Perhaps this: "remaining lifetime =E2=80=A6seconds.=C2=A0 DNS API clie= nts SHOULD
NOT pass along the received DNS RRset without decrementing the TTL to
match the remaining lifetime.=C2=A0 Doing so may accidentally prolong the lifetime of a cached DNS RRset, and therefore ought not to be passed
along without strong evidence that the requesting client will process
the resulting cached entries correctly."

That's awkward and needs some work.=C2=A0 But it's at least explici= t.

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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

--000000000000bbb78b056d62fabd-- From nobody Wed May 30 07:39:13 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4E712D943 for ; Wed, 30 May 2018 07:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=FGdj2joB; dkim=pass (1024-bit key) header.d=yitter.info header.b=G4wtHY1H 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 aJDxKadgdUy3 for ; Wed, 30 May 2018 07:39:10 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9247612DA03 for ; Wed, 30 May 2018 07:39:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id E988ABDEF9 for ; Wed, 30 May 2018 14:38:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527691116; bh=uK5gDy/qFfHHwHr5HmOGzJ41zNgOuQrVm95AL5uqCXo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=FGdj2joBiOb+ueFLP7aq2FUOb6mNR/A4Xisg8fynyHIMwO8nDQey4feKA5D2eYXm3 io3c8Iz76+tMSnepQju77EkNdW9ykNAkq+APAOGuauKZzYuZH9bLGNr2ZGfPBrrXxr G7vAEgnU8c+ogZ6Hf1EzFS/bzhWoXSq5AC1FdUtc= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5inhZS_OA1I for ; Wed, 30 May 2018 14:38:35 +0000 (UTC) Date: Wed, 30 May 2018 10:38:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527691115; bh=uK5gDy/qFfHHwHr5HmOGzJ41zNgOuQrVm95AL5uqCXo=; h=Date:From:To:Subject:References:In-Reply-To:From; b=G4wtHY1HGpjLswSjtwXWxtW2lLQFQU01mXb/wnegn/7asr6bU4o3gRYB5Nmr9rOGY 7Dvr7v42yVlMSM6NBBkRrz7e1X++pJomIOYwp32DZZfICveN8o23Pdbi8g+RxizV/T l+pECyJ5UmvGN7/X7Hpt9utHt2legrw/fcxjiSN0= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180530143833.GB3110@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:39:13 -0000 Hi, On Tue, May 29, 2018 at 09:22:54PM -0400, Patrick McManus wrote: > I support only specifying direct configuration in this document but either > way making it more explicit. > > > I would describe [in]direct (or not) as one aspect of discovery, and the > working group has chosen to stay away from discovery in this document. To people who are used to the model of, "I got my resolver from DHCP," a thing you get from DHCP is not obviously "discovery". It's (auto)configuration. It's not hard to see how a hotspot portal is going to extend that metaphor using DOH, and it is still not clear to me that this text is saying, "Don't do that," though I think it might be. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed May 30 07:46: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 CCF4412D88A for ; Wed, 30 May 2018 07:46:24 -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 9M762XCMqHCq for ; Wed, 30 May 2018 07:46:23 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 2C57D12D86E for ; Wed, 30 May 2018 07:46:23 -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, 30 May 2018 07:46: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, 30 May 2018 07:46:21 -0700 From: Paul Hoffman To: Andrew Sullivan CC: "doh@ietf.org" Thread-Topic: [Ext] [Doh] A question of trust (was Re: Draft -09 and WGLC #2) Thread-Index: AQHT+CT5Axi7M/HFtUWkwFRL5Ez03w== Date: Wed, 30 May 2018 14:46:21 +0000 Message-ID: <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> In-Reply-To: <20180530143833.GB3110@mx4.yitter.info> 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] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:46:25 -0000 On May 30, 2018, at 7:38 AM, Andrew Sullivan wrote= : >=20 > Hi, >=20 > On Tue, May 29, 2018 at 09:22:54PM -0400, Patrick McManus wrote: >> I support only specifying direct configuration in this document but e= ither >> way making it more explicit. >>=20 >>=20 >> I would describe [in]direct (or not) as one aspect of discovery, and the >> working group has chosen to stay away from discovery in this document. >=20 > To people who are used to the model of, "I got my resolver from DHCP," > a thing you get from DHCP is not obviously "discovery". It's > (auto)configuration. It's not hard to see how a hotspot portal is > going to extend that metaphor using DOH, and it is still not clear to > me that this text is saying, "Don't do that," though I think it might > be. =20 The new text from the pull request is hopefully clearer: A DNS API client MUST NOT use a different URI simply because it was discove= red outside of the client's configuration, or because a server offers an unsoli= cited 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 DNS API 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. That "future specification" might come out of DRIU, or from this WG. --Paul Hoffman= From nobody Wed May 30 07:47: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 C7C2E127698 for ; Wed, 30 May 2018 07:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=EzRS8XMD; dkim=pass (1024-bit key) header.d=yitter.info header.b=Zgr3Dctr 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 MDic2xn3dV7l for ; Wed, 30 May 2018 07:47:53 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A1B12E037 for ; Wed, 30 May 2018 07:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 85FAEBDEF9 for ; Wed, 30 May 2018 14:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527691642; bh=2V22q3sCOdUAhsqWEUOzgqdaXSRf88m/00UfcutxHR4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EzRS8XMDo0b5lzR9ZhEcZMiD5QWLISSXppNV2AxR/bV+xJlf1Fu7xROwHVflBK8+i R+Iwhv44WtStolkzCwlTIag6xFmBQpJikbNDs+5Ai9nYeEbUygLeBKwCF+9SmwIJCq Rpqa+E1GihGaOUOPZxX5HRHpyx4+pHP1GjUCicF8= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BKTzVCSB1TF for ; Wed, 30 May 2018 14:47:21 +0000 (UTC) Date: Wed, 30 May 2018 10:47:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527691641; bh=2V22q3sCOdUAhsqWEUOzgqdaXSRf88m/00UfcutxHR4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Zgr3Dctr2kY2Os7y3DTfcvpVYLrQI69QKvcinMCxGCpg6NT7PqE/D1VbUtCP/mstZ m8Dlq0MUWAaCwY7sPUVAyTOn0MfTrSb4mC+f8oQcY45SWkFg6/peG8dC1PEXJOk9gK PG+fYODZ5yUZ2CHjvHNSYMDtkcBv32ZvEq+Hkjb0= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180530144718.GC3110@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <20180529033519.GB18049@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Doh] Draft -09 and WGLC #2 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 14:47:55 -0000 On Tue, May 29, 2018 at 10:19:23PM -0400, Patrick McManus wrote: > I think my objection is that there is no assumption a client is passing > anything along - much less passing it along in dns wireformat. It's probably because the "client" and "server" roles in the document feel more http-y, and less dns-y, at least to me. I think this stance is defensible, but it's not immediately obvious to a reader who comes to the document fresh. If a DNS API client is functioning as part of a general-purpose resolution stack, then it is entirely possible that it is also feeding what it gets on to other components. In the DNS, as we know, the distinction between "client" and "server" is not really the right one: the question is, for any given message, what is the role of the component sending or receiving data with respect to that message. A recursive resolver (yes, yes, a misnomer) can be thought of in that way as having a resolver side and a server side. The resolver side is going to pass on data it gets from other servers to the server side. And the resolver side itself might not be querying authoritative servers. We all know the whole thing is much more complicated than the usual neat "stub -> full-service-resolver -> authoritative server" diagram that everyone usually produces. I'm worried that failing to call attention to this here will cause implementers to believe in the simple-minded model, and then that a DNS API client will go on to feed RRsets it gets into some other subsystem. And the point is that they can't, because before doing so they need to decrement the TTL in the handed-on RRset. Anyway, that was the basis for the comment. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed May 30 08:20: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 79E9C12EABE for ; Wed, 30 May 2018 08:20:56 -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 kY3XGwQha8XP for ; Wed, 30 May 2018 08:20:53 -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 B662612EAC3 for ; Wed, 30 May 2018 08:20:53 -0700 (PDT) Received: from mail-ot0-f174.google.com (mail-ot0-f174.google.com [74.125.82.174]) by linode64.ducksong.com (Postfix) with ESMTPSA id 7B6353A042 for ; Wed, 30 May 2018 11:20:52 -0400 (EDT) Received: by mail-ot0-f174.google.com with SMTP id t1-v6so21536479ott.13 for ; Wed, 30 May 2018 08:20:52 -0700 (PDT) X-Gm-Message-State: ALKqPwdEqtiVvX+FxtnovVw5iMVAn+J8nas57tuNf5uFHjkwqX+iMoVp IKctU2/33/4SPdnYr5KcjDhtepjd9kLr51ezmzw= X-Google-Smtp-Source: ADUXVKKgCU7Tqya2OqphwwSv2WExd0E/iSM+CGaZJcgHLSp+iWlVDZimGzkso4ufrKLgB5KneXl8qDZHnz1ZnlnjOLw= X-Received: by 2002:a9d:2c64:: with SMTP id f91-v6mr1927777otb.263.1527693652198; Wed, 30 May 2018 08:20:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 30 May 2018 08:20:51 -0700 (PDT) In-Reply-To: <20180530143833.GB3110@mx4.yitter.info> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> From: Patrick McManus Date: Wed, 30 May 2018 11:20:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Sullivan Cc: DoH WG Content-Type: multipart/alternative; boundary="000000000000770bc6056d6de591" Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 15:20:57 -0000 --000000000000770bc6056d6de591 Content-Type: text/plain; charset="UTF-8" On Wed, May 30, 2018 at 10:38 AM, Andrew Sullivan wrote: > > going to extend that metaphor using DOH, and it is still not clear to > me that this text is saying, "Don't do that," though I think it might > be. > > It's not saying that (is not trying to say that?). Primarily its saying if you're browsing the web minding your own business and some site unexpectedly provides you a DoH exchange with an address for example.com don't use it unless that pushing site is one you have configured for resolution. Whether or not you do unauthenticated configuration (e.g. DHCP) is not something it takes a position on. --000000000000770bc6056d6de591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 30, 2018 at 10:38 AM, Andrew Sullivan <ajs@anvilwalrusden.com= > wrote:

going to extend that metaphor using DOH, and it is still not clear to
me that this text is saying, "Don't do that," though I think = it might
be.=C2=A0


It's not saying that= (is not trying to say that?). Primarily its saying if you're browsing = the web minding your own business and some site unexpectedly provides you a= DoH exchange with an address for example.co= m don't use it unless that pushing site is one you have configured = for resolution.

Whether or not you do unauthen= ticated configuration (e.g. DHCP) is not something it takes a position on. =
=C2=A0
--000000000000770bc6056d6de591-- From nobody Wed May 30 08:59: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 9735112E046 for ; Wed, 30 May 2018 08:59:29 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0XHN87YwDlW for ; Wed, 30 May 2018 08:59:26 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.142]) (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 8D35612E86E for ; Wed, 30 May 2018 08:59:26 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 26602 invoked from network); 30 May 2018 17:59:22 +0200 Received: from agkj186.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[217.99.137.186]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 30 May 2018 17:59:22 +0200 To: Patrick McManus , DoH WG References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <9c437a7f-a109-c9f3-ee14-b4274313563f@o2.pl> Date: Wed, 30 May 2018 17:59:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2uVL5Ovd9Ig77ze9cyisOHcGRhdQDgkvQ" X-WP-MailID: b4f37ae718618bca9a5b4eda7479c94c X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [sXPk] Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 15:59:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2uVL5Ovd9Ig77ze9cyisOHcGRhdQDgkvQ Content-Type: multipart/mixed; boundary="zL53ggyPLSW6cnHvO0JypKKOjM0zkGNGE"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Patrick McManus , DoH WG Message-ID: <9c437a7f-a109-c9f3-ee14-b4274313563f@o2.pl> Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> In-Reply-To: --zL53ggyPLSW6cnHvO0JypKKOjM0zkGNGE Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable Hello, >+A DNS API client MUST NOT use a different URI simply because it was dis= covered >+outside of the client's configuration, or because a DNS API server offe= rs an >+unsolicited response >+that appears to be a valid answer to a DNS query. The second part of this sentence is unclear to me. Some people may read i= t as prohibiting all Server Pushed messages. I would reword it as: ... or simply because some web server offers an unsolicited response that appears to be a valid answer to a DNS query. I think the previous wording in the "Security considerations" section was= much better: A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration. It only required a rewording of the section "Selection of DNS API server"= to match it. ------------------ By the way, we should clarify the section "Server push". I propose it to = read so: A DNS API client MUST ignore pushed DNS API requests (see {{RFC7540}} Section 8.2) whose pushed request URI is not one that the client would have directed the same query to if the client had initiated the request. (which is a modification of the text proposed in https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/185 and suits the comments there). Greetings, Mateusz Jo=C5=84czyk W dniu 30.05.2018 o=C2=A004:14, Patrick McManus pisze: > I've proposed https://github.com/dohwg/draft-ietf-doh-dns-over-https/pu= ll/189 >=20 > Mateusz, it also harmonizes with the security considerations a bit. --zL53ggyPLSW6cnHvO0JypKKOjM0zkGNGE-- --2uVL5Ovd9Ig77ze9cyisOHcGRhdQDgkvQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbDspZAAoJEPvWWrhhCv7GtX0QAJhhvuw/Mn+GMrQO/a6zEZz9 sT9YnOTDbC4R3D+z2ymWqcrA3T23Y4B6xgKoD89imvpjDzovUnf+6YRt1Tj32HsL JOZg2zhkI9JHl2vYyiE2MqV36BHo09lLPHV80mZ5o+IrX8yCnuugq+e15Gl7TtpW VNFWPXcGo4VOlOSRkK/BJggafjJ+gZPNrgLmEbPzlKQKp0UAj/SP+m8loVACWpZc 2RBiwU1Z/S6lVkYSwFVp3YB3eeX1ypmFNXZdryGyeSATyzieYf1O5ED2Gz0t6T5M qi84mj3/eJXi9fIvnoDBrJfltYaPBKJ/fEp0J93sFuO9mNKaPihMrRUa9HMopkpM b9cZk2VpFMJmKOY6YmP4kxZqFpsh0dkEw/ypO9k/3Uddwlc0JE1Zs6ikLOzfWWnp 6tkH8FBtSgsH8913AMN2H6tCza+ZMQAsmko/aL3gL1dCK5OX8yXTfnSKePXOh0vT vl489v2ywAnht+U7Vzr8awhP5zbfqRyNiZeXI8TcFyFRzDcpZWUcPKpZyqbEszgI A8yNPjoBBUt2LE2L8Ccx4N3ZcfhOY67AnU2bVRr63LtOPLzTE27Acxf/l32I9MwS dmm1IUFdqoJsInAzKa5hB2HpGEa/F022gGyzSHUsBQpTBbtCRdRewxFYRvkeA55j XiSwZlQtRsSdLJFB4ueD =isFS -----END PGP SIGNATURE----- --2uVL5Ovd9Ig77ze9cyisOHcGRhdQDgkvQ-- From nobody Wed May 30 09:20: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 BDAAF12E8AF for ; Wed, 30 May 2018 09:20:37 -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 KFrayBpFu7dK for ; Wed, 30 May 2018 09:20:35 -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 4BC3012E8C4 for ; Wed, 30 May 2018 09:20:35 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id B0FF53A051 for ; Wed, 30 May 2018 12:20:34 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id 14-v6so8841388oie.3 for ; Wed, 30 May 2018 09:20:34 -0700 (PDT) X-Gm-Message-State: APt69E0BiPSyc2Ro/u8hpdnixEDWHWsPfVM87DVMhPHJUxlHI4pfv5rh WuADkhI2tFErkByVEKCzpjtbJRu6ZjdD123BakI= X-Google-Smtp-Source: ADUXVKJ419gR8q5Nw811tF3bXb+4XFXTAwhKfMDodvyai4JxCCisY6NWGjQvvoF8oP+cRK8+aoB0gRNyU2UV9cTeSb4= X-Received: by 2002:aca:bec6:: with SMTP id o189-v6mr1802693oif.337.1527697234432; Wed, 30 May 2018 09:20:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a32:0:0:0:0:0 with HTTP; Wed, 30 May 2018 09:20:33 -0700 (PDT) In-Reply-To: <9c437a7f-a109-c9f3-ee14-b4274313563f@o2.pl> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <9c437a7f-a109-c9f3-ee14-b4274313563f@o2.pl> From: Patrick McManus Date: Wed, 30 May 2018 12:20:33 -0400 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= Cc: Patrick McManus , DoH WG Content-Type: multipart/alternative; boundary="000000000000fb998d056d6eba61" Archived-At: Subject: Re: [Doh] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 16:20:38 -0000 --000000000000fb998d056d6eba61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I appreciate the comments. On Wed, May 30, 2018 at 11:59 AM, Mateusz Jo=C5=84czyk = wrote: The server selection text that ended up merged is a little different than what you quoted (partly because we had a similar reaction when rereading) "A DNS API client MUST NOT use a different URI simply because it was discovered outside of the client's configuration, or because a server offers an unsolicited response that appears to be a valid answer to a DNS query." the key and clear part there is "a different URI". > I think the previous wording in the "Security considerations" section was > much > better: > A client MUST NOT use arbitrary DNS API servers. > Instead, a client MUST only use DNS > API servers specified using mechanisms such as explicit > configuration. > > While I normally favor concise (and do like your text), the feedback has been to err on the side of being more explanatory especially in justifying use of MUST NOT - so editorially I think what we have is the right thing to do and I think you did make it better by reconciling it more tightly with the server selection section. > It only required a rewording of the section "Selection of DNS API server" > to > match it. > > ------------------ > > By the way, we should clarify the section "Server push". I propose it to > read so: > > A DNS API client MUST ignore pushed DNS API requests (see > {{RFC7540}} > Section 8.2) whose pushed request URI is not one that the client > would have directed the same query to if the client had initiated > the > request. > > (which is a modification of the text proposed in > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/185 > and suits the comments there). > > Basically, my response is that this is the same as the security considerations reasoning. Its helpful to explain a little bit of rationale and highlight how this differs between push and pull.. --000000000000fb998d056d6eba61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I appreciate the comments.

On Wed, May 30, 2018 at 11:59 AM, Mateus= z Jo=C5=84czyk <mat.jonczyk@o2.pl> wrote:

=
The server selection text that ended up merged is a little different t= han what you quoted (partly because we had a similar reaction when rereadin= g)

"A DNS API client MUST NOT use a different= URI simply because it was discovered outside of the client's configuration, or because a server offers an un= solicited response that appears to be a valid answer to a DNS query."

the key and clear p= art there is "a different URI".


I think the previous wording in the "Security considerations&qu= ot; section was much
better:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 A client MUST NOT use arbitrar= y DNS API servers.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Instead, a client MUST only use DNS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 API servers specified using mechanisms such as = explicit configuration.


While I normally favor concise = (and do like your text), the feedback has been to err on the side of being = more explanatory especially in justifying use of MUST NOT - so editorially = I think what we have is the right thing to do and I think you did make it b= etter by reconciling it more tightly with the server selection section.
=

=C2=A0
It only required a rewording of the section "Selection of DNS A= PI server" to
match it.

------------------

By the way, we should clarify the section "Server push". I propos= e it to read so:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 A DNS API client MUST ignore pushed DNS API req= uests (see {{RFC7540}}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Section 8.2) whose pushed request URI is not on= e that the client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would have directed the same query to if the cl= ient had initiated the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 request.

(which is a modification of the text proposed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://g= ithub.com/dohwg/draft-ietf-doh-dns-over-https/pull/185
and suits the comments there).


Basically, my response is that this is= the same as the security considerations reasoning. Its helpful to explain = a little bit of rationale and highlight how this differs between push and p= ull..


=C2=A0


--000000000000fb998d056d6eba61-- From nobody Thu May 31 02:21: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 C841612EC81 for ; Thu, 31 May 2018 02:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSRfr8hkOSps for ; Thu, 31 May 2018 02:21:37 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3650F12EC34 for ; Thu, 31 May 2018 02:21:37 -0700 (PDT) Received: from [2001:b98:204:102:fffa::409] (port=57219) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1fOJlw-0004lL-UZ; Thu, 31 May 2018 10:21:34 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Sara Dickinson In-Reply-To: <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> Date: Thu, 31 May 2018 10:20:34 +0100 Cc: Andrew Sullivan , "doh@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.6.18) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 09:21:40 -0000 > On 30 May 2018, at 15:46, Paul Hoffman wrote: >=20 > On May 30, 2018, at 7:38 AM, Andrew Sullivan = wrote: >>=20 >> Hi, >>=20 >> On Tue, May 29, 2018 at 09:22:54PM -0400, Patrick McManus wrote: >>> I support only specifying direct configuration in this document = but either >>> way making it more explicit. >>>=20 >>>=20 >>> I would describe [in]direct (or not) as one aspect of discovery, and = the >>> working group has chosen to stay away from discovery in this = document. >>=20 >> To people who are used to the model of, "I got my resolver from = DHCP," >> a thing you get from DHCP is not obviously "discovery". It's >> (auto)configuration. It's not hard to see how a hotspot portal is >> going to extend that metaphor using DOH, and it is still not clear to >> me that this text is saying, "Don't do that," though I think it might >> be. =20 >=20 I agree with Andrew here - the document doesn=E2=80=99t define either = configuration or discovery and they are open to interpretation. A reader = who has not been privy to the repeated discussions on the mailing list = has no context within the document itself to accurately judge the = distinction. If these terms were defined it would be easy to state what = is in scope and what is out of scope and clarify the document further. = If we as a WG struggle to define them then that in itself speaks to a = lack of consensus on the problem statement. I agree the new text is clearer about the push scenario but the general = case of =E2=80=98configuration=E2=80=99 is still under specified IMHO. Sara.=20 > The new text from the pull request is hopefully clearer: >=20 > A DNS API client MUST NOT use a different URI simply because it was = discovered > outside of the client's configuration, or because a server 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 DNS API 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. >=20 > That "future specification" might come out of DRIU, or from this WG. >=20 > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Thu May 31 06:46:36 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3718512EC26 for ; Thu, 31 May 2018 06:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, 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 HA7HHAaCZAic for ; Thu, 31 May 2018 06:46:26 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 445BF12EC38 for ; Thu, 31 May 2018 06:46:24 -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; Thu, 31 May 2018 06:46:22 -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; Thu, 31 May 2018 06:46:21 -0700 From: Paul Hoffman To: Sara Dickinson , Andrew Sullivan CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) Thread-Index: AQHT+MDH1fDyXz4bL0C/ZAkrkwFDV6RKTySA Date: Thu, 31 May 2018 13:46:21 +0000 Message-ID: <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> References: <382ba525100a4561b086fe8b8b6527be@ustx2ex-dag1mb3.msg.corp.akamai.com> <603D7553-D1A9-4DCC-9E74-199059C56A9F@sinodun.com> <1daad94d-99c1-803a-f52c-1dd17adefb7a@o2.pl> <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> In-Reply-To: <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.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: <57BBB6F5691BDD4C9F3239570CEF1A15@pexch112.icann.org> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 13:46:28 -0000 T24gTWF5IDMxLCAyMDE4LCBhdCAyOjIwIEFNLCBTYXJhIERpY2tpbnNvbiA8c2FyYUBzaW5vZHVu LmNvbT4gd3JvdGU6DQo+IEkgYWdyZWUgd2l0aCBBbmRyZXcgaGVyZSAtIHRoZSBkb2N1bWVudCBk b2VzbuKAmXQgZGVmaW5lIGVpdGhlciBjb25maWd1cmF0aW9uIG9yIGRpc2NvdmVyeSBhbmQgdGhl eSBhcmUgb3BlbiB0byBpbnRlcnByZXRhdGlvbi4gQSByZWFkZXIgd2hvIGhhcyBub3QgYmVlbiBw cml2eSB0byB0aGUgcmVwZWF0ZWQgZGlzY3Vzc2lvbnMgb24gdGhlIG1haWxpbmcgbGlzdCBoYXMg bm8gY29udGV4dCB3aXRoaW4gdGhlIGRvY3VtZW50IGl0c2VsZiB0byBhY2N1cmF0ZWx5IGp1ZGdl IHRoZSBkaXN0aW5jdGlvbi4gSWYgdGhlc2UgdGVybXMgd2VyZSBkZWZpbmVkIGl0IHdvdWxkIGJl IGVhc3kgdG8gc3RhdGUgd2hhdCBpcyBpbiBzY29wZSBhbmQgd2hhdCBpcyBvdXQgb2Ygc2NvcGUg YW5kIGNsYXJpZnkgdGhlIGRvY3VtZW50IGZ1cnRoZXIuIElmIHdlIGFzIGEgV0cgc3RydWdnbGUg dG8gZGVmaW5lIHRoZW0gdGhlbiB0aGF0IGluIGl0c2VsZiBzcGVha3MgdG8gYSBsYWNrIG9mIGNv bnNlbnN1cyBvbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQuDQo+IA0KPiBJIGFncmVlIHRoZSBuZXcg dGV4dCBpcyBjbGVhcmVyIGFib3V0IHRoZSBwdXNoIHNjZW5hcmlvIGJ1dCB0aGUgZ2VuZXJhbCBj YXNlIG9mIOKAmGNvbmZpZ3VyYXRpb27igJkgaXMgc3RpbGwgdW5kZXIgc3BlY2lmaWVkIElNSE8u DQoNCldpdGhvdXQgYSBkaXNjdXNzaW9uIGhlcmUgb24gcHJvcG9zZWQgdGV4dCBhYm91dCB3aGF0 IGVpdGhlciBvZiB5b3UgdGhpbmsgY29uZmlndXJhdGlvbiBpcywgYW55IGF0dGVtcHQgdGhhdCB3 ZSBtYWtlIGhhcyBhIGhpZ2ggY2hhbmNlIG9mIG1ha2luZyB0aGUgd29yZGluZyB3b3JzZSBmb3Ig dGhlIG1ham9yaXR5LCBub3QgYmV0dGVyLiAoTXkgcGVyc29uYWwgcHJlZmVyZW5jZSBpcyB0byBk ZWZlciB0aGlzIGRpc2N1c3Npb24gdG8gRFJJVSBiZWNhdXNlIGNvbmZpZ3VyYXRpb24gaXMgYW4g aXNzdWUgZm9yIGFsbCBETlMgY2xpZW50cywgbm90IGp1c3QgdGhvc2UgdXNpbmcgRE9ILCBidXQg YW0gaGFwcHkgdG8gaGVhciBuZXcgd29yZGluZyBhcyBsb25nIGFzIHRoZSBXRyBoYXMgZW5lcmd5 IHRvIGdyaW5kIG9uIHRoaXMuKQ0KDQotLVBhdWwgSG9mZm1hbg== From nobody Thu May 31 08:12: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 D66C012E877 for ; Thu, 31 May 2018 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=PT8N/u62; dkim=pass (1024-bit key) header.d=yitter.info header.b=cEa8j6pP 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 x7TtPh8IpeQ1 for ; Thu, 31 May 2018 08:11:57 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A94126CB6 for ; Thu, 31 May 2018 08:11:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 69839BDEF9 for ; Thu, 31 May 2018 15:11:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527779516; bh=s2+RNyrCWSDURhzbGkwqjgm8taMVOm9YaSVVhxGNQls=; h=Date:From:To:Subject:References:In-Reply-To:From; b=PT8N/u62xxqIvZVc8+CPtwIRLYbdGaPLrGw0IC4MxEAk5TrPwY8l8X18+DqSc8gXQ n26tXgIHfX2V32SVHMpr2jILv2AKGTVMH3NOgKKaWFmzBbXrYqRBn1LwGFmPIMcrEI qAbbUMYrnvzlrsRlbuQJ17qX57TNUNEIo4GhGt/o= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsS8EgQ4zwbC for ; Thu, 31 May 2018 15:11:55 +0000 (UTC) Date: Thu, 31 May 2018 11:11:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527779515; bh=s2+RNyrCWSDURhzbGkwqjgm8taMVOm9YaSVVhxGNQls=; h=Date:From:To:Subject:References:In-Reply-To:From; b=cEa8j6pPpsnPzUE1s/fBWCrRvqOjBWtyl6HgpKR8UyHHEJ/R8SIT9qltMdEdqB8Gr 0OUus9PUs5Ae93zo78S3M6MZp751BFIUcmwbpSjg8uph36gcKztHOWlHoKIoumohgW 3IcL/xM54V1CZ8O5+UO3bZ251kDLY4Ow5A9aJDCQ= From: Andrew Sullivan To: doh@ietf.org Message-ID: <20180531151151.GA3060@mx4.yitter.info> References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> Archived-At: Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:11:59 -0000 Hi, On Thu, May 31, 2018 at 01:46:21PM +0000, Paul Hoffman wrote: > > Without a discussion here on proposed text about what either of you > think configuration is, I just think it needs to be clear about what is and isn't covered by configuration: is autoconf in or out? One possibility is that it's supposed to be out, and then something like "explicit configuration, excluding any autoconfiguration" would be ok. But I think some people aren't going to like that. I suspect that we haven't made up our minds about this; but it won't do to leave an ambiguity just because we can't make up our minds. Readers of this document will need to know whether only a user may on purpose set up the use of some URI, or whether the user may configure the system to get stuff automatically and thereby learn about (and subsequently use) a DNS API server. The reason I'm on about this is because I can't tell what the consequences are of the configuration being out of band. If it just means, "A user needed to go into their system and directly configure some URI," then it seems plain the user gets to make an explicit decision. But if you can autoconfigure, then that has different consequences (e.g. maybe you got the URI from your hotspot signon portal, and now a random hotspot can partly alter your resolution settings even after you've changed networks). It's ok with me that we might want to punt this to DRIU or something, but it needs to be crystal clear what meaning of "configuration" is intended. Does this make my concern clearer? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu May 31 08:18: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 C62DB127286 for ; Thu, 31 May 2018 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUaBTT--nGQH for ; Thu, 31 May 2018 08:18:40 -0700 (PDT) Received: from out.west.pexch112.icann.org (unknown [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 20BBF12EAD3 for ; Thu, 31 May 2018 08:18:40 -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; Thu, 31 May 2018 08:18:38 -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; Thu, 31 May 2018 08:18:37 -0700 From: Paul Hoffman To: Andrew Sullivan , Sara Dickinson CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) Thread-Index: AQHT+MDH1fDyXz4bL0C/ZAkrkwFDV6RKTySAgAAYGoCAAAHjAA== Date: Thu, 31 May 2018 15:18:36 +0000 Message-ID: <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> <20180531151151.GA3060@mx4.yitter.info> In-Reply-To: <20180531151151.GA3060@mx4.yitter.info> 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: <6A390DE34B8C1C4DA41A7FD2ABEC7596@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:18:43 -0000 Thanks, this does make it clearer. Proposal: move this sentence: Configuration and discovery of the URI Template is done out of band from= this protocol. up to before the first use of the word "configuration", and change it to: Configuration, discovery, and updating of the URI Template is done out of b= and from this protocol. Note that configuration might be manual (such as a = user typing URI Templatess in the UI for "options") or automatic (such as U= RI Templates being supplied in responses from DHCP or similar protocols). Is this sufficient? --Paul Hoffman= From nobody Thu May 31 11:17: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 65B84129515 for ; Thu, 31 May 2018 11:17:43 -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, FREEMAIL_FROM=0.001, 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 5X4pqesPtPte for ; Thu, 31 May 2018 11:17:40 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.140]) (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 80D4812E876 for ; Thu, 31 May 2018 11:17:40 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 20844 invoked from network); 31 May 2018 20:17:38 +0200 Received: from ackl73.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.87.73]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 31 May 2018 20:17:38 +0200 From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> <20180531151151.GA3060@mx4.yitter.info> <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> Openpgp: preference=signencrypt Message-ID: <94972b71-49ec-619a-b6dd-4822a7725e28@o2.pl> Date: Thu, 31 May 2018 20:17:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i8jFucaf9SRBQTQmsBmLMDBQSiN2ph9AU" X-WP-MailID: 4f3197d8a969cfa838b0225b45a0733a X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 000000A [ofN0] Archived-At: Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 18:17:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --i8jFucaf9SRBQTQmsBmLMDBQSiN2ph9AU Content-Type: multipart/mixed; boundary="MxMLmSVe23e5o1EIy2AiDvv1DOoI10oJn"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: DoH WG Message-ID: <94972b71-49ec-619a-b6dd-4822a7725e28@o2.pl> Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> <20180531151151.GA3060@mx4.yitter.info> <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> In-Reply-To: <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> --MxMLmSVe23e5o1EIy2AiDvv1DOoI10oJn Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable W dniu 31.05.2018 o=C2=A017:18, Paul Hoffman pisze: > Thanks, this does make it clearer. Proposal: move this sentence: > Configuration and discovery of the URI Template is done out of band = from this protocol. > up to before the first use of the word "configuration",=20 > and change it to: >=20 > Configuration, discovery, and updating of the URI Template is done out = of band from this protocol. Note that configuration might be manual (such= as a user typing URI Templatess in the UI for "options") or automatic (s= uch as URI Templates being supplied in responses from DHCP or similar pro= tocols). >=20 +1 to general idea. I think that this sentence should follow the first sentence in the sectio= n "Selection of DNS API Server" and be slightly modified: A DNS API client uses configuration to select the URI, and thus the DNS API server, that is to be used for resolution. Configuration, discovery, and updating of the URI is done out =09 of band from this protocol. Note that configuration might be manual (such as a user typing URI Templates in the UI for "options") or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). [RFC2818] defines how HTTPS verifies the DNS API server's identity. > Is this sufficient? >=20 > --Paul Hoffman > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh >=20 --MxMLmSVe23e5o1EIy2AiDvv1DOoI10oJn-- --i8jFucaf9SRBQTQmsBmLMDBQSiN2ph9AU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbEDxBAAoJEPvWWrhhCv7Gj6MP/0PJbS3sdyzC2xS0Sclj7aJy JdqBKRN2E0friHDIthsAq+7kFpFPVIqHxq0u6K28ppjzW6XD4j936EExvhPebJOI B3YecJ2FWmcTD0kBo2ORBWHBHu89I/W2t+CiXXBzUq1/Bzq+GWYquIW03CKX3xF0 UkZyWQz6Bf4Cv+j5N+9fXcTx1KpYK+kyZ5aH6Tqbq6jJhxoFiXu/2yWnQAFcGa4m 81mqzP88xD6T6vr7SBJuxxcKFFnVlibYPhQZKZmpNBj3ZlJmUXzKRaysPOYIT/GV vzK4fGSgXEBN3fdZ6ojo7J8C2Hpyct+2HoSGyga/kGQk+Iji96qeOrTSX6iXL8WM sGu4IrtZ655Tpm9vpT592gneiJAkMWD0ofUAHn89J9uAz8KOpQy6bFDvcXp3t9+N a9cXt7ET4MEVdSHLEmSGx+eYuaKEGDr8+EcFLWQ06y39NMAZ+Cc0HDJZIHTPXHEg 9jSPTBvSgTS/jSA7F+hzoklcC50qYIkMNheLE+7pxZo5/jtgY7VFW55RHLhMeHTX p632iuuoY1/JCgHu+xeUdaEqptvFosdG/uSzgdGGSjH+eC4bCwXbDE09BHwgzUKP 9nTZ6TG8brA1F5Q9uwMbDY6XWJ7es4X1khUuQyp8cUeMTvoWB+xPG/Zb4i7VwpcK HKR5SPfkSqZyr+T/+ZO9 =g5YN -----END PGP SIGNATURE----- --i8jFucaf9SRBQTQmsBmLMDBQSiN2ph9AU-- From nobody Thu May 31 11:17:59 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 9B50412EB86; Thu, 31 May 2018 11:17:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: doh@ietf.org, adam@nostrum.com, tale@dd.org, doh-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152779066956.12140.1433546805600205825.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2018 11:17:49 -0700 Archived-At: Subject: [Doh] doh - Not having a session at IETF 102 X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 18:17:56 -0000 David Lawrence, a chair of the doh working group, indicated that the doh working group does not plan to hold a session at IETF 102. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu May 31 14:56:29 2018 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C55133260 for ; Thu, 31 May 2018 14:56:27 -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 K5ijr4n0ETcz for ; Thu, 31 May 2018 14:56:25 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 27D9A131913 for ; Thu, 31 May 2018 14:56:25 -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; Thu, 31 May 2018 14:56:22 -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; Thu, 31 May 2018 14:56:22 -0700 From: Paul Hoffman To: Andrew Sullivan , Sara Dickinson CC: "doh@ietf.org" Thread-Topic: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) Thread-Index: AQHT+MDH1fDyXz4bL0C/ZAkrkwFDV6RKTySAgAAYGoCAAAHjAIAAbyIA Date: Thu, 31 May 2018 21:56:22 +0000 Message-ID: References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> <20180531151151.GA3060@mx4.yitter.info> <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> In-Reply-To: <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> 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] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 21:56:28 -0000 I have submitted this as a pull request: https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/190 I actually moved the whole paragraph (not just the sentence) up before addi= ng the clarifications about updating config and config examples. --Paul Hoffman= From nobody Thu May 31 15:46: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 B9DA612EB75 for ; Thu, 31 May 2018 15:46:47 -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, FREEMAIL_FROM=0.001, 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 FLHDGtsmUdd7 for ; Thu, 31 May 2018 15:46:45 -0700 (PDT) Received: from mx-out.tlen.pl (mx-out.tlen.pl [193.222.135.148]) (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 DA27212EC4A for ; Thu, 31 May 2018 15:46:44 -0700 (PDT) Received: (wp-smtpd smtp.tlen.pl 30830 invoked from network); 1 Jun 2018 00:46:41 +0200 Received: from ackl73.neoplus.adsl.tpnet.pl (HELO [192.168.1.22]) (mat.jonczyk@o2.pl@[83.10.87.73]) (envelope-sender ) by smtp.tlen.pl (WP-SMTPD) with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP for ; 1 Jun 2018 00:46:41 +0200 To: Paul Hoffman , DoH WG References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> <20180531151151.GA3060@mx4.yitter.info> <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= Openpgp: preference=signencrypt Message-ID: <33a91d37-10ca-c43b-ec55-a63e3bb956e7@o2.pl> Date: Fri, 1 Jun 2018 00:45:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="j8hrZcCHyd2LYNOd19Wcyh6JTWuOTeUqq" X-WP-MailID: 353989db2b75d83d54ae833dac3192ed X-WP-AV: skaner antywirusowy Poczty o2 X-WP-SPAM: NO 0000000 [kYOU] Archived-At: Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 22:46:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j8hrZcCHyd2LYNOd19Wcyh6JTWuOTeUqq Content-Type: multipart/mixed; boundary="ClFrTnBPLbXAMnA2sYuSAa0mX9UzwvvqL"; protected-headers="v1" From: =?UTF-8?Q?Mateusz_Jo=c5=84czyk?= To: Paul Hoffman , DoH WG Message-ID: <33a91d37-10ca-c43b-ec55-a63e3bb956e7@o2.pl> Subject: Re: [Doh] [Ext] A question of trust (was Re: Draft -09 and WGLC #2) References: <20180528161043.GB12038@mx4.yitter.info> <20180530143833.GB3110@mx4.yitter.info> <197F1CB0-DFA5-4720-94E0-223D708B0D79@icann.org> <3920ACC9-D167-4E2C-88E7-7A2AB317EA16@sinodun.com> <33BE0098-C168-4B75-9B8F-D31AB45749AA@icann.org> <20180531151151.GA3060@mx4.yitter.info> <54C8B3CF-55EF-48F9-87FD-A38913D2C4FB@icann.org> In-Reply-To: --ClFrTnBPLbXAMnA2sYuSAa0mX9UzwvvqL Content-Type: text/plain; charset=utf-8 Content-Language: pl Content-Transfer-Encoding: quoted-printable Please note that "URI Template" is specified later in the text (in "The H= TTP Request") and its usage is not clear in section "Selection of DNS API Ser= ver"). This term should be explained in "Selection of DNS API Server", e.g.: Configuration, discovery, and updating of the URI Template (and thus the= DNS API server) is done out of band from this ... Other that that, the pull request is OK to me. Greetings, Mateusz =09 W dniu 31.05.2018 o=C2=A023:56, Paul Hoffman pisze: > I have submitted this as a pull request: > https://github.com/dohwg/draft-ietf-doh-dns-over-https/pull/190 > I actually moved the whole paragraph (not just the sentence) up before = adding the clarifications about updating config and config examples. >=20 > --Paul Hoffman --ClFrTnBPLbXAMnA2sYuSAa0mX9UzwvvqL-- --j8hrZcCHyd2LYNOd19Wcyh6JTWuOTeUqq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJbEHtPAAoJEPvWWrhhCv7GBEQQAJHqmuIQYH1u7nAa4cOOcNqC uFDqEI9thr8TQuLDUsEb2KOtFAiMnQcD6x7MgkwTaBCypFPRrzA9bVrj9hsowddu fKJHu+uQmj1R4DUiRnxNwyrTDJs6u1+9tqKxFN4+MmCF3+/I33XSJhDqlEDOWdE8 gpX+naho+vFOSa6FwJrKACJOOSGMQSZ+ZLiGAjkh7qdWlLCbSTt/hbePNRd6MOGw 7IEw8gKGFL+w0Lb5nkrLyHvo3EYDBY0Lv1Hv5qqxZdWqMuPMXD1CYI1zPD2c5cdv kjpnShgHIFcT0zLSp+jFsrf7gONSG5A/hPaQfc/A5kkHlYLuFWRvx+PB7eRWkGso LE+wu1GL3Dm4+K65aSh1tNFVhQjrcX8jf+FYsLxJhm77WPuqkNGh3kbkDybpAYP4 cE9TLhaCNgA65FMFfJkusrgLv4EY4HsTN4yhUn9ssv0NBpHoi9J2LXLwg2D8YZLL T4gf37JtuQ1UBLEIHz3IeqAB0ZyRln++Pv0GkvEM0goZ8QjK7+tXAMVm9+BwhxE/ GwYCr4zjG55fPtQoGNjhQXAM6mo4QfTwmKxrG3/AiIlNOKOjyGUQyh+udR5Gv4Wb 8tcD79e9Mo4X/fiIICumfSf0Oe4hNfR5XmHfcoF20iCpoM+QT+gKSL/iZUAPWEQI US+odhdMmAJ/jseBLJyz =kZvz -----END PGP SIGNATURE----- --j8hrZcCHyd2LYNOd19Wcyh6JTWuOTeUqq--