From nobody Mon Sep 11 08:38:00 2017 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 1589613219F; Sat, 9 Sep 2017 10:45:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150497915406.8167.17608149948148839208.idtracker@ietfa.amsl.com> Date: Sat, 09 Sep 2017 10:45:54 -0700 Archived-At: X-Mailman-Approved-At: Mon, 11 Sep 2017 08:37:59 -0700 Subject: [Doh] Eric Rescorla's Block on charter-ietf-doh-00-00: (with BLOCK and COMMENT) 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: Sat, 09 Sep 2017 17:45:54 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-doh-00-00: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- This charter seems oddly agnostic on whether or not we are defining use over HTTP or over HTTPS. In 2017, I think its imperative that this only be chartered for secure transports (which is, after all, implicit in the value proposition). I agree with Martin Thomson that "HTTPS" is the right way to convey this point. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think I agree with MT's point that it would be best if this binding were agnostic about HTTP/2 over TLS versus HTTPS over QUIC (or whatever we call it) and to the extent possible, agnostic about HTTP/2 versus HTTP/1.1 (i.e., the binding should be indifferent for the functionality that don't depend on explicit HTTP/2 features like push). However, I think we could send the charter out for review w/o deciding that. From nobody Mon Sep 11 12:59:08 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA1B13239C; Mon, 11 Sep 2017 12:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvDmzzjPxQrC; Mon, 11 Sep 2017 12:59:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280CE132339; Mon, 11 Sep 2017 12:59:02 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8BJx0L3070590 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 11 Sep 2017 14:59:01 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Eric Rescorla , The IESG Cc: doh@ietf.org, doh-chairs@ietf.org References: <150497915406.8167.17608149948148839208.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Mon, 11 Sep 2017 14:59:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150497915406.8167.17608149948148839208.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Eric Rescorla's Block on charter-ietf-doh-00-00: (with BLOCK and COMMENT) 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, 11 Sep 2017 19:59:06 -0000 On 9/9/17 12:45 PM, Eric Rescorla wrote: > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > This charter seems oddly agnostic on whether or not we are defining > use over HTTP or over HTTPS. In 2017, I think its imperative that this > only be chartered for secure transports (which is, after all, implicit > in the value proposition). I agree with Martin Thomson that "HTTPS" > is the right way to convey this point. The charter text had used "HTTP" only where it was an adjective (e.g., "HTTP semantics"), and "HTTPS" everywhere else.  Although it sounds a bit odd to my ear, the latest revision refers to "HTTPS infrastructure," "HTTPS clients," "HTTPS semantics," and "HTTPS protocol". /a From nobody Mon Sep 11 13:42:34 2017 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 A6E1C1331A3; Mon, 11 Sep 2017 12:34:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.60.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150515848463.9707.1920349366631392428.idtracker@ietfa.amsl.com> Date: Mon, 11 Sep 2017 12:34:44 -0700 Archived-At: X-Mailman-Approved-At: Mon, 11 Sep 2017 13:42:33 -0700 Subject: [Doh] Spencer Dawkins' No Objection on charter-ietf-doh-00-00: (with COMMENT) 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: Mon, 11 Sep 2017 19:34:45 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-doh-00-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Eric's BLOCK, that this charter should be really clear about HTTPS expectations. If I was chairing this working group, I'd want to know whether specifying HTTP was in scope, up front. I'm pretty sure I know what the answer is going to be, but I'll let people who understand more about DNS usage have that conversation before I express an opinion. From nobody Wed Sep 13 17:14:33 2017 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 C3E21132F69; Wed, 13 Sep 2017 17:08:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150534773677.12640.757356084092038546.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 17:08:56 -0700 Archived-At: X-Mailman-Approved-At: Wed, 13 Sep 2017 17:14:31 -0700 Subject: [Doh] Terry Manderson's Block on charter-ietf-doh-00-03: (with BLOCK) 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, 14 Sep 2017 00:08:57 -0000 Terry Manderson has entered the following ballot position for charter-ietf-doh-00-03: Block When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I would very much like to see explicit text in the charter that reinforces the need for cross area review to INT area for DNS semantics and also to OPS (not speaking for the OPS ADs) for operational impacts of DNS over HTTPS on the aspects where normal/expected host (stub resolver->recursive resolver) behaviours are altered through browser HTTPS over DNS resolution. From nobody Wed Sep 13 17:25:22 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C614513213D; Wed, 13 Sep 2017 17:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3NjoUfRtye9; Wed, 13 Sep 2017 17:25:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A950127005; Wed, 13 Sep 2017 17:25:13 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8E0Oq7A006968 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 13 Sep 2017 19:24:52 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Terry Manderson , The IESG Cc: doh@ietf.org, doh-chairs@ietf.org References: <150534773677.12640.757356084092038546.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <337e6c06-ea81-b0c8-0a53-3d3741491152@nostrum.com> Date: Wed, 13 Sep 2017 19:24:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150534773677.12640.757356084092038546.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Terry Manderson's Block on charter-ietf-doh-00-03: (with BLOCK) 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, 14 Sep 2017 00:25:16 -0000 On 9/13/17 7:08 PM, Terry Manderson wrote: > I would very much like to see explicit text in the charter that reinforces the > need for cross area review to INT area for DNS semantics and also to OPS (not > speaking for the OPS ADs) for operational impacts of DNS over HTTPS on the > aspects where normal/expected host (stub resolver->recursive resolver) > behaviours are altered through browser HTTPS over DNS resolution. Would adding the following text be adequate? > The working group will coordinate with the DNSOP and INTAREA working > groups for input on DNS-over-HTTPS's impact on DNS operations and DNS > semantics, respectvely. In particular, DNSOP will be consulted for > guidance on the operational impacts that result from traditional host > behaviors (i.e., stub-resolver to recursive-resolver interaction) > being replaced with the specified mechanism. /a From nobody Thu Sep 14 06:08:09 2017 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 6B3A51321CB; Thu, 14 Sep 2017 05:54:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alvaro Retana To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539368740.12565.870212526594777830.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 05:54:47 -0700 Archived-At: X-Mailman-Approved-At: Thu, 14 Sep 2017 06:08:09 -0700 Subject: [Doh] Alvaro Retana's No Objection on charter-ietf-doh-00-04: (with COMMENT) 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, 14 Sep 2017 12:54:47 -0000 Alvaro Retana has entered the following ballot position for charter-ietf-doh-00-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a couple of nits: (1) s/data may used/data may be used (2) Given that the milestones reflect the intended date for completion, I don't think it is necessary to also include the date in the charter text. From nobody Thu Sep 14 07:33:36 2017 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 5CB4A132355; Thu, 14 Sep 2017 06:58:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539750133.12561.3666174772720186500.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 06:58:21 -0700 Archived-At: X-Mailman-Approved-At: Thu, 14 Sep 2017 07:33:35 -0700 Subject: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-05: (with COMMENT) 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, 14 Sep 2017 13:58:21 -0000 Benoit Claise has entered the following ballot position for charter-ietf-doh-00-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- What I've been failing to understand from the charter is the rational for DNS over HTTPS? Can you expand on this. My first reaction was: is it because HTTP(S) became the new transport? But obviously not. So instead of fixing a DNS issue with UDP/TCP/DTLS, we're going to offer yet another choice (with, I guess, a different source of truth?) Do we need to mention the connection with DNSSEC? Why not DPRIV? From nobody Thu Sep 14 07:33:42 2017 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 D4DC3132335; Thu, 14 Sep 2017 07:13:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150539842586.12537.10469544387783752570.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 07:13:45 -0700 Archived-At: X-Mailman-Approved-At: Thu, 14 Sep 2017 07:33:35 -0700 Subject: [Doh] Eric Rescorla's No Objection on charter-ietf-doh-00-05: (with COMMENT) 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, 14 Sep 2017 14:13:46 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-doh-00-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think I agree with MT's point that it would be best if this binding were agnostic about HTTP/2 over TLS versus HTTPS over QUIC (or whatever we call it) and to the extent possible, agnostic about HTTP/2 versus HTTP/1.1 (i.e., the binding should be indifferent for the functionality that don't depend on explicit HTTP/2 features like push). However, I think we could send the charter out for review w/o deciding that. From nobody Thu Sep 14 07:41:40 2017 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 EE92513302B; Thu, 14 Sep 2017 07:41:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Terry Manderson To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150540009893.12591.6850071771578231302.idtracker@ietfa.amsl.com> Date: Thu, 14 Sep 2017 07:41:38 -0700 Archived-At: Subject: [Doh] Terry Manderson's No Objection on charter-ietf-doh-00-05: (with COMMENT) 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, 14 Sep 2017 14:41:39 -0000 Terry Manderson has entered the following ballot position for charter-ietf-doh-00-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the added text. From nobody Fri Sep 15 09:45:34 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2D1321D8; Fri, 15 Sep 2017 09:45:33 -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 4CXPkOBptwHI; Fri, 15 Sep 2017 09:45:30 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CB913209C; Fri, 15 Sep 2017 09:45:30 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id r141so2600421qke.2; Fri, 15 Sep 2017 09:45:30 -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=MeYog05+MGKZxcs98gXl0GlhxcJ4zGqkj3TsawU0dpw=; b=BNd7xxLHePsVoMLsmPP4OlxOn8dSH1Aso3mFhen2+FCS7AHQ7RXnqSCQSbtuxh7MF9 KvoLBbc3pCQCuYsihFCu0ICsehR3vJrAPfHqTBauM+txJSPSSu17So2OBrI5AMMyS9vz DKXE9ye8McTQCBq4ZhYGtSNSXyHG7jq6j5WWLT6kEg4oVATTKXzeUFjKcVI65YVErpeu VVpGeYKTQgmO22dpTdhUAEcHcn+lILOMnRS8KyA5vUdMK4j78CJUmnFKH/TSe+avUfPy jtPeZ+JnyX2pdB1nuVbJNq0325egTx2oWYV/d74aXDO+kp4Bp6SoABD4924HqgfpZJzu 9kfQ== 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=MeYog05+MGKZxcs98gXl0GlhxcJ4zGqkj3TsawU0dpw=; b=CosJHTwkPxhE9XJtylugoAZemg4lO3YmgxMdM4/YdVN05s/dCwFWyvxLviwzmffNRs 7RxMlMTM0939IxBIfen6hLVBR6Nt77d0Ce8tH26EcSKQ5qvPJPUMY6k1se81jPQCq5Hf /it+YxeT4QfJSAV5wt1+PTcADPhv+LCIVL4Yxboi2oKORa8aCPZ5HiES1uij6n/Z+YRg rJGcnqbaDfg6B0EyBJxRJ/UF/Cyz7XcXcxZX4UVS9t20n/LSmadxzdbKMSYHJoeRYBk+ B7XfmJgnVnJhPGMCNdh+r8evo/k3ufQZIpbdBPZuUeLQPl78686f3JsT06Z7GxmqAkVJ vR3g== X-Gm-Message-State: AHPjjUh20lx1CoILvv40n2J18242gJX07kicwMV05wKlxoOkKYfqfEVR VIH53flSdXsSDwb8Wlc0BXuAbgr2e1rRrzerWWzAuA== X-Google-Smtp-Source: AOwi7QDFKPFAxVuSM8x9lGeiOpBV+4KmnnRSYZQUuWjPJSZvhuOh1nG4NPQgZ0JO5CPREdT9IsrjIyVTOA8dtfg/Pbo= X-Received: by 10.55.52.19 with SMTP id b19mr8113450qka.218.1505493928997; Fri, 15 Sep 2017 09:45:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Fri, 15 Sep 2017 09:44:58 -0700 (PDT) In-Reply-To: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Ted Hardie Date: Fri, 15 Sep 2017 09:44:58 -0700 Message-ID: To: IETF Cc: doh@ietf.org Content-Type: multipart/alternative; boundary="001a1147957ed9798e05593d1ef3" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 16:45:33 -0000 --001a1147957ed9798e05593d1ef3 Content-Type: text/plain; charset="UTF-8" Howdy, There are a couple of points that I'd like to raise here. On Fri, Sep 15, 2017 at 8:44 AM, The IESG wrote: > A new IETF WG has been proposed in the Applications and Real-Time Area. The > IESG has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your > comments to the IESG mailing list (iesg@ietf.org) by 2017-09-25. > > DNS Over HTTPS (doh) > ----------------------------------------------------------------------- > Current status: Proposed WG > > Chairs: > TBD > > Assigned Area Director: > Adam Roach > > Applications and Real-Time Area Directors: > Adam Roach > Ben Campbell > Alexey Melnikov > > Mailing list: > Address: doh@ietf.org > To subscribe: https://www.ietf.org/mailman/listinfo/doh > Archive: https://mailarchive.ietf.org/arch/browse/doh/ > > Group page: https://datatracker.ietf.org/group/doh/ > > Charter: https://datatracker.ietf.org/doc/charter-ietf-doh/ > > This working group will standardize encodings for DNS queries and responses > that are suitable for use in HTTPS. This will enable the domain name system > to function over certain paths where existing DNS methods (UDP, TLS, and > DTLS) > experience problems. The working group will re-use HTTPS methods, error > codes, and other semantics to the greatest extent possible. The use of > HTTPS > provides integrity and confidentiality, and it also allows the transport to > interoperate with common HTTPS infrastructure and policy. > > I appreciate the charter's use of "HTTPS" as a signal that these are intended to be TLS-protected HTTP sessions. I note, however, that there is considerable ambiguity still present. HTTPS can mean HTTP 1.1 over TLS, HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon (in some deployments it already means that). The document named as input specifies HTTP/2 over TLS. While the working group may, of course, change that to support HTTP 1.1 and/or QUIC, it might be useful for the charter to indicate which of these is potentially in scope. If the community is sure now that HTTP over QUIC is in scope, for example, having that noted in the charter by adding the QUIC working group to list of working groups to consult would be useful. I will confess a bias here: while I think it is useful to match the capability set of HTTP over QUIC to that of HTTP over other transports as much as possible, I think making that a key part of this work is not a good initial direction. For one thing, there are some aspects of the QUIC transport that are still in discussion, and I think it will slow this work a bit to track those. More importantly, though, I think this would be the wrong way to do DNS over QUIC (draft-huitema-quic-dnsoquic-00 shows a different approach). Having QUIC be an early focus here may solidify an approach that is simple, but not nearly as complete as we could deliver with a DNS over QUIC. (This is in part because of the choice to use the udp wireformat as the baseline HTTP response here, rather than specifying DNS responses over a transport construct like a QUIC stream. The working group could, of course, change that, but it would seriously shift the direction of its input document to do so). The working group will coordinate with the DNSOP and INTAREA working groups > for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, > respectvely. In particular, DNSOP will be consulted for guidance on the > operational impacts that result from traditional host behaviors (i.e., > stub-resolver to recursive-resolver interaction) being replaced with the > specified mechanism. > > Specification of how the DNS data may be used for new use cases, and > the discovery of the DOH servers, are out of scope for the working group. > > While it is useful to know that discovery is out of scope here, I think having a quick community discussion now of where it might be in scope is useful. There are some potentially interesting questions buried in that, especially in how we expect interworking with existing systems to go. Note that even if the service discovery method provides an HTTPS URI for the name server, the questions above related to HTTP version or transport may bite you. For server discovery based on address and port, the situation is much the same unless the port is clearly marked as TCP or UDP. And if the server discovery includes no port at all, then a happy eyeballs type method may be needed. This may all fall into a combo of DHCP and DNSOP work, but giving somewhat clean lines for it now seems like it will make the later work go faster. > The working group will use draft-hoffman-dispatch-dns-over-https as input. > > Milestones: > > Apr 2018 - Submit specification for performing DNS queries over HTTPS to > the IESG for publication as PS > > I admire the optimism in this. regards, Ted Hardie --001a1147957ed9798e05593d1ef3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

There are a couple of points that= I'd like to raise here.
<= br>
On Fri, Sep 15, 2017 at 8:44 AM, The IESG <iesg-secretary@ietf.org> wrote:
A new IETF WG has been proposed in the Applica= tions and Real-Time Area. The
IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send you= r
comments to the IESG mailing list (iesg@ie= tf.org) by 2017-09-25.

DNS Over HTTPS (doh)
-----------------------------------------------------------------= ------
Current status: Proposed WG

Chairs:
=C2=A0 TBD

Assigned Area Director:
=C2=A0 Adam Roach <adam@nostrum.com<= /a>>

Applications and Real-Time Area Directors:
=C2=A0 Adam Roach <adam@nostrum.com<= /a>>
=C2=A0 Ben Campbell <ben@nostrum.com<= /a>>
=C2=A0 Alexey Melnikov <aameln= ikov@fastmail.fm>

Mailing list:
=C2=A0 Address: doh@ietf.org
=C2=A0 To subscribe: https://www.ietf.org/mailman/list= info/doh
=C2=A0 Archive: https://mailarchive.ietf.org/arch/= browse/doh/

Group page: https://datatracker.ietf.org/group/doh/<= br>
Charter: https://datatracker.ietf.org/doc/cha= rter-ietf-doh/

This working group will standardize encodings for DNS queries and responses=
that are suitable for use in HTTPS. This will enable the domain name system=
to function over certain paths where existing DNS methods (UDP, TLS, and DT= LS)
experience problems.=C2=A0 The working group will re-use HTTPS methods, err= or
codes, and other semantics to the greatest extent possible.=C2=A0 The use o= f HTTPS
provides integrity and confidentiality, and it also allows the transport to=
interoperate with common HTTPS infrastructure and policy.


I appreciate the charter's use of = "HTTPS" as a signal that these are intended to be TLS-protected H= TTP sessions.=C2=A0 I note, however, that there is considerable ambiguity s= till present.=C2=A0 HTTPS can mean HTTP 1.1 over TLS, HTTP/2 over TLS, and = it may mean HTTP over QUIC at some point soon (in some deployments it alrea= dy means that).=C2=A0 The document named as input specifies HTTP/2=C2=A0 ov= er TLS.=C2=A0 While the working group may, of course, change that to suppor= t HTTP 1.1 and/or QUIC, it might be useful for the charter to indicate whic= h of these is potentially in scope.=C2=A0 If the community is sure now that= HTTP over QUIC is in scope, for example, having that noted in the charter = by adding the QUIC working group to list of working groups to consult would= be useful.

I will confess a bias here: while I think it = is useful to match the capability set of HTTP over QUIC to that of HTTP ove= r other transports as much as possible, I think making that a key part of t= his work is not a good initial direction.=C2=A0 For one thing, there are so= me aspects of the QUIC transport that are still in discussion, and I think = it will slow this work a bit to track those.=C2=A0 More importantly, though= , I think this would be the wrong way to do DNS over QUIC (draft-huitema-qu= ic-dnsoquic-00 shows a different approach).=C2=A0 Having QUIC be an early f= ocus here may solidify an approach that is simple, but not nearly as comple= te as we could deliver with a DNS over QUIC.

(This is in = part because of the choice to use the udp wireformat as the baseline HTTP r= esponse here, rather than specifying DNS responses over a transport constru= ct like a QUIC stream.=C2=A0 The working group could, of course, change tha= t, but it would seriously shift the direction of its input document to do s= o).


The working group will coordinate with the DNSOP and INTAREA working groups=
for input on DNS-over-HTTPS's impact on DNS operations and DNS semantic= s,
respectvely. In particular, DNSOP will be consulted for guidance on the
operational impacts that result from traditional host behaviors (i.e.,
stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism.

Specification of how the DNS data may be used for new use cases, and
the discovery of the DOH servers, are out of scope for the working group.

While it is useful to know that discov= ery is out of scope here, I think having a quick community discussion now o= f where it might be in scope is useful.=C2=A0 There are some potentially in= teresting questions buried in that, especially in how we expect interworkin= g with existing systems to go.=C2=A0=C2=A0 Note that even if the service di= scovery method provides an HTTPS URI for the name server, the questions abo= ve related to HTTP version or transport may bite you.=C2=A0 For server disc= overy based on address and port, the situation is much the same unless the = port is clearly marked as TCP or UDP.=C2=A0 And if the server discovery inc= ludes no port at all, then a happy eyeballs type method may be needed.=C2= =A0

This may all fall into a combo of DHCP and DNSOP work, but givi= ng somewhat clean lines for it now seems like it will make the later work g= o faster.
=C2=A0
The working group will use draft-hoffman-dispatch-dns-over-https as in= put.

Milestones:

=C2=A0 Apr 2018 - Submit specification for performing DNS queries over HTTP= S to
=C2=A0 the IESG for publication as PS


I admire the optimism in this.

=
regards,

Ted Hardie

=
--001a1147957ed9798e05593d1ef3-- From nobody Fri Sep 15 11:46:44 2017 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 732CC132713; Fri, 15 Sep 2017 08:44:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Cc: doh@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> Date: Fri, 15 Sep 2017 08:44:53 -0700 Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 11:46:42 -0700 Subject: [Doh] WG Review: DNS Over HTTPS (doh) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 15:44:53 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2017-09-25. DNS Over HTTPS (doh) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Adam Roach Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Mailing list: Address: doh@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/doh Archive: https://mailarchive.ietf.org/arch/browse/doh/ Group page: https://datatracker.ietf.org/group/doh/ Charter: https://datatracker.ietf.org/doc/charter-ietf-doh/ This working group will standardize encodings for DNS queries and responses that are suitable for use in HTTPS. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) experience problems. The working group will re-use HTTPS methods, error codes, and other semantics to the greatest extent possible. The use of HTTPS provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTPS infrastructure and policy. The working group will coordinate with the DNSOP and INTAREA working groups for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, respectvely. In particular, DNSOP will be consulted for guidance on the operational impacts that result from traditional host behaviors (i.e., stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism. Specification of how the DNS data may be used for new use cases, and the discovery of the DOH servers, are out of scope for the working group. The working group will use draft-hoffman-dispatch-dns-over-https as input. Milestones: Apr 2018 - Submit specification for performing DNS queries over HTTPS to the IESG for publication as PS From nobody Fri Sep 15 11:46:49 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F330133050; Fri, 15 Sep 2017 10:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEl8IxAnscL6; Fri, 15 Sep 2017 10:24:44 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9588F13309D; Fri, 15 Sep 2017 10:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1505496283; x=1506705883; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=jLXmHlk8uGFwzaoOS6dlNVHJcjBiRzUF1Ji5Z7dTi+Y=; b=DHEQ/X/yxbUrV2ADOeHNWBf/6JABdJ6AlYmNhvsJkJHWdDdP7Zuvkf22 VpDRnUjlMD45oKuBk/jcQ8J8GPs5hYXmaOGbC8H5yTT9w/cm/Qz5LfMOc ZNsUI9q4D3rKWyRi6usNKD3f6abpcxAiTarEfojP1bF+0ZirPX7FU0KE3 E=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgCSDLxZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD5uhByLFJBICSKWJ4ISBwOFPAKEaxYBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BI1YQCxgqAgJXEwgBAYonCKt7gieLLQEBAQEGAQEBARUPgyuFNSsLgnKEYmKCR?= =?us-ascii?q?4JgBZEvj1aEOYIhjXuLV4chlTSBOSYCL0FMMiEIHBWHZz6JSwEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,398,1500940800"; d="asc'?scan'208";a="697215963" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Sep 2017 17:24:27 +0000 Received: from [10.61.209.107] ([10.61.209.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8FHOQE9001663; Fri, 15 Sep 2017 17:24:26 GMT To: ietf@ietf.org Cc: doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Eliot Lear Message-ID: Date: Fri, 15 Sep 2017 19:24:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cV2fCVtPUQS9CCHmuk7WX4PuBdPcfSa6B" Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 11:46:42 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 17:24:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cV2fCVtPUQS9CCHmuk7WX4PuBdPcfSa6B Content-Type: multipart/mixed; boundary="EKTLLdAF8OMqLIBMU3tfbSWaCCUhmGR1Q"; protected-headers="v1" From: Eliot Lear To: ietf@ietf.org Cc: doh@ietf.org Message-ID: Subject: Re: WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> In-Reply-To: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> --EKTLLdAF8OMqLIBMU3tfbSWaCCUhmGR1Q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, I have no objection to a WG forming, but I have some concerns about the charter. On 9/15/17 5:44 PM, The IESG wrote: > > This working group will standardize encodings for DNS queries and respo= nses > that are suitable for use in HTTPS. This will enable the domain name sy= stem > to function over certain paths where existing DNS methods (UDP, TLS, an= d DTLS) > experience problems. There is a fundamental question that is left open in the charter: is the HTTPS server intended to be a substitute for a resolver, or is intended to provide name service for domains related to the authority section of the URL used to connect to the current service?=C2=A0 There is some hint along the lines of the latter in the draft, and I see nothing wrong with that use, and could see quite a bit of benefit, because the browser would be following the express intent of the origin. On the other hand, if this is intended to be used as a full scale replacement of a resolver, the placement of that resolver and more precisely locality would become a big operational issue for all sorts of reasons, such as anti-malware protection, split dns behavior, split personalities across applications that might impact non-participating web services, and more.=C2=A0 And yet.. > The working group will coordinate with the DNSOP and INTAREA working gr= oups > for input on DNS-over-HTTPS's impact on DNS operations and DNS semantic= s, > respectvely. In particular, DNSOP will be consulted for guidance on the= [nit - s/respectvely/respectively/] > operational impacts that result from traditional host behaviors (i.e., > stub-resolver to recursive-resolver interaction) being replaced with th= e > specified mechanism. > > Specification of how the DNS data may be used for new use cases, and > the discovery of the DOH servers, are out of scope for the working grou= p. The last sentence seems to put the cart before the horse.=C2=A0 How about= letting the working group decide in consultation with dnsop and intarea whether or not to handle discovery?=C2=A0 The fact is, you are not leavin= g discovery out of scope.=C2=A0 You are making a decision that discovery wi= ll take place either in a proprietary way, on an ad hoc basis, or via manual configuration, but you are ruling out a standard discovery mechani= sm. Eliot > > The working group will use draft-hoffman-dispatch-dns-over-https as inp= ut. > > Milestones: > > Apr 2018 - Submit specification for performing DNS queries over HTTPS= to > the IESG for publication as PS > > > --EKTLLdAF8OMqLIBMU3tfbSWaCCUhmGR1Q-- --cV2fCVtPUQS9CCHmuk7WX4PuBdPcfSa6B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZvAzTAAoJEIe2a0bZ0nozeKEIAL9AZ75OKSjmSfuWo0v0Xbeq DcjnYxpNQZW/BTtmVQGks6hkAmeRN4//YUl5KzinQ/GbvPXWzXuCICQRaHkGhH53 6fAcfLZB0twO6AP8r6Gz8UjtnZzhoC3YRWruivE5ttQbDITcmyEAJe9mCO71sUSh Zb5RkSwwsHHG9aoNHMLTJpRINSwP6hxd1vJRXVibEVLeiMSKDYrdk5U/cEx2br+l aVxRstwDA3UfcnImjEw+e77FsBcRbHfc8tM3QoNAqrtcDhUdQvlgjK0ci8qSVJYx 2Dwr27j7CUEd2ngvQYwxiPR9xkJPSPP27h7rpLWKKDNZoag3FMv+HRb7y1C1JeM= =MAC0 -----END PGP SIGNATURE----- --cV2fCVtPUQS9CCHmuk7WX4PuBdPcfSa6B-- From nobody Fri Sep 15 11:46:53 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAFD133453; Fri, 15 Sep 2017 11:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lByYLKcZlXU; Fri, 15 Sep 2017 11:24:05 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6F01330A9; Fri, 15 Sep 2017 11:24:04 -0700 (PDT) Received: from [169.254.57.250] (50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v8FIMsc9065379 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Sep 2017 11:22:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42] claimed to be [169.254.57.250] From: "Paul Hoffman" To: "Ted Hardie" Cc: IETF , doh@ietf.org Date: Fri, 15 Sep 2017 11:24:01 -0700 Message-ID: In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 11:46:42 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 18:24:07 -0000 On 15 Sep 2017, at 9:44, Ted Hardie wrote: =>> This working group will standardize encodings for DNS queries and responses >> that are suitable for use in HTTPS. This will enable the domain name >> system >> to function over certain paths where existing DNS methods (UDP, TLS, >> and >> DTLS) >> experience problems. The working group will re-use HTTPS methods, >> error >> codes, and other semantics to the greatest extent possible. The use >> of >> HTTPS >> provides integrity and confidentiality, and it also allows the >> transport to >> interoperate with common HTTPS infrastructure and policy. >> >> > I appreciate the charter's use of "HTTPS" as a signal that these are > intended to be TLS-protected HTTP sessions. I note, however, that > there is > considerable ambiguity still present. HTTPS can mean HTTP 1.1 over > TLS, > HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon (in > some > deployments it already means that). The document named as input > specifies > HTTP/2 over TLS. While the working group may, of course, change that > to > support HTTP 1.1 and/or QUIC, it might be useful for the charter to > indicate which of these is potentially in scope. Yes, please. The charter should say "HTTP/2 over TLS". There is no reason for current browsers adding this feature to add it using an obsolete protocol. If someone wants to create a diff from the eventual protocol for HTTP 1.1, they can do that without forcing the document to add a comparison of the two transports to what is supposed to be a short, concise document. > If the community is sure > now that HTTP over QUIC is in scope, for example, having that noted in > the > charter by adding the QUIC working group to list of working groups to > consult would be useful. The deadline for this WG is well ahead of when HTTP-over-QUIC will be finalized. Instead, when HTTP-over-QUIC is finalized, an update to this document should be pretty easy to produce. > I will confess a bias here: while I think it is useful to match the > capability set of HTTP over QUIC to that of HTTP over other transports > as > much as possible, I think making that a key part of this work is not a > good > initial direction. For one thing, there are some aspects of the QUIC > transport that are still in discussion, and I think it will slow this > work > a bit to track those. More importantly, though, I think this would be > the > wrong way to do DNS over QUIC (draft-huitema-quic-dnsoquic-00 shows a > different approach). Having QUIC be an early focus here may solidify > an > approach that is simple, but not nearly as complete as we could > deliver > with a DNS over QUIC. > > (This is in part because of the choice to use the udp wireformat as > the > baseline HTTP response here, rather than specifying DNS responses over > a > transport construct like a QUIC stream. The working group could, of > course, change that, but it would seriously shift the direction of its > input document to do so). Fully agree. >> Specification of how the DNS data may be used for new use cases, and >> the discovery of the DOH servers, are out of scope for the working >> group. >> >> > While it is useful to know that discovery is out of scope here, I > think > having a quick community discussion now of where it might be in scope > is > useful. There are some potentially interesting questions buried in > that, > especially in how we expect interworking with existing systems to go. > Note that even if the service discovery method provides an HTTPS URI > for > the name server, the questions above related to HTTP version or > transport > may bite you. For server discovery based on address and port, the > situation is much the same unless the port is clearly marked as TCP or > UDP. And if the server discovery includes no port at all, then a > happy > eyeballs type method may be needed. > > This may all fall into a combo of DHCP and DNSOP work, but giving > somewhat > clean lines for it now seems like it will make the later work go > faster. If you want to propose a new WG for that, please do so; there are a lot of people interested in that topic. It definitely goes across multiple areas of interest, such as "discovery" and "addressing" and even "trust". Personally, I don't think it applies to a transport document. >> Milestones: >> >> Apr 2018 - Submit specification for performing DNS queries over >> HTTPS to >> the IESG for publication as PS >> >> > I admire the optimism in this. It was not optimistic with the charter that was originally sent to the IESG; see . As more issues are added to the charter, it makes sense to have to extend the milestone deliverable. --Paul Hoffman From nobody Fri Sep 15 12:00:38 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF8013422C; Fri, 15 Sep 2017 12:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idbqbpooAoDp; Fri, 15 Sep 2017 12:00:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68C74134213; Fri, 15 Sep 2017 12:00:26 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8FJ0NeM066450 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 14:00:23 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Paul Hoffman , Ted Hardie Cc: doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> Date: Fri, 15 Sep 2017 14:00:23 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 19:00:30 -0000 On 9/15/17 1:24 PM, Paul Hoffman wrote: > Yes, please. The charter should say "HTTP/2 over TLS". There is no > reason for current browsers adding this feature to add it using an > obsolete protocol. I think you're assuming a tighter coupling between layers than actually exists. In particular -- since you're talking about browsers -- it would easy to implement the current draft entirely in content JavaScript. In doing so, it would be impossible for the implementation to prevent its use over HTTP/1.1 (or QUIC): aside from some proprietary browser-specific APIs, there's no way for such an implementation to even tell what version of HTTP is in use, much less prevent certain queries from going out over unwanted ones. This all bears more on the specified solution than the charter, but I suspect that (after a reasonable back-and-forth in the ensuing working group), one reasonable outcome will be that the mechanism works over HTTPS in general, simply because it will be too much of an implementation burden to prevent it from doing so. I'd rather not preclude the ability to have that discussion in the working group by foreclosing it in the charter language. /a From nobody Fri Sep 15 12:25:55 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F212B1341D3; Fri, 15 Sep 2017 12:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRpcabueS-Xj; Fri, 15 Sep 2017 12:25:50 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 9BB7F1329F9; Fri, 15 Sep 2017 12:25:50 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id q4so3071062qtq.8; Fri, 15 Sep 2017 12:25:50 -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=7wlaHoKHHbHRdmd+4rpgZKi5JIuhlGTYUH+m7pTmow0=; b=u/vofVC7OCDu2bqjBv60MUSkOI99cQVehd2Hi8gfN3rCW7kZJr/mkWpc55giNyapxs BoTc5WHAPd/ANRPDBZ1xNIrTQvVZnp/Op98Psh4NW0t5NY6xG3F3dn8C7Qb/aftEqNw2 GNWWMJ+VKbYydXw9HPONjECO3N4FOhFicAqmuD3U8CC19aYaolt8lWoHWRL6Mdl4T0vY DyccL1H1apXH8A7YoJxzGM+Rukq+J4rhLqp9bSIz4NCIDW6hPBpDReHq7mexJeoCqTHi qcRqlp2axI132WvWE0WSv50aatvlwTOFWdHpqTv0O7uXSzwczw/6zQkJWTSpx5GnMGRv LbAg== 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=7wlaHoKHHbHRdmd+4rpgZKi5JIuhlGTYUH+m7pTmow0=; b=ZhPQwgOqmX8kZnEZcCU9immLszH7Vd4FyvTVZJQrvSXtXldr4I/nAciKrflSdTREmD WKizPOyzXdOuM748EJoUbQzOUwstKkagq5mLJ73Y5pwOy1n020qSp1Nk3VyMsdBjMWt0 EQpzX8Xo4HoVs+//7i6iU5dpJI/RfwhNSp0aF7VUNIz+TwRvon4NiTlVHZvdYb87tOYP 3sG3Q4GC+DRcbmIp2zTYij09G5p5B+XMvbJmUyvtuYh5ZrQNzLHItfXsTSNqAjaEB3av S6V4FxcrRAOrtMTZEBxW72VIs+NM3in8pmktix4EZRD/EjZoyjMnW0IM3eQcWK0fkhpc 4hvA== X-Gm-Message-State: AHPjjUig+0+4RZf/L5joxcmBOsaWznux9Hk6fU7UG8uwNhDT9kqTJRL2 5WPZ2LpvBFIpiZoGdjA/vzL/P6kg0X4prJujL1c= X-Google-Smtp-Source: AOwi7QBENCB4rXfH8UdIOLl+PpzqfGLW5NHen6DUeCo0W+hCYQSlJX1U3wOdv3BpqyrRBh4vXnjGWVvdiXs4UK3eClI= X-Received: by 10.237.53.86 with SMTP id b22mr39516630qte.33.1505503549456; Fri, 15 Sep 2017 12:25:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Fri, 15 Sep 2017 12:25:19 -0700 (PDT) In-Reply-To: <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> From: Ted Hardie Date: Fri, 15 Sep 2017 12:25:19 -0700 Message-ID: To: Adam Roach Cc: Paul Hoffman , doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a11c01aac46078705593f5c72" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 19:25:53 -0000 --001a11c01aac46078705593f5c72 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach wrote: > On 9/15/17 1:24 PM, Paul Hoffman wrote: > >> Yes, please. The charter should say "HTTP/2 over TLS". There is no reason >> for current browsers adding this feature to add it using an obsolete >> protocol. >> > > > I think you're assuming a tighter coupling between layers than actually > exists. > > In particular -- since you're talking about browsers -- it would easy to > implement the current draft entirely in content JavaScript. In doing so, it > would be impossible for the implementation to prevent its use over HTTP/1.1 > (or QUIC): aside from some proprietary browser-specific APIs, So, "the implementation" in your statement above--is that the JavaScript or the browser? > there's no way for such an implementation to even tell what version of > HTTP is in use, much less prevent certain queries from going out over > unwanted ones. > > So, I think you have a usage in mind that is not the usage model that the draft talks about and is not really clear in the charter--the use of this within a JavaScript application to collect DNS responses without going through the browser/OS cache and DNS method. If that is a proposed use case, then I think there is a serious question of how the same origin policy applies here. Assume for a second that the resource in question mimics the current DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme. If Facebook JavaScript has a call for https://dns.fb.com/www.google.com?type=AAAA, will that be within same origin policy or not? If it is within same origin, where does the resulting data go? Just to the JavaScript or into browser or system caches? In addition to same origin questions, there are some privacy issues around this being used to signal external parties. Imagine a query like this: https://dns.google.com/unique-id.partner-site.com?type=TXT I don't know of any cross-site cookie watcher that would catch that, but it might be needed. This set of questions is pretty different from the ones you get with "function over different paths", because the locus of control moves from the mostly-trusted browser to the mostly not trusted downloaded application. > This all bears more on the specified solution than the charter, but I > suspect that (after a reasonable back-and-forth in the ensuing working > group), one reasonable outcome will be that the mechanism works over HTTPS > in general, simply because it will be too much of an implementation burden > to prevent it from doing so. > > I'd rather not preclude the ability to have that discussion in the working > group by foreclosing it in the charter language. > > I agree that the working group has to tackle it if it is in scope. The question we're discussing now is whether that use case is in scope. If any potential solution must deal with that eventuality because they all *could* be done in Javascript, like it or not, then the question is moot, but that's not personally clear to me yet. regards, Ted > /a > > --001a11c01aac46078705593f5c72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <adam@nostrum= .com> wrote:
On 9/15/17 1:24 PM= , Paul Hoffman wrote:
Yes, please. The charter should say "HTTP/2 over TLS". There is n= o reason for current browsers adding this feature to add it using an obsole= te protocol.


 I think you're assuming a tighter coupling between layers than actually= exists.

In particular -- since you're talking about browsers -- it would easy t= o implement the current draft entirely in content JavaScript. In doing so, = it would be impossible for the implementation to prevent its use over HTTP/= 1.1 (or QUIC): aside from some proprietary browser-specific APIs,

So, "the implementation" in your statement= above--is that the JavaScript or the browser?
=C2=A0
there's no way for such an implementation to even te= ll what version of HTTP is in use, much less prevent certain queries from g= oing out over unwanted ones.


So, I think you have a usage in mind t= hat is not the usage model that the draft talks about and is not really cle= ar in the charter--the use of this within a JavaScript application to colle= ct DNS responses without going through the browser/OS cache and DNS method.= =C2=A0 If that is a proposed use case, then I think there is a serious ques= tion of how the same origin policy applies here.

Assume f= or a second that the resource in question mimics the current DNS URI struct= ure (RFC 4501), but substitutes HTTPS as a scheme.=C2=A0=C2=A0 If Facebook = JavaScript has a call for https://dns.fb.com/www.google.com?type=3DAAAA, will that be wi= thin same origin policy or not?=C2=A0 If it is within same origin, where do= es the resulting data go?=C2=A0 Just to the JavaScript or into browser or s= ystem caches?=C2=A0

In addition to same origin questions= , there are some privacy issues around this being used to signal external p= arties.=C2=A0 Imagine a query like this:

I don'= t know of any cross-site cookie watcher that would catch that, but it might= be needed.

This set of questions is pretty di= fferent from the ones you get with "function over different paths"= ;, because the locus of control moves from the mostly-trusted browser to th= e mostly not trusted downloaded application.
=C2=A0
This all bears more on the specified solution than the charter, but I suspe= ct that (after a reasonable back-and-forth in the ensuing working group), o= ne reasonable outcome will be that the mechanism works over HTTPS in genera= l, simply because it will be too much of an implementation burden to preven= t it from doing so.

I'd rather not preclude the ability to have that discussion in the work= ing group by foreclosing it in the charter language.=


I agree that the working= group has to tackle it if it is in scope.=C2=A0 The question we're dis= cussing now is whether that use case is in scope.=C2=A0 If any potential so= lution must deal with that eventuality because they all *could* be done in = Javascript, like it or not, then the question is moot, but that's not p= ersonally clear to me yet.

regards,

Ted=

=C2=A0
/a


--001a11c01aac46078705593f5c72-- From nobody Fri Sep 15 13:20:00 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CD4133074; Fri, 15 Sep 2017 13:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcZyBNe-fjMC; Fri, 15 Sep 2017 13:19:51 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF591341F8; Fri, 15 Sep 2017 13:19:51 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8FKJmS3079529 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 15:19:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ted Hardie Cc: Paul Hoffman , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> From: Adam Roach Message-ID: Date: Fri, 15 Sep 2017 15:19:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1CDEA10D0626F2D160C651CB" Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 20:19:54 -0000 This is a multi-part message in MIME format. --------------1CDEA10D0626F2D160C651CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/15/17 14:25, Ted Hardie wrote: > On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach > wrote: > > On 9/15/17 1:24 PM, Paul Hoffman wrote: > > Yes, please. The charter should say "HTTP/2 over TLS". There > is no reason for current browsers adding this feature to add > it using an obsolete protocol. > > > > I think you're assuming a tighter coupling between layers than > actually exists. > > In particular -- since you're talking about browsers -- it would > easy to implement the current draft entirely in content > JavaScript. In doing so, it would be impossible for the > implementation to prevent its use over HTTP/1.1 (or QUIC): aside > from some proprietary browser-specific APIs, > > > So, "the implementation" in your statement above--is that the > JavaScript or the browser? In the scenario I'm describing, it's the JavaScript. > there's no way for such an implementation to even tell what > version of HTTP is in use, much less prevent certain queries from > going out over unwanted ones. > > > So, I think you have a usage in mind that is not the usage model that > the draft talks about and is not really clear in the charter--the use > of this within a JavaScript application to collect DNS responses > without going through the browser/OS cache and DNS method.  If that is > a proposed use case, then I think there is a serious question of how > the same origin policy applies here. Given that (in this scenario), the browser wouldn't know this query from any _other_ HTTPS request, it applies the same way as it does to all other HTTPS requests. > Assume for a second that the resource in question mimics the current > DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme.   If > Facebook JavaScript has a call for > https://dns.fb.com/www.google.com?type=AAAA, will that be within same > origin policy or not? You didn't say what the origin of the calling page was. If it's the same origin, then it's the same origin (modulo CORS behavior). > If it is within same origin, where does the resulting data go?  Just > to the JavaScript or into browser or system caches? The scenario I'm posting above assumes no special browser behavior. > In addition to same origin questions, there are some privacy issues > around this being used to signal external parties.  Imagine a query > like this: > > https://dns.google.com/unique-id.partner-site.com?type=TXT > > I don't know of any cross-site cookie watcher that would catch that, > but it might be needed. This is a fine point. I do wonder how the resolvers at 8.8.8.8 and 8.8.4.4 handle it. I suppose the API deployed at https://developers.google.com/speed/public-dns/docs/dns-over-https is probably closer to the use case we're contemplating, though. To be clear, I'm not saying that these situations you describe aren't _bad_; I'm pointing out that they already exist with or without the mechanism under discussion. I would think the standard here is "don't make it worse," rather than "first, drain the swamp." I'll also point out that this use case (the JavaScript-based one) is nice in that it allows applications to communicate with a known trusted site (e.g., their own origin) to prevent this kind of unintentional exfiltration of information. Of course, this is already possible today using proprietary mechanisms, but it would be nice if such apps could use standard libraries. > I agree that the working group has to tackle it if it is in scope.  > The question we're discussing now is whether that use case is in > scope.  If any potential solution must deal with that eventuality > because they all *could* be done in Javascript, like it or not, then > the question is moot, but that's not personally clear to me yet. I chose that example because it's easy to reason about without knowing the internal implementation architecture of browsers. If we instead turn to the *other* use case that you describe in which the browser (absent any special JavaScript handling) chooses to use DNS-over-HTTPS, then a congruent problem arises. While it's not an area I've worked in closely, what I've seen of Firefox's network layer implementation leads me to believe that precluding a mechanism like this from working across all supported variations of HTTP would require additional code; and that the role of that code, in its entirety, would be to prevent from working that which otherwise would. Unless there are, say, security implications to doing so, I'd think we need better rationale for preventing it than "we don't want to think about it." /a --------------1CDEA10D0626F2D160C651CB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/15/17 14:25, Ted Hardie wrote:
On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <adam@nostrum.com> wrote:
On 9/15/17 1:24 PM, Paul Hoffman wrote:
Yes, please. The charter should say "HTTP/2 over TLS". There is no reason for current browsers adding this feature to add it using an obsolete protocol.


 I think you're assuming a tighter coupling between layers than actually exists.

In particular -- since you're talking about browsers -- it would easy to implement the current draft entirely in content JavaScript. In doing so, it would be impossible for the implementation to prevent its use over HTTP/1.1 (or QUIC): aside from some proprietary browser-specific APIs,

So, "the implementation" in your statement above--is that the JavaScript or the browser?

In the scenario I'm describing, it's the JavaScript.

 
there's no way for such an implementation to even tell what version of HTTP is in use, much less prevent certain queries from going out over unwanted ones.


So, I think you have a usage in mind that is not the usage model that the draft talks about and is not really clear in the charter--the use of this within a JavaScript application to collect DNS responses without going through the browser/OS cache and DNS method.  If that is a proposed use case, then I think there is a serious question of how the same origin policy applies here.

Given that (in this scenario), the browser wouldn't know this query from any _other_ HTTPS request, it applies the same way as it does to all other HTTPS requests.

Assume for a second that the resource in question mimics the current DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme.   If Facebook JavaScript has a call for https://dns.fb.com/www.google.com?type=AAAA, will that be within same origin policy or not?

You didn't say what the origin of the calling page was. If it's the same origin, then it's the same origin (modulo CORS behavior).

If it is within same origin, where does the resulting data go?  Just to the JavaScript or into browser or system caches?

The scenario I'm posting above assumes no special browser behavior.

In addition to same origin questions, there are some privacy issues around this being used to signal external parties.  Imagine a query like this:

I don't know of any cross-site cookie watcher that would catch that, but it might be needed.

This is a fine point. I do wonder how the resolvers at 8.8.8.8 and 8.8.4.4 handle it. I suppose the API deployed at https://developers.google.com/speed/public-dns/docs/dns-over-https is probably closer to the use case we're contemplating, though.

To be clear, I'm not saying that these situations you describe aren't _bad_; I'm pointing out that they already exist with or without the mechanism under discussion. I would think the standard here is "don't make it worse," rather than "first, drain the swamp."

I'll also point out that this use case (the JavaScript-based one) is nice in that it allows applications to communicate with a known trusted site (e.g., their own origin) to prevent this kind of unintentional exfiltration of information. Of course, this is already possible today using proprietary mechanisms, but it would be nice if such apps could use standard libraries.

I agree that the working group has to tackle it if it is in scope.  The question we're discussing now is whether that use case is in scope.  If any potential solution must deal with that eventuality because they all *could* be done in Javascript, like it or not, then the question is moot, but that's not personally clear to me yet.

I chose that example because it's easy to reason about without knowing the internal implementation architecture of browsers. If we instead turn to the *other* use case that you describe in which the browser (absent any special JavaScript handling) chooses to use DNS-over-HTTPS, then a congruent problem arises. While it's not an area I've worked in closely, what I've seen of Firefox's network layer implementation leads me to believe that precluding a mechanism like this from working across all supported variations of HTTP would require additional code; and that the role of that code, in its entirety, would be to prevent from working that which otherwise would. Unless there are, say, security implications to doing so, I'd think we need better rationale for preventing it than "we don't want to think about it."

/a
--------------1CDEA10D0626F2D160C651CB-- From nobody Fri Sep 15 13:54:17 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225DD134213; Fri, 15 Sep 2017 13:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wA-Hfx93VsyA; Fri, 15 Sep 2017 13:54:13 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1292B126E64; Fri, 15 Sep 2017 13:54:13 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id m35so3292791qte.1; Fri, 15 Sep 2017 13:54:13 -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=AK6M4Wzz8yK0kBWMkSQ2uN4LIrNgN7pIPlFxywceCw0=; b=FSNHdXLDFzABfS2mKZESN0hC2lhxRGR8vW11HjvnN7mp4JldMqUdWV2AhjrvMfBlID layIsZWiqFyOxznJlYazrc6MaxpDXJEidi/4hjaJXD8vPaqVosURY8x7PNCmP3zqI+Ws Ejy9hmzuZmbXFyptCo+tzKmWheOQoOTr7kVP/uSeVW4DmhpEHAwPUNbeD/xAaA6FaoYA gRbXLR6VpxQZ9+nsiQRIQJprECdpJoVK2s31Npphl+ltNAtzh6wGbi/6X89L9l4BIL+b 2IE+R17zuhJkRI5wKXNlOdNfTu77SBi5cNXYOJg5SwEt7GdH8NL+1Nn7hmRMIj66maQ1 SlpQ== 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=AK6M4Wzz8yK0kBWMkSQ2uN4LIrNgN7pIPlFxywceCw0=; b=SFGqMrXRuaf5Gshgm3ZrcuXyHrWM1vBL8wUTrMvFn6EFit1fVGIGr1337wFoBanlLU E0kP7tb35/rSuc6aSnNEwh/qgj3QSkms1rSrFSB8MDN1XCwstIRVLmImwL1oasH8dchm j/F5jyorzidknSKOiH+8RJl40swMXpOsGJqw9zl0vdXXnjI95AcfQturzJvr8k4eRQx0 6cqOHJTAQ1scM0tTjRDHm2pOhrH4pqp6KJBfCzf6Rz4OqJVJmEc5svCVC81iLqcoOiJ7 1hQA6ZMn09xmHlin2p1JBqbshVyzUE2HNCGzZ4ej4G76Z1igohV68HJRUhL1xexdcp/w vY6A== X-Gm-Message-State: AHPjjUg1yTYkgXIiJvAVkuGPk5lrHoyO4g85g+LHWOAY7PViMd98OL3a pxcsslUw28plSC2PZsI/R6UoyAGh0RoWh7BCTig= X-Google-Smtp-Source: AOwi7QCwu+HLTOJRCyjWnkl2RVDm8NFGT2d0UAEne/n7GMGEJNARdT+G0gCvnfrFvJW0OhoXody2Stby2DPaREFzf14= X-Received: by 10.237.37.231 with SMTP id y36mr39042634qtc.199.1505508850844; Fri, 15 Sep 2017 13:54:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Fri, 15 Sep 2017 13:53:40 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> From: Ted Hardie Date: Fri, 15 Sep 2017 13:53:40 -0700 Message-ID: To: Adam Roach Cc: Paul Hoffman , doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a114029b642cc37055940981c" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 20:54:16 -0000 --001a114029b642cc37055940981c Content-Type: text/plain; charset="UTF-8" In-line. On Fri, Sep 15, 2017 at 1:19 PM, Adam Roach wrote: > On 9/15/17 14:25, Ted Hardie wrote: > > On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach wrote: > >> On 9/15/17 1:24 PM, Paul Hoffman wrote: >> >>> Yes, please. The charter should say "HTTP/2 over TLS". There is no >>> reason for current browsers adding this feature to add it using an obsolete >>> protocol. >>> >> >> >> I think you're assuming a tighter coupling between layers than actually >> exists. >> >> In particular -- since you're talking about browsers -- it would easy to >> implement the current draft entirely in content JavaScript. In doing so, it >> would be impossible for the implementation to prevent its use over HTTP/1.1 >> (or QUIC): aside from some proprietary browser-specific APIs, > > > So, "the implementation" in your statement above--is that the JavaScript > or the browser? > > > In the scenario I'm describing, it's the JavaScript. > > > >> there's no way for such an implementation to even tell what version of >> HTTP is in use, much less prevent certain queries from going out over >> unwanted ones. >> >> > So, I think you have a usage in mind that is not the usage model that the > draft talks about and is not really clear in the charter--the use of this > within a JavaScript application to collect DNS responses without going > through the browser/OS cache and DNS method. If that is a proposed use > case, then I think there is a serious question of how the same origin > policy applies here. > > > Given that (in this scenario), the browser wouldn't know this query from > any _other_ HTTPS request, it applies the same way as it does to all other > HTTPS requests. > > You're making an assumption that I don't think is established, that the requests using HTTPS for DNS are not distinguishable from other resources. If they were keyed by something like dnsh://authority/query-target?RR (to pick on poor old RFC 4501 again), they would be in JavaScript *even if they were not on the wire*. > Assume for a second that the resource in question mimics the current DNS > URI structure (RFC 4501), but substitutes HTTPS as a scheme. If Facebook > JavaScript has a call for https://dns.fb.com/www.google.com?type=AAAA, > will that be within same origin policy or not? > > > You didn't say what the origin of the calling page was. > Sorry, when I said "Facebook JavaScript" I meant to imply that facebook was the origin and that fb.com would same origin. > If it's the same origin, then it's the same origin (modulo CORS behavior). > > I'm frankly a bit worried that the GET version of Paul's draft would not trigger the CORS pre-flight checks. If it is consumed by JavaScript and never otherwise cached, that's not so big a deal, but if it is populating a browser or system cache, it's a problem. > If it is within same origin, where does the resulting data go? Just to > the JavaScript or into browser or system caches? > > > The scenario I'm posting above assumes no special browser behavior. > > I'm not sure "no special browser behavior" answers my question. Is the default the browser behavior when it gets a DNS response or the browser behavior for content JavaScript requests in-line? > In addition to same origin questions, there are some privacy issues around > this being used to signal external parties. Imagine a query like this: > > https://dns.google.com/unique-id.partner-site.com?type=TXT > > I don't know of any cross-site cookie watcher that would catch that, but > it might be needed. > > > > This is a fine point. I do wonder how the resolvers at 8.8.8.8 and 8.8.4.4 > handle it. I suppose the API deployed at https://developers.google.com/ > speed/public-dns/docs/dns-over-https is probably closer to the use case > we're contemplating, though. > > (I wasn't involved developing that, so the view from the outside); that looks very much like it would take the JSON records returned and populate the standard cache(s) with them. To be clear, I'm not saying that these situations you describe aren't > _bad_; I'm pointing out that they already exist with or without the > mechanism under discussion. I would think the standard here is "don't make > it worse," rather than "first, drain the swamp." > > I'll also point out that this use case (the JavaScript-based one) is nice > in that it allows applications to communicate with a known trusted site > (e.g., their own origin) to prevent this kind of unintentional exfiltration > of information. Of course, this is already possible today using proprietary > mechanisms, but it would be nice if such apps could use standard libraries. > > The trust relationship you mention is important (the JavaScript trusting its source), but we also have to consider the user's trust in the JavaScript. A malicious piece of JavaScript is not so hard to introduce into the world, and if it can influence the DNS mapping, it may be well worth the time of phishers and others to do so. I agree that the working group has to tackle it if it is in scope. The > question we're discussing now is whether that use case is in scope. If any > potential solution must deal with that eventuality because they all *could* > be done in Javascript, like it or not, then the question is moot, but > that's not personally clear to me yet. > > > I chose that example because it's easy to reason about without knowing the > internal implementation architecture of browsers. If we instead turn to the > *other* use case that you describe in which the browser (absent any special > JavaScript handling) chooses to use DNS-over-HTTPS, then a congruent > problem arises. While it's not an area I've worked in closely, what I've > seen of Firefox's network layer implementation leads me to believe that > precluding a mechanism like this from working across all supported > variations of HTTP would require additional code; and that the role of that > code, in its entirety, would be to prevent from working that which > otherwise would. Unless there are, say, security implications to doing so, > I'd think we need better rationale for preventing it than "we don't want to > think about it." > I assume that you have code that would let you say "not unless protected by TLS", though, so that portion of the charter presumption matches reality? Thanks for your insight into this, Ted > > /a > --001a114029b642cc37055940981c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In-line.

On Fri, Sep 15, 2017 at 1:19 PM, Adam Roach <adam@nostrum.= com> wrote:
=20 =20 =20
On 9/15/17 14:25, = Ted Hardie wrote:
On Fri, Sep 15, 2017 at 12:00 PM, Adam Roach <adam@n= ostrum.com> wrote:
On 9/15/17 1:24 PM, Paul H= offman wrote:
Yes, please. The charter should say "HTTP/2 over TLS= ". There is no reason for current browsers adding this feature to add it using an obsolete protocol.


 I think you're assuming a tighter coupling between layers than actually exists.

In particular -- since you're talking about browsers -- i= t would easy to implement the current draft entirely in content JavaScript. In doing so, it would be impossible for the implementation to prevent its use over HTTP/1.1 (or QUIC): aside from some proprietary browser-specific APIs,

So, "the implementation" in your statement above= --is that the JavaScript or the browser?

 In the scenario I'm describing, it's the JavaScript.

=C2=A0
there's no way for such an implementation to even tell what version of HTTP is in use, much less prevent certain queries from going out over unwanted ones.


So, I think you have a usage in mind that is not the usage model that the draft talks about and is not really clear in the charter--the use of this within a JavaScript application to collect DNS responses without going through the browser/OS cache and DNS method.=C2=A0 If that is a proposed use case, then I think there is a serious question of how the same origin policy applies here.

 Given that (in this scenario), the browser wouldn't know this query from any _other_ HTTPS request, it applies the same way as it does to all other HTTPS requests.


You're making an = assumption that I don't think is established, that the requests using H= TTPS for DNS are not distinguishable from other resources.=C2=A0 If they we= re keyed by something like dnsh://authority/query-target?RR (to pick on poo= r old RFC 4501 again), they would be in JavaScript *even if they were not o= n the wire*.
=C2=A0
Assume for a second that the resource in question mimics the current DNS URI structure (RFC 4501), but substitutes HTTPS as a scheme.=C2=A0=C2=A0 If Facebook JavaSc= ript has a call for https://dns.fb.com/www.google.com?type= =3DAAAA, will that be within same origin policy or not?

 You didn't say what the origin of the calling page was.

Sorry, when I said "Facebook JavaScript&qu= ot; I meant to imply that facebook was the origin and that fb.com would same origin.
=C2=A0
If it's= the same origin, then it's the same origin (modulo CORS behavior).


I'm frankly a bit= worried that the GET version of Paul's draft would not trigger the COR= S pre-flight checks.=C2=A0 If it is consumed by JavaScript and never otherw= ise cached, that's not so big a deal, but if it is populating a browser= or system cache, it's a problem.

=C2=A0
If it is within same origin, where does the resulting data go?=C2=A0 Just to the JavaScript or into browser or syst= em caches?

 The scenario I'm posting above assumes no special browser behavior.=


I'm not sure &quo= t;no special browser behavior" answers my question.=C2=A0 Is the defau= lt the browser behavior when it gets a DNS response or the browser behavior= for content JavaScript requests in-line?=C2=A0
=C2=A0
=
In addition to same origin questions, there are some privacy issues around this being used to signal external parties.=C2=A0 Imagine a query like this:

I don't know of any cross-site cookie watcher that would catch that, but it might be needed.


=C2=A0
This is a fine point. I do wonder how the resolvers at 8.8.8.8 and 8.8.4.4 handle it. I suppose the API deployed at https://developers.google.com/speed/public-dns/docs/dns-over= -https is probably closer to the use case we're contemplating, though.


(I wasn't involved devel= oping that, so the view from the outside); that looks very much like it wou= ld take the JSON records returned and populate the standard cache(s) with t= hem.

To be clear, I'm not saying that these situations you describe aren't _bad_; I'm pointing out that they already exist with or without the mechanism under discussion. I would think the standard here is "don't make it worse," rather than "first, d= rain the swamp."

I'll also point out that this use case (the JavaScript-based one) i= s nice in that it allows applications to communicate with a known trusted site (e.g., their own origin) to prevent this kind of unintentional exfiltration of information. Of course, this is already possible today using proprietary mechanisms, but it would be nice if such apps could use standard libraries.


The trust relationshi= p you mention is important (the JavaScript trusting its source), but we als= o have to consider the user's trust in the JavaScript.=C2=A0 A maliciou= s piece of JavaScript is not so hard to introduce into the world, and if it= can influence the DNS mapping, it may be well worth the time of phishers a= nd others to do so.

=
I agree that the working group has to tackle it if it is in scope.=C2=A0 The question we're discu= ssing now is whether that use case is in scope.=C2=A0 If any potentia= l solution must deal with that eventuality because they all *could* be done in Javascript, like it or not, then the question is moot, but that's not personally clear to me yet= .

 I chose that example because it's easy to reason about without knowing the internal implementation architecture of browsers. If we instead turn to the *other* use case that you describe in which the browser (absent any special JavaScript handling) chooses to use DNS-over-HTTPS, then a congruent problem arises. While it's not an area I've worked in closely, what I've seen of Firefox's ne= twork layer implementation leads me to believe that precluding a mechanism like this from working across all supported variations of HTTP would require additional code; and that the role of that code, in its entirety, would be to prevent from working that which otherwise would. Unless there are, say, security implications to doing so, I'= d think we need better rationale for preventing it than "we don'= t want to think about it."=

I assume that you = have code that would let you say "not unless protected by TLS", t= hough, so that portion of the charter presumption matches reality?

<= /div>
Thanks for your insight into this,

Ted
=C2= =A0

/a

--001a114029b642cc37055940981c-- From nobody Fri Sep 15 13:56:53 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81FF132A05; Fri, 15 Sep 2017 13:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW8GsyJWVkg5; Fri, 15 Sep 2017 13:56:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA01E1321A2; Fri, 15 Sep 2017 13:56:50 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8FKumox085974 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 15 Sep 2017 15:56:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ted Hardie Cc: Paul Hoffman , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> From: Adam Roach Message-ID: <379869c3-df15-5c15-ee5e-96e583543258@nostrum.com> Date: Fri, 15 Sep 2017 15:56:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 20:56:52 -0000 On 9/15/17 15:53, Ted Hardie wrote: > I assume that you have code that would let you say "not unless > protected by TLS", though, so that portion of the charter presumption > matches reality? Yes; there's a *lot* of "don't do this over unsecured transports" code. /a From nobody Fri Sep 15 15:04:46 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA91133209; Fri, 15 Sep 2017 15:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo-imUq15cSn; Fri, 15 Sep 2017 15:04:43 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26FCE1330A1; Fri, 15 Sep 2017 15:04:43 -0700 (PDT) Received: from [10.32.60.139] (50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v8FM3TRc075760 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 15 Sep 2017 15:03:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42] claimed to be [10.32.60.139] From: "Paul Hoffman" To: "Stephen Farrell" Cc: doh@ietf.org, IETF Date: Fri, 15 Sep 2017 15:04:36 -0700 Message-ID: <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> In-Reply-To: <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 22:04:44 -0000 On 15 Sep 2017, at 14:44, Stephen Farrell wrote: > On 15/09/17 20:25, Ted Hardie wrote: >> >> This set of questions is pretty different from the ones you get with >> "function over different paths", because the locus of control moves >> from >> the mostly-trusted browser to the mostly not trusted downloaded >> application. > > FWIW, I share Ted's concerns about origins. Regardless > of what approaches are taken, the effects of this need > to be well understood I think. I don't object to the WG > being chartered though but would suggest that there be > a mention in the charter that the WG needs to document > the consequences, including the dangers, of caching and > re-use of DNS answers for likely implementations. The charter already points to the document that the work will be based on, which has that topic in it, because *you* pointed it out in the earlier discussion of the document. As co-author on the document, I assure you we will not remove it, if for no other reason than I wouldn't want to face your wrath again in IETF Last Call. :-) > I'd be even happier if the resulting spec had a bunch > of MUST NOT statements about that, if such statements > were likely to be effective. All MUST NOTs are only partially effective, but we use them anyway to help good implementers. If you have some proposed MUST NOTs on the current document, by all means send them in. --Paul Hoffman From nobody Fri Sep 15 15:14:22 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EEC13423D for ; Fri, 15 Sep 2017 15:14:20 -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 JFOchvtZLNQo for ; Fri, 15 Sep 2017 15:14:18 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D1CE134236 for ; Fri, 15 Sep 2017 15:14:18 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l4so2237052ywa.6 for ; Fri, 15 Sep 2017 15:14:18 -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=Kwjb6UwqywCgnmpFBEGJnts7G36kKVsGWtRxWPC2zpE=; b=Ohv17jla+fL2FtJk1OB7hkK5GyB0bfHkmzbh0WLAARhs00n1f2ZcauJU/XjjQYOwnB Iy7e3hqnWsR9fWbeEhBrpAErJtFs4bp9N1RWlJJX9fBjjbR0QZK1TQGt2vWios9rZti1 AD9/090fodr02vcWN2+nbxoUn9EeR5DmeWRQ5hfGlbA8WioGXQOSWXCe4b6NHjDvZFFD PvbsH8CJNjpLzARns2PPaPMwYpTfZZnVFTL5vQXFx7N/4AN4ra/EXb2DonNVaT4YJ6ND WYomqA4NaewRh4eiAR/0FPguRY8Ex+WQdDBCsjOloy8GPQrOqqTQBtHstuCYI4mBzW08 +frg== 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=Kwjb6UwqywCgnmpFBEGJnts7G36kKVsGWtRxWPC2zpE=; b=qzS3XU7fpe0jh8r4q/BF0MzmqQrwQP/byu8fZ6UxdLNvPY+OOU1MFmGFC27fHnNcP5 ucU8hGrWK/0V2F0Q2FSJ/K0D1COCQhiT/yZE0ZNUls/WCgX8smgI6uN1KKe33Wf8aSPG ZPt0cfyntMjddlDORKCqmNJkq77K6YQeN+ZBDVOMIwjo+OiLqjED40gAw1/IAi/a65EK tt0gnBtBw/AGEMpuBj4AHiRvCmECwACny+a9dCWM64hzCDFL107fJdwMf2UHcEYUJEvr 04lomiHWd/rwVhgA72s7dLRIYPJ2Gg7NoW65Q2RRM2eWeNXKPMatTLs+EIbd2Fk5Yna3 XBUA== X-Gm-Message-State: AHPjjUj/8nRkATmzvlJ719/TFs7jD+zVv8czS0YDW7378fHUSF33Vrqc RMv+xof2XrGc7nRo0c1ilGOzUQD23LgRtcBfdwxSIQ== X-Google-Smtp-Source: ADKCNb5eDWwqP6Q2OUmaEXMo2gey1lMv4BzFknlrdXhNzySCHLuKXXLd+Q+tQfmc6TniNhZHFXNsVxpasuvGXZ4SqZg= X-Received: by 10.37.3.151 with SMTP id 145mr23415406ybd.38.1505513657236; Fri, 15 Sep 2017 15:14:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.15 with HTTP; Fri, 15 Sep 2017 15:14:16 -0700 (PDT) In-Reply-To: <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> From: Spencer Dawkins at IETF Date: Fri, 15 Sep 2017 17:14:16 -0500 Message-ID: To: Paul Hoffman Cc: Stephen Farrell , doh@ietf.org Content-Type: multipart/alternative; boundary="001a11c02b62be7f0e055941b644" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 22:14:20 -0000 --001a11c02b62be7f0e055941b644 Content-Type: text/plain; charset="UTF-8" To a slightly smaller crowd ... On Fri, Sep 15, 2017 at 5:04 PM, Paul Hoffman wrote: > On 15 Sep 2017, at 14:44, Stephen Farrell wrote: > > On 15/09/17 20:25, Ted Hardie wrote: >> >>> >>> This set of questions is pretty different from the ones you get with >>> "function over different paths", because the locus of control moves from >>> the mostly-trusted browser to the mostly not trusted downloaded >>> application. >>> >> >> FWIW, I share Ted's concerns about origins. Regardless >> of what approaches are taken, the effects of this need >> to be well understood I think. I don't object to the WG >> being chartered though but would suggest that there be >> a mention in the charter that the WG needs to document >> the consequences, including the dangers, of caching and >> re-use of DNS answers for likely implementations. >> > > The charter already points to the document that the work will be based on, > which has that topic in it, because *you* pointed it out in the earlier > discussion of the document. As co-author on the document, I assure you we > will not remove it, if for no other reason than I wouldn't want to face > your wrath again in IETF Last Call. :-) I recently pointed out, while complaining about pervasive monitoring in an AD Evaluation for a TSV document, that not only is https://tools.ietf.org/html/rfc7258 a BCP, but if https://www.ietf.org/mailman/roster/secdir really is the list of reviewers like https://trac.ietf.org/trac/sec/wiki/SecurityDirectorate says it is, authors have a non-zero chance of getting an RFC 7258 author as their sec-dir reviewer ... The same probability of getting Stephen would apply here. You are very wise :-) Spencer --001a11c02b62be7f0e055941b644 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To a slightly smaller crowd ...
=
On Fri, Sep 15, 2017 at 5:04 PM, Paul Hoffma= n <paul.hoffman@vpnc.org> wrote:
On 15 Sep 2017, at 14:= 44, Stephen Farrell wrote:

On 15/09/17 20:25, Ted Hardie wrote:

This set of questions is pretty different from the ones you get with
"function over different paths", because the locus of control mov= es from
the mostly-trusted browser to the mostly not trusted downloaded application= .

FWIW, I share Ted's concerns about origins. Regardless
of what approaches are taken, the effects of this need
to be well understood I think. I don't object to the WG
being chartered though but would suggest that there be
a mention in the charter that the WG needs to document
the consequences, including the dangers, of caching and
re-use of DNS answers for likely implementations.

 The charter already points to the document that the work will be based on, = which has that topic in it, because *you* pointed it out in the earlier dis= cussion of the document. As co-author on the document, I assure you we will= not remove it, if for no other reason than I wouldn't want to face you= r wrath again in IETF Last Call. :-)

I rece= ntly pointed out, while complaining about pervasive monitoring in an AD Eva= luation for a TSV document, that not only is https://tools.ietf.org/html/rfc7258=C2=A0a BCP, but i= f https://www.ietf.o= rg/mailman/roster/secdir really is the list of reviewers like https://trac.i= etf.org/trac/sec/wiki/SecurityDirectorate says it is, authors have a no= n-zero chance of getting an RFC 7258 author as their sec-dir reviewer ...= =C2=A0

The same probability of getting Stephen wou= ld apply here.

You are very wise :-)
Spencer
--001a11c02b62be7f0e055941b644-- From nobody Fri Sep 15 15:35:59 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33C133044; Fri, 15 Sep 2017 14:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbW6UAz3EWRv; Fri, 15 Sep 2017 14:44:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9EB4132620; Fri, 15 Sep 2017 14:44:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9F601BE6F; Fri, 15 Sep 2017 22:44:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBa-3H-GSrak; Fri, 15 Sep 2017 22:44:31 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3CCA1BE5D; Fri, 15 Sep 2017 22:44:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1505511871; bh=NoI5J9BYvl0NxmaTttbtsn11gKWpTXPO5iIOt8jOzD4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=B2uSD5I+JKin46N19Pc9ElOcsiDC6H3Q+17v8sX4/aWXRKOSGfaMsR0pznrgRWVVg Vb0aSi77DYMuCZWDUeWNpF4eO0Q3VFsYzTJruFaAeJJ+la+JNFsyKCrEuoWXkRrtmp xYgJI0sckFTnPvAXbGscis1iGdzufzMKY3WA66Rc= To: Ted Hardie , Adam Roach Cc: doh@ietf.org, Paul Hoffman , IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> Date: Fri, 15 Sep 2017 22:44:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7Lgx31bA02nBbHJkSxT6oqoeifFLrILB1" Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 15:35:58 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 21:44:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7Lgx31bA02nBbHJkSxT6oqoeifFLrILB1 Content-Type: multipart/mixed; boundary="P6TBNO00lxHePdQ6WuK6H4rS2vuf3dNp1"; protected-headers="v1" From: Stephen Farrell To: Ted Hardie , Adam Roach Cc: doh@ietf.org, Paul Hoffman , IETF Message-ID: <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> In-Reply-To: --P6TBNO00lxHePdQ6WuK6H4rS2vuf3dNp1 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 15/09/17 20:25, Ted Hardie wrote: >=20 > This set of questions is pretty different from the ones you get with > "function over different paths", because the locus of control moves fro= m > the mostly-trusted browser to the mostly not trusted downloaded applica= tion. FWIW, I share Ted's concerns about origins. Regardless of what approaches are taken, the effects of this need to be well understood I think. I don't object to the WG being chartered though but would suggest that there be a mention in the charter that the WG needs to document the consequences, including the dangers, of caching and re-use of DNS answers for likely implementations. I'd be even happier if the resulting spec had a bunch of MUST NOT statements about that, if such statements were likely to be effective. S. --P6TBNO00lxHePdQ6WuK6H4rS2vuf3dNp1-- --7Lgx31bA02nBbHJkSxT6oqoeifFLrILB1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZvEm+AAoJEC88hzaAX42i9PAIAKh4wLXY1teCuNYnlDDepC9F MDykUcB++rOf5dnzzSmBTZ8Ndc/9vD24HVUZvXeoQSp+ehQnfvkn07yKaW5oIpr/ ZUEy31ZBTvgY4Mj23A4ZolE9NCWvx82sxrEzu8MUp1TqMBK2VJn1HuwBq8XhzRDb 2nMd/tk+OaNFvl+4mPPQ8qtde82L6B95hrpoQ7ku+fnpas0/4wGeCDtCwukJsB41 M31Au4/T4prli/8fVmfIyQmbgB/nyzgc6t+wLZ8XB2QZ3FrsFEPRUPE7deIJ7wiw CGKcteqcoLM5xEklM5F5DpWpZm+O7JrMtDbZgC1hO0x/aVzMOiEhCndU6B7P0RI= =ik07 -----END PGP SIGNATURE----- --7Lgx31bA02nBbHJkSxT6oqoeifFLrILB1-- From nobody Fri Sep 15 15:36:05 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9A8133224; Fri, 15 Sep 2017 15:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOczRNmiIVwj; Fri, 15 Sep 2017 15:33:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA58B13208E; Fri, 15 Sep 2017 15:33:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40533BE73; Fri, 15 Sep 2017 23:33:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tddlDlmO2idk; Fri, 15 Sep 2017 23:33:10 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5C4FBE6F; Fri, 15 Sep 2017 23:33:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1505514790; bh=7hPGXjfc6FjglGhZcbpQw+vQUI2Qvzo9G5Zjhlvfrxo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=LVkRRXlnlTRKgvq5Z0gT7DD/QaEc42lzbvAWzZ5+TuH/jUFFI6o9OUjriDzCssCc0 yGvDUFGSk+0oor82LEY4xGwmAK/XtAodMwAmvPHrOYkD/5wOWv1fNstFNKDtEv6dka eMtpr4B0i/VvH/GkGUKsfRoVr0b97XuaeUP33fmA= To: Paul Hoffman Cc: doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> Date: Fri, 15 Sep 2017 23:33:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f4vb2pJImm1GENCLUMahUapFkDxTSwaDD" Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 15:35:58 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 15 Sep 2017 22:33:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --f4vb2pJImm1GENCLUMahUapFkDxTSwaDD Content-Type: multipart/mixed; boundary="tqUhNIHv5Q1qdKvs1K8pHunN0EkkceBgh"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman Cc: doh@ietf.org, IETF Message-ID: <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> In-Reply-To: <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> --tqUhNIHv5Q1qdKvs1K8pHunN0EkkceBgh Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 15/09/17 23:04, Paul Hoffman wrote: > On 15 Sep 2017, at 14:44, Stephen Farrell wrote: >=20 >> On 15/09/17 20:25, Ted Hardie wrote: >>>=20 >>> This set of questions is pretty different from the ones you get >>> with "function over different paths", because the locus of >>> control moves from the mostly-trusted browser to the mostly not >>> trusted downloaded application. >>=20 >> FWIW, I share Ted's concerns about origins. Regardless of what >> approaches are taken, the effects of this need to be well >> understood I think. I don't object to the WG being chartered though >> but would suggest that there be a mention in the charter that the >> WG needs to document the consequences, including the dangers, of >> caching and re-use of DNS answers for likely implementations. >=20 > The charter already points to the document that the work will be > based on, which has that topic in it, because *you* pointed it out in > the earlier discussion of the document. As co-author on the document, > I assure you we will not remove it, if for no other reason than I > wouldn't want to face your wrath again in IETF Last Call. :-) "Wrath" has to count a pretty speedy escalation in terms, and especially when I'm so shy and retiring about saying what I think:-) I'm also confident that that security considerations will cover this topic in some sense. I'm not confident that I understand the relevant consequences at this point in time, so ISTM useful to mention it in the charter as that might help later. >=20 >> I'd be even happier if the resulting spec had a bunch of MUST NOT >> statements about that, if such statements were likely to be >> effective. >=20 > All MUST NOTs are only partially effective, but we use them anyway > to help good implementers.=20 Agreed. And sometimes we use them to describe damaging things bad implementers might otherwise be likely to do without realising the downsides. > If you have some proposed MUST NOTs on > the current document, by all means send them in. Probably better in a different thread, but I think there is scope for a MUST NOT (re-)use answers outside the same origin, but I've no doubt there are subtleties there that the WG would need to figure out and that'd make this sentence a bad idea to include on it's own. S. >=20 > --Paul Hoffman >=20 --tqUhNIHv5Q1qdKvs1K8pHunN0EkkceBgh-- --f4vb2pJImm1GENCLUMahUapFkDxTSwaDD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZvFUmAAoJEC88hzaAX42iYvkIAJ5oav+HntexG4LyFB+7oFFD wfSbitWs7HwcJOeu7R0PC5RuzIgM4V/A62PyipJ/JWREBAIy/O+LirjjM4xU5/Cl Su8VinAG/vdRAp8yhMFyTCYzkBAsSSjOuEQ/P3zxDoCcuBSJIIhyGgvHCsaKZXUp Ui9PcsuLxLLixZRL5DU0PEdqgPjih1wUDJOaYz6bVLyTDdiJRw0YAcfoxEry/bpa EzFitzgSJDzLEyUlHf2K11NBCrzGqa/OS8PqJiwPLryfHOrfaO8+Hv9P9je/UIWG uPAqVm8/K0Zl3IabQWu5kfF3Hp7lvIIONXu1zs1K6NaN9K8zOrdBu1aFNmQ12+k= =pjer -----END PGP SIGNATURE----- --f4vb2pJImm1GENCLUMahUapFkDxTSwaDD-- From nobody Sat Sep 16 02:54:40 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D76132C2A; Fri, 15 Sep 2017 18:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=RQb11Z1N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fGqr4cFq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGIv1PvQvKq8; Fri, 15 Sep 2017 18:51:53 -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 9C1CC13235A; Fri, 15 Sep 2017 18:51:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 0EB7D20D9A; Fri, 15 Sep 2017 21:51:53 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 15 Sep 2017 21:51:53 -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:x-sasl-enc; s=fm1; bh=iUnT+0AfzkX7ORB672 7dQoBYeiPhQcTzvoD16hNBXJ4=; b=RQb11Z1NzKOPARKaDqFSdfLWQvAr6/z30C UfSWvEIdieXmUmReJ2rnqKWW7YPv6nse4ZOLPW+GmOC9BK22MeX2zBoxTXIkGTeD FgLMqiVIyXX5yE1qjowIM8npRXK77qBowHI6oM7SAm4lonwSw+u6UTLoMEQoBfyY qNkzOHLsJu35DvpvwXInCvb+0fyOPo+ZuLtcrxwWrxzBIFlH4TlA51DRuFL8f0Lj SzA70N0yGxi6YkMhZH0+X90hKrBxDAoTn7g2X99EJz/s/68JTAEHWL/W9xZLRi2g ClcHvRn30rQeBBhzDi4tpB/sGULvA4O5kmQhTDUeVk4k7/BqShOQ== 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:x-sasl-enc; s= fm1; bh=iUnT+0AfzkX7ORB6727dQoBYeiPhQcTzvoD16hNBXJ4=; b=fGqr4cFq Y5ga/TJjP+WFrRBAEHtI3jvNxaKkL38xU1I6jankJNZn8H4uEuBrot9jri+OobxP jfF/pWm58x/bgTfNnReHbkw23BHrSMYFrfhb/jHucLXE92I0tRuFIBSlRnYhcqNc Y2zPaNF0DaUnINr6DdAOtJwXCbwQfTw1GzRLSq9sfvOgy5UPMljgtpQtIqFuKanj yQ6U6AJi1YVW9TCbTPuZ/nfSuBE0d8oNPIP9rbXQ7C4HWIKS1SnpR+vS2YlKvCZA KsIgZCPBd5KS3s+u5sP3IDuv7dHZX5HrlN++yJJQCSP8VqIeLi/T/Z4FSmrbdgmf P56xvAUMH3mEZg== X-ME-Sender: X-Sasl-enc: mQDwf9TKya/gW49KITadGp1TjUKURs9oVqrp7ewQ+dCc 1505526712 Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 2C97C7E446; Fri, 15 Sep 2017 21:51:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sat, 16 Sep 2017 11:51:48 +1000 Cc: Ted Hardie , doh@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> To: Paul Hoffman X-Mailer: Apple Mail (2.3273) Archived-At: X-Mailman-Approved-At: Sat, 16 Sep 2017 02:54:38 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 01:51:56 -0000 On 16 Sep 2017, at 4:24 am, Paul Hoffman wrote: >=20 > On 15 Sep 2017, at 9:44, Ted Hardie wrote: >=20 >> I appreciate the charter's use of "HTTPS" as a signal that these are >> intended to be TLS-protected HTTP sessions. I note, however, that = there is >> considerable ambiguity still present. HTTPS can mean HTTP 1.1 over = TLS, >> HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon = (in some >> deployments it already means that). The document named as input = specifies >> HTTP/2 over TLS. While the working group may, of course, change = that to >> support HTTP 1.1 and/or QUIC, it might be useful for the charter to >> indicate which of these is potentially in scope. >=20 > Yes, please. The charter should say "HTTP/2 over TLS". There is no = reason for current browsers adding this feature to add it using an = obsolete protocol. If someone wants to create a diff from the eventual = protocol for HTTP 1.1, they can do that without forcing the document to = add a comparison of the two transports to what is supposed to be a = short, concise document. Whoa; hold it right there. Last I checked, we had only obsoleted = HTTP/0.9; 1.1 is still very actively used, still on the standards track, = and despite some peoples' wishes, needs and gets attention. >> If the community is sure >> now that HTTP over QUIC is in scope, for example, having that noted = in the >> charter by adding the QUIC working group to list of working groups to >> consult would be useful. >=20 > The deadline for this WG is well ahead of when HTTP-over-QUIC will be = finalized. Instead, when HTTP-over-QUIC is finalized, an update to this = document should be pretty easy to produce. I don't understand why anyone thinks anything would be required at all; = if QUIC does its job properly, any application defined for HTTP/1.1 or = HTTP/2 should work on HTTP-over-QUIC (whatever we end up calling it) = without any changes.=20 >> (This is in part because of the choice to use the udp wireformat as = the >> baseline HTTP response here, rather than specifying DNS responses = over a >> transport construct like a QUIC stream. The working group could, of >> course, change that, but it would seriously shift the direction of = its >> input document to do so). I interpret the charter to say that this protocol is *using* HTTP, in = the sense of . In that view, = this WG *cannot* change that. >>> Specification of how the DNS data may be used for new use cases, and >>> the discovery of the DOH servers, are out of scope for the working = group. >>>=20 >> While it is useful to know that discovery is out of scope here, I = think >> having a quick community discussion now of where it might be in scope = is >> useful. There are some potentially interesting questions buried in = that, >> especially in how we expect interworking with existing systems to go. >> Note that even if the service discovery method provides an HTTPS URI = for >> the name server, the questions above related to HTTP version or = transport >> may bite you. For server discovery based on address and port, the >> situation is much the same unless the port is clearly marked as TCP = or >> UDP. And if the server discovery includes no port at all, then a = happy >> eyeballs type method may be needed. >>=20 >> This may all fall into a combo of DHCP and DNSOP work, but giving = somewhat >> clean lines for it now seems like it will make the later work go = faster. >=20 > If you want to propose a new WG for that, please do so; there are a = lot of people interested in that topic. It definitely goes across = multiple areas of interest, such as "discovery" and "addressing" and = even "trust". Personally, I don't think it applies to a transport = document. I agree that it's a preferable separable rathole. >>> Milestones: >>>=20 >>> Apr 2018 - Submit specification for performing DNS queries over = HTTPS to >>> the IESG for publication as PS >>>=20 >> I admire the optimism in this. >=20 > It was not optimistic with the charter that was originally sent to the = IESG; see . As = more issues are added to the charter, it makes sense to have to extend = the milestone deliverable. I'd prefer to keep the current milestone by avoiding additions. -- Mark Nottingham https://www.mnot.net/ From nobody Sat Sep 16 02:54:43 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1081341EB; Fri, 15 Sep 2017 18:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=XfiEahMp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C1vlnH1S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShQx3R8gYghK; Fri, 15 Sep 2017 18:53:01 -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 8540C129C41; Fri, 15 Sep 2017 18:53:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E120E20D86; Fri, 15 Sep 2017 21:53:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 15 Sep 2017 21:53:00 -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:x-sasl-enc; s=fm1; bh=RgqHvZXvQlQO94uL/X KiGVDXGRSewuWEjd6YyjyxgIg=; b=XfiEahMpuKXtqQFXsBTxtzduGsGcLzn50S rIEnxdISPajdq+kyWXrZ13aXHv2ZxFQKvp5eOXUCRwGQe1ExFFY9QSxYgitdOZ1m 9pkNUVsWqcEny2dlhrH82prE90ZZ6bkJMjZeSRo0xGAn4luLU7zI6a+hsd0Pzwh6 +PKP1wHFsGGwoWSMT/DxcLKJNnXEaZuxS4awTLB6Fr2YdBP6GnBoXrtn9faC8STk XQA9+qx1MbCxGSLWKspfj3KQfsYXpxAEvlcc4VdskyFQFWMtEIG3v96edq069Yq6 blMxdHMw6MRnUhTDzFxWimEFVQE8jr2NmC8frtj42/LQmz7agMcw== 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:x-sasl-enc; s= fm1; bh=RgqHvZXvQlQO94uL/XKiGVDXGRSewuWEjd6YyjyxgIg=; b=C1vlnH1S XcMBnuNF0WYYwzGxXtnjT+wdnPknuRHnmnlUa5cXrrPlKCAuRBUsL/7zi9jwS8pY nk7dWW9/zcdTbjEQBAotmWss1jZgDLhUCzWFjihzfwVJyMEIIIk9F2voKPXP+fCo QBRHZWmOdj5qShipyeKZ47t4C3N0aTzgaki8H5jEbNjC9P0d5Lk4w0iMWaHh5RQ5 gxcTAjsPfpiLy5oFHFhJZPGR4Evl70CeOXeoPVilhDja+antOPIKkpQQCPnta6/U Zaqazq8iQB/9wcoIQkLxAJwACUWm8LUCFk/L8yvNA1IrrCizuIz44r/mIRFm/jWB Ti0ei1sU1FCrAg== X-ME-Sender: X-Sasl-enc: XGx23Rydw1rT41OSlpJCodNS4P/uceuM8F06DrNvWnj8 1505526780 Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 4D1987E446; Fri, 15 Sep 2017 21:52:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sat, 16 Sep 2017 11:52:57 +1000 Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: X-Mailman-Approved-At: Sat, 16 Sep 2017 02:54:38 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 01:53:03 -0000 > On 16 Sep 2017, at 6:53 am, Ted Hardie wrote: >=20 > You're making an assumption that I don't think is established, that = the requests using HTTPS for DNS are not distinguishable from other = resources. If they were keyed by something like = dnsh://authority/query-target?RR (to pick on poor old RFC 4501 again), = they would be in JavaScript *even if they were not on the wire*. As before, I read the charter as saying that this protocol will use HTTP = in the sense of -- i.e., = defining a new URI scheme is out of scope. If that's not clear, it = should be made explicit. -- Mark Nottingham https://www.mnot.net/ From nobody Sat Sep 16 02:54:47 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEEA1320C9 for ; Fri, 15 Sep 2017 19:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_SORBS_SPAM=0.5, 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 M_7LoiVka0yA for ; Fri, 15 Sep 2017 19:23:32 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC88126B7E for ; Fri, 15 Sep 2017 19:23:32 -0700 (PDT) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 1615C3A01B for ; Fri, 15 Sep 2017 22:23:31 -0400 (EDT) Received: by mail-lf0-f46.google.com with SMTP id l196so3938337lfl.1 for ; Fri, 15 Sep 2017 19:23:31 -0700 (PDT) X-Gm-Message-State: AHPjjUgZhSr/T6cBEGW44ocv6K/X2nX/DVEyvQA8v1hvhG4BKjOAsXz7 Lr/jNRgON7iqiEBohB20EMSxx0pQpPQ8suTq/nU= X-Received: by 10.46.67.156 with SMTP id z28mt10327196lje.124.1505528609675; Fri, 15 Sep 2017 19:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.200 with HTTP; Fri, 15 Sep 2017 19:23:28 -0700 (PDT) In-Reply-To: <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> From: Patrick McManus Date: Fri, 15 Sep 2017 19:23:28 -0700 X-Gmail-Original-Message-ID: Message-ID: Cc: doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a114b522cfc89dd05594531e6" Archived-At: X-Mailman-Approved-At: Sat, 16 Sep 2017 02:54:38 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 02:23:34 -0000 --001a114b522cfc89dd05594531e6 Content-Type: text/plain; charset="UTF-8" Hi All. I'll respond to most of the key points in one message. Forgive the consolidation. * This is meant to be over "https" full stop. Whether that means we require a particular minimum level of version (which the input draft defines as >= h2 not == h2 btw) to satisfy the uses at hand is a controversy suitable for the wg to resolve. On one hand we should consider that semantic http has no versioning, so using the semantics from something like javascript becomes impossible to enforce the versioning requirement (though the server could do so). otoh you could argue that the mechanisms of <=h1 are not technically up to the task (hol blocking, lack of priority, etc..) of providing a reasonable implementation for a recursive resolver like use case.. or even argue that the IETF would have been better off historically across the board using new functionality as a forcing function for migrating to newer specifications rather than putting such a premium on backwards compatibility (or arguing against that based on bootstrapping costs, etc..). As I said - that's a controversy for the wg. The charter should be over https, and the wg can decide exactly what that means there is no need to litigate it in a charter discussion. * I believe adam and mnot are right on the questions of same origin, js, https:// uris.. * I think its fine for the charter to say the group must document the security considerations of the source of a name resolution. -P On Fri, Sep 15, 2017 at 3:33 PM, Stephen Farrell wrote: > > > On 15/09/17 23:04, Paul Hoffman wrote: > > On 15 Sep 2017, at 14:44, Stephen Farrell wrote: > > > >> On 15/09/17 20:25, Ted Hardie wrote: > >>> > >>> This set of questions is pretty different from the ones you get > >>> with "function over different paths", because the locus of > >>> control moves from the mostly-trusted browser to the mostly not > >>> trusted downloaded application. > >> > >> FWIW, I share Ted's concerns about origins. Regardless of what > >> approaches are taken, the effects of this need to be well > >> understood I think. I don't object to the WG being chartered though > >> but would suggest that there be a mention in the charter that the > >> WG needs to document the consequences, including the dangers, of > >> caching and re-use of DNS answers for likely implementations. > > > > The charter already points to the document that the work will be > > based on, which has that topic in it, because *you* pointed it out in > > the earlier discussion of the document. As co-author on the document, > > I assure you we will not remove it, if for no other reason than I > > wouldn't want to face your wrath again in IETF Last Call. :-) > > "Wrath" has to count a pretty speedy escalation in terms, > and especially when I'm so shy and retiring about saying > what I think:-) > > I'm also confident that that security considerations will > cover this topic in some sense. I'm not confident that I > understand the relevant consequences at this point in > time, so ISTM useful to mention it in the charter as that > might help later. > > > > >> I'd be even happier if the resulting spec had a bunch of MUST NOT > >> statements about that, if such statements were likely to be > >> effective. > > > > All MUST NOTs are only partially effective, but we use them anyway > > to help good implementers. > > Agreed. And sometimes we use them to describe damaging > things bad implementers might otherwise be likely to do > without realising the downsides. > > > If you have some proposed MUST NOTs on > > the current document, by all means send them in. > > Probably better in a different thread, but I think there > is scope for a MUST NOT (re-)use answers outside the same > origin, but I've no doubt there are subtleties there that > the WG would need to figure out and that'd make this > sentence a bad idea to include on it's own. > > S. > > > > > --Paul Hoffman > > > > --001a114b522cfc89dd05594531e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All. I'll respond to most of the key points in= one message. Forgive the consolidation.

* This is= meant to be over "https" full stop. Whether that means we requir= e a particular minimum level of version (which the input draft defines as &= gt;=3D h2 not =3D=3D h2 btw) to satisfy the uses at hand is a controversy s= uitable for the wg to resolve.

On one hand we shou= ld consider that semantic http has no versioning, so using the semantics fr= om something like javascript becomes impossible to enforce the versioning r= equirement (though the server could do so). otoh you could argue that the m= echanisms of <=3Dh1 are not technically up to the task (hol blocking, la= ck of priority, etc..) of providing a reasonable implementation for a recur= sive resolver like use case.. or even argue that the IETF would have been b= etter off historically across the board using new functionality as a forcin= g function for migrating to newer specifications rather than putting such a= premium on backwards compatibility (or arguing against that based on boots= trapping costs, etc..). As I said - that's a controversy for the wg. Th= e charter should be over https, and the wg can decide exactly what that mea= ns there is no need to litigate it in a charter discussion.
<= br>
* I believe adam and mnot are right on the questions of same = origin, js, https:// uris..

* I think its fine= for the charter to say the group must document the security considerations= of the source of a name resolution.

-P
<= div>

On = Fri, Sep 15, 2017 at 3:33 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:


On 15/09/17 23:04, Paul Hoffman wrote:
> On 15 Sep 2017, at 14:44, Stephen Farrell wrote:
>
>> On 15/09/17 20:25, Ted Hardie wrote:
>>>
>>> This set of questions is pretty different from the ones you ge= t
>>> with "function over different paths", because the lo= cus of
>>> control moves from the mostly-trusted browser to the mostly no= t
>>> trusted downloaded application.
>>
>> FWIW, I share Ted's concerns about origins. Regardless of what=
>> approaches are taken, the effects of this need to be well
>> understood I think. I don't object to the WG being chartered t= hough
>> but would suggest that there be a mention in the charter that the<= br> >> WG needs to document the consequences, including the dangers, of >> caching and re-use of DNS answers for likely implementations.
>
> The charter already points to the document that the work will be
> based on, which has that topic in it, because *you* pointed it out in<= br> > the earlier discussion of the document. As co-author on the document,<= br> > I assure you we will not remove it, if for no other reason than I
> wouldn't want to face your wrath again in IETF Last Call. :-)

"Wrath" has to count a pretty speedy escalation in terms,<= br> and especially when I'm so shy and retiring about saying
what I think:-)

I'm also confident that that security considerations will
cover this topic in some sense. I'm not confident that I
understand the relevant consequences at this point in
time, so ISTM useful to mention it in the charter as that
might help later.

>
>> I'd be even happier if the resulting spec had a bunch of MUST = NOT
>> statements about that, if such statements were likely to be
>> effective.
>
> All MUST NOTs are only partially effective, but we use them anyway
> to help good implementers.

Agreed. And sometimes we use them to describe damaging
things bad implementers might otherwise be likely to do
without realising the downsides.

> If you have some proposed MUST NOTs on
> the current document, by all means send them in.

Probably better in a different thread, but I think there
is scope for a MUST NOT (re-)use answers outside the same
origin, but I've no doubt there are subtleties there that
the WG would need to figure out and that'd make this
sentence a bad idea to include on it's own.

S.

>
> --Paul Hoffman
>


--001a114b522cfc89dd05594531e6-- From nobody Sat Sep 16 09:15:53 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD26133075; Sat, 16 Sep 2017 09:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB0uCYwoPdjF; Sat, 16 Sep 2017 09:15:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF2C124B18; Sat, 16 Sep 2017 09:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2D9D6BE4D; Sat, 16 Sep 2017 17:15:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiX9KjxsmyFq; Sat, 16 Sep 2017 17:15:41 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF982BE39; Sat, 16 Sep 2017 17:15:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1505578541; bh=x9kK0rVe+ACzlHhteZMjoBoRMtdqdF6Xbn/iYGH8zSw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YVMHxBZROnYpcGTG+Qcp/Y3B+n39emSfXmd3QJdGIpyUmtsJ9Z6TtNC0af/iIV4nQ mb1vi13T0MQzhH9fgrtslUClgJa9TqIpFy+bhqcqK3SOPaJ+yH/pbwCChR32hn13D4 Au4ZmyZSL5/BebM1rxq2wtJv71j+kDN4Exfs72Lg= To: Phillip Hallam-Baker , Patrick McManus Cc: doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 16 Sep 2017 17:15:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oItGIV4kQ8E0QraN7kgdRX2RMSeVDFw4B" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 16:15:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oItGIV4kQ8E0QraN7kgdRX2RMSeVDFw4B Content-Type: multipart/mixed; boundary="6ABHIJVsaAixOhUVlqfCghd9VKDGR2P9o"; protected-headers="v1" From: Stephen Farrell To: Phillip Hallam-Baker , Patrick McManus Cc: doh@ietf.org, IETF Message-ID: Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> In-Reply-To: --6ABHIJVsaAixOhUVlqfCghd9VKDGR2P9o Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 16/09/17 17:07, Phillip Hallam-Baker wrote: > We had a re-run of the same issues with DPRIV which began with the > assertion that a solution must be found within a year.=20 I don't recall any such assertion. IIRC, DPRIVE was always considered as the start, within the IETF, of a marathon. (At least by anyone credible.) Perhaps you can provide a pointer to that assertion? Aside from that, I'm not clear who you think is being ignored with the current proposal, nor what you think we ought wait upon, so it'd help me understand your objections if you could clarify those aspects. (FWIW, as of now, I don't share your concerns in those respects at all.) S. --6ABHIJVsaAixOhUVlqfCghd9VKDGR2P9o-- --oItGIV4kQ8E0QraN7kgdRX2RMSeVDFw4B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZvU4sAAoJEC88hzaAX42i24YH/098cfaeG0DQy2OjTZhHuVqC 13t82sS4KMA7aYEFMA6MShQurZD+B4Y5fOMJcw/BVqgC5TMHDgxNGHt4A8stx9X7 0N9YJBQ7L1v0ooY1PwKD9NQFrrZDqWyVVcXkZ2RzFKjNjqaWb1X1kpfj/yy+xUUo 90hdFdbM2bwIYgSVvTgvd5x2N01ve6jxMEwX7O6ndESyJuiPpog4QS4eWt8Lfrs3 I8IPB1H9K4HoDiT+fYYQB9malMCjRs+Q/qi+lhEaoMxjgEdikTpgk66fyqUAMGLF UrJNY1fwwQ5/41KAdVH3aYcQV8rx79xDZ6lxkrEzLgo94jnXV4+aAD2Dytlhmwk= =mEz8 -----END PGP SIGNATURE----- --oItGIV4kQ8E0QraN7kgdRX2RMSeVDFw4B-- From nobody Sat Sep 16 10:33:18 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358C413263F; Sat, 16 Sep 2017 10:33:16 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wj1JhFXdwZF2; Sat, 16 Sep 2017 10:33:13 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 66F301321CB; Sat, 16 Sep 2017 10:33:13 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id u67so4405537qkg.6; Sat, 16 Sep 2017 10:33:13 -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=p63N2iBtZSJISZRxo1UnBHOQkSpZezxUk2jl6lCYOzs=; b=hhjKSL/vBCWrDJIKTwUUfEFwFvBhOEWaYNxhSaTNONTXY+Cb376EbLEzj1wH5ZH/lU l7xX8JfMEmbBLrTat/rQxXbQHNnx9m9aLR+tr1Ja1Yw/JIJjtatfQCeLMPV5fnJtA6K6 BlA/+n9PkePDtmg2lRnk44ZVJ2RqNtoIrvIMpmlD0XOTml4z+ibio9z5dYkoLsIQJuwC xesn5klzYZI1WoRGg6JDRZu/+DmvitoaIr99lp9V1xAWQVUeO12hQSttccgeXpn8PdOV 5TLeQGApRkqDYvFOjr7HgEV7Pe5rsoZch9fjffsizJ9+A8EEMH/Y7UPuTnjEdlCQpwb2 BPIg== 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=p63N2iBtZSJISZRxo1UnBHOQkSpZezxUk2jl6lCYOzs=; b=NqCquPYXh2GOJITw/4eNrgEkUcJlBScMqf0qX/da0aTok1BGvzCy3KG+e7S5iTSiWL 8Pquq7uasr4Kt+oasi59u3Ya6WqNtnq18pReZhwy6P3yShiMECP3aqaDI+x+xIUdPlHj yuHTCv5PTuRQe+7c8F57667M/Bgfh4ysmkeN1F3Foad3ntHfEY/v6y3hSksiyozLvTgN RAUDQQo351P6hQKpAbJPk//vw96BPNsI/kPYA2hlbqm68bNepSge2DsN7wAyPlaWs1pC YaVjL78mfQLvwOpgrEvTy6lrECY3UzFuNtDJYxNOh3VGZ8Kj7IICMJlH+g5o9K6M94WT hw+g== X-Gm-Message-State: AHPjjUhsXtoqMFACGwa0uGSfJAv4ikoBuwh7ZdEVRH9j+jUKVD3RGUYO e/fjVv7uO7dBXhayh5grquhjaTtfGXYjDXo6KYg= X-Google-Smtp-Source: AOwi7QD6To+X7Nf4QBDkkY1aMcnAFifKBZAVHLTB4p38jokQQh98E046X/GVlDTMgvFlXDDw6gSrNbqqnNIql/xB7qQ= X-Received: by 10.55.123.1 with SMTP id w1mr13535542qkc.114.1505583192249; Sat, 16 Sep 2017 10:33:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Sat, 16 Sep 2017 10:32:41 -0700 (PDT) In-Reply-To: <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> From: Ted Hardie Date: Sat, 16 Sep 2017 10:32:41 -0700 Message-ID: To: Mark Nottingham Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Type: multipart/alternative; boundary="94eb2c063b485a99be055951e73e" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 17:33:16 -0000 --94eb2c063b485a99be055951e73e Content-Type: text/plain; charset="UTF-8" On Fri, Sep 15, 2017 at 6:52 PM, Mark Nottingham wrote: > > > On 16 Sep 2017, at 6:53 am, Ted Hardie wrote: > > > > You're making an assumption that I don't think is established, that the > requests using HTTPS for DNS are not distinguishable from other resources. > If they were keyed by something like dnsh://authority/query-target?RR (to > pick on poor old RFC 4501 again), they would be in JavaScript *even if they > were not on the wire*. > > As before, I read the charter as saying that this protocol will use HTTP > in the sense of -- i.e., > defining a new URI scheme is out of scope. If that's not clear, it should > be made explicit. > > So, I don't that this is established. One mental model for this work is that DNS, having started with UDP and TCP as transports, has now added a set of additional secure transports. Two of those were defined in DPRIV; this defines another. From that perspective, any time an application requires a DNS name to be resolved, the relevant local code would try the set of secure transports until it got an answer. The application may not know which is used and does not specify it; it is simply getting the DNS answer back that allows it to proceed. The name of the group (DNS over HTTP), the justification at the beginning of the charter: This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) experience problems. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS, and DTLS) experience problems. and Paul's input draft all point to that interpretation. Note especially that Paul's draft provides the UDP wireformat as response. To me, that strongly hints that the results of this get handed to the same bit of code that would take the UDP wireformat from other transports (like UDP) and do what it would have done with data retreived from any of those. That behavior makes sense for DNS transported over HTTP, where you are talking to an authoritative server or shared resolver over a new transport. That order of operations does not make sense as a new resource type available to web applications, in part because they can't tell from examining the URI whether the resulting *resource* obeys CORS or not. There are serious attacks here that even DNSSEC won't catch, because a malicious server and cooperating JavaScript app could give correct answers that are non performant (like the search engine instance on the most distant continent). And, if there really was a handoff to the local DNS subsystem for parsing and processing, the JavaScript also wouldn't be able to tell whether the result they get from that subsystem is the one that the just retrieved (because a cache entry from some other system may have a different SOA record and be returned as a result instead). To avoid that, they would have build udp wireformat parsers into the downloadable javascript. I think if you want the second, a way of making DNS resources available to web applications, you need a very different approach; it may be valuable, but I don't believe this charter covers it. If it is meant to, it needs a major re-write. regards, Ted --94eb2c063b485a99be055951e73e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Sep 15, 2017 at 6:52 PM, Mark Nottingham <mnot@mnot.n= et> wrote:

> On 16 Sep 2017, at 6:53 am, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> You're making an assumption that I don't think is established,= that the requests using HTTPS for DNS are not distinguishable from other r= esources.=C2=A0 If they were keyed by something like dnsh://authority/query= -target?RR (to pick on poor old RFC 4501 again), they would be in Java= Script *even if they were not on the wire*.

As before, I read the charter as saying that this protocol will use = HTTP in the sense of <https://mnot.github.io/I-D/bc= p56bis/#used> -- i.e., defining a new URI scheme is out of scope. If= that's not clear, it should be made explicit.


So, I don't that this is established.=C2=A0 O= ne mental model for this work is that DNS, having started with UDP and TCP = as transports, has now added a set of additional secure transports.=C2=A0 T= wo of those were defined in DPRIV; this defines another.=C2=A0 From that pe= rspective, any time an application requires a DNS name to be resolved, the = relevant local code would try the set of secure transports until it got an = answer.=C2=A0 The application may not know which is used and does not speci= fy it; it is simply getting the DNS answer back that allows it to proceed.= =C2=A0 The name of the group (DNS over HTTP), the justification at the begi= nning of the charter:

This will enable the do= main name system to function over certain paths where existing DNS methods = (UDP, TLS, and DTLS) experience problems. This will enable the domain name = system to function over certain paths where existing DNS methods (UDP, TLS,= and DTLS)
experience problems.=C2=A0

and Paul's input draft all point to that interpretation.=C2=A0 Note = especially that Paul's draft provides the UDP wireformat as response.= =C2=A0 To me, that strongly hints that the results of this get handed to th= e same bit of code that would take the UDP wireformat from other transports= (like UDP) and do what it would have done with data retreived from any of = those.=C2=A0 That behavior makes sense for DNS transported over HTTP, where= you are talking to an authoritative server or shared resolver over a new t= ransport.=C2=A0

That order of operations does= not make sense as a new resource type available to web applications, in pa= rt because they can't tell from examining the URI whether the resulting= *resource* obeys CORS or not. =C2=A0 There are serious attacks here that e= ven DNSSEC won't catch, because a malicious server and cooperating Java= Script app could give correct answers that are non performant (like the sea= rch engine instance on the most distant continent).=C2=A0 And, if there rea= lly was a handoff to the local DNS subsystem for parsing and processing, th= e JavaScript also wouldn't be able to tell whether the result they get = from that subsystem is the one that the just retrieved (because a cache ent= ry from some other system may have a different SOA record and be returned a= s a result instead).=C2=A0 To avoid that, they would have build udp wirefor= mat parsers into the downloadable javascript.

I th= ink if you want the second, a way of making DNS resources available to web = applications, you need a very different approach; it may be valuable, but I= don't believe this charter covers it.=C2=A0 If it is meant to, it need= s a major re-write.

regards,

Ted
--94eb2c063b485a99be055951e73e-- From nobody Sat Sep 16 10:54:13 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCEA132A89; Sat, 16 Sep 2017 10:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s-e47nrv0bk; Sat, 16 Sep 2017 10:54:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 353FF1321D8; Sat, 16 Sep 2017 10:54:10 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8GHs613097553 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 16 Sep 2017 12:54:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ted Hardie , Mark Nottingham Cc: doh@ietf.org, Paul Hoffman , IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> From: Adam Roach Message-ID: <2d532b20-2c7f-af06-e17c-a929ec85a63f@nostrum.com> Date: Sat, 16 Sep 2017 12:54:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 17:54:12 -0000 On 9/16/17 12:32, Ted Hardie wrote: > To avoid that, they would have build udp wireformat parsers into the > downloadable javascript. To be clear, in the scenario I outlined, that's exactly what I was intending to describe. It hadn't even occurred to me that one might form a model, based on that description, that involved routing the information through the local, OS-level stub resolver. Now that you've clarified that confusion, I agree: a system that did so would be terrifyingly difficult to secure. Let's not do that horrible thing. And I hope my previous explanation was clear: this isn't the primary use case for this work; I used it in my example because it was a very easy way to explain the layering issue to anyone with a basic understanding of the web platform. I wouldn't over-rotate on it. (That said, I know that several people are watching this work precisely because they do want to perform these operations in JavaScript. The input draft does not preclude doing so, and I see no reason to artificially limit the mechanism in a way that prevents it.) /a From nobody Sat Sep 16 20:00:22 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AB113235A; Sat, 16 Sep 2017 20:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=MCZe47+U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KM7AIHTa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36N7OdF092aW; Sat, 16 Sep 2017 20:00:17 -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 712AB1200F3; Sat, 16 Sep 2017 20:00:17 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B04B3229CB; Sat, 16 Sep 2017 23:00:16 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 16 Sep 2017 23:00:16 -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:x-sasl-enc; s=fm1; bh=MHkLihSi1DlQy4RloW ZCHb1KazvL8dxnKfq6tQc29FU=; b=MCZe47+UZqrqhjh4kgv284Ng1c+TPwIG38 E7hiUD6LHnOqVnexzc4tzOCBODLEpIyOC3zYn9xKUfnZik3KPCuGKOsoPd24Jb9i vH3hQah0nWIxgX2f5SQAGTE5ViDPpAfDee1UAhGn243wfJ5afcYdDoTEBhckt2T4 LcQrYgURzs1AKf5WeFaJh3XbHPnJyRSfz2sQPlFE4mYIl2iAAaMYxMKs/wlsCE/b nIYkN0RwKkiJUeQIp4H7pqQ8vFnI9PGdjWZ+N2U7IcLzRIQQn6SoqG68d0BQO+D2 2fvwvIrIW6Hd/owBxEXJlJCezZzqMMJn+AFmZvemE4DWnnqM73Tg== 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:x-sasl-enc; s= fm1; bh=MHkLihSi1DlQy4RloWZCHb1KazvL8dxnKfq6tQc29FU=; b=KM7AIHTa wdMEMAWfX9pZSKGHzIkDcn8CytAuV6JePkckzzacVwn3OKtPNTMtVjyqVra0PqDd ztnxuZdVnGv1zFv7v5J8KxlHKcc4USwHbPUeGDTyZ5BXFKJ9PM02E5M4aMS6INDG JLoylZ9sKlR+URXo6d3H+qRiH4K7nfv8b2KER8ftsVQSzMpRzoqorEpYPA2wETo1 RxZg+7QmPDEo2IVukOlQ9JB16d/a62kk+w2uDwCFeox/dtXisitqsvyJYKjOhzpi 3mN1HGB4ZhcQyXShTQhnRgEULz478nO6YpWT1neVY/LPHWa2DTAuWk3wFXczi7Y0 dRSzTopK1Z/JPA== X-ME-Sender: X-Sasl-enc: ReVuDNhKy0tDFL/6Gn7M8RNADG58iKa6rUKmhRzzB9G3 1505617215 Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D6B87E5EE; Sat, 16 Sep 2017 23:00:14 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sun, 17 Sep 2017 13:00:11 +1000 Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sun, 17 Sep 2017 03:00:20 -0000 Ted, On 17 Sep 2017, at 3:32 am, Ted Hardie wrote: >=20 > On Fri, Sep 15, 2017 at 6:52 PM, Mark Nottingham = wrote: >=20 >> > On 16 Sep 2017, at 6:53 am, Ted Hardie wrote: >> > >> > You're making an assumption that I don't think is established, that = the requests using HTTPS for DNS are not distinguishable from other = resources. If they were keyed by something like = dnsh://authority/query-target?RR (to pick on poor old RFC 4501 again), = they would be in JavaScript *even if they were not on the wire*. >>=20 >> As before, I read the charter as saying that this protocol will use = HTTP in the sense of -- = i.e., defining a new URI scheme is out of scope. If that's not clear, it = should be made explicit. >=20 >=20 > So, I don't that this is established. One mental model for this work = is that DNS, having started with UDP and TCP as transports, has now = added a set of additional secure transports. Two of those were defined = in DPRIV; this defines another. =46rom that perspective, any time an = application requires a DNS name to be resolved, the relevant local code = would try the set of secure transports until it got an answer. The = application may not know which is used and does not specify it; it is = simply getting the DNS answer back that allows it to proceed. =20 Every time people start talking in this manner and referring to HTTP as = a "transport", I get flashbacks to WS-* and what a glorious failure that = was. > The name of the group (DNS over HTTP), the justification at the = beginning of the charter:=20 >=20 > This will enable the domain name system to function over certain paths = where existing DNS methods (UDP, TLS, and DTLS) experience problems. = This will enable the domain name system to function over certain paths = where existing DNS methods (UDP, TLS, and DTLS)=20 > experience problems.=20 >=20 > and Paul's input draft all point to that interpretation. Note = especially that Paul's draft provides the UDP wireformat as response. = To me, that strongly hints that the results of this get handed to the = same bit of code that would take the UDP wireformat from other = transports (like UDP) and do what it would have done with data retreived = from any of those. That behavior makes sense for DNS transported over = HTTP, where you are talking to an authoritative server or shared = resolver over a new transport. =20 I don't disagree that the charter lays out that the goal is to enable = the use case of DNS using HTTP semantics -- that's hopefully = uncontroversial. > That order of operations does not make sense as a new resource type = available to web applications, in part because they can't tell from = examining the URI whether the resulting *resource* obeys CORS or not. It's not clear why that's an important property. Why is it necessary? > There are serious attacks here that even DNSSEC won't catch, because a = malicious server and cooperating JavaScript app could give correct = answers that are non performant (like the search engine instance on the = most distant continent). =20 Who would be consuming these answers? How is this different from = configuring your system to use a malicious DNS resolver (either in an = application or the OS)? > And, if there really was a handoff to the local DNS subsystem for = parsing and processing, the JavaScript also wouldn't be able to tell = whether the result they get from that subsystem is the one that the just = retrieved (because a cache entry from some other system may have a = different SOA record and be returned as a result instead). To avoid = that, they would have build udp wireformat parsers into the downloadable = javascript. >=20 > I think if you want the second, a way of making DNS resources = available to web applications, you need a very different approach; it = may be valuable, but I don't believe this charter covers it. If it is = meant to, it needs a major re-write. I agree there are significant risks when using DNS. I think the question = is what to do about it. One thing the WG could do would be to write some Security Considerations = about the different ways this could be sub-optimal or even dangerous.=20 I don't see how giving the protocol a new URI scheme avoids these risks, = given that the defined resources would be available over HTTP still. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Sep 17 10:27:44 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E906313307D; Sat, 16 Sep 2017 09:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kQnLWnvfaW3; Sat, 16 Sep 2017 09:07:50 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73671321A1; Sat, 16 Sep 2017 09:07:50 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id t21so1887923oih.6; Sat, 16 Sep 2017 09:07:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0rAvSW2LpORwAWA4TeXlb8kifxl0Lq5pyEsdLNH+gxY=; b=NTNJiw/QyD6xVzQqFfLzmt6vF3uaBjCTgsFc8CaRvphR6DSw90/Xg3bLfnFO0ykZ1O jpYtSKrxgUfl6rpoWZnvHK0wNUPVZWZXuO2U8KJqOzAH65NlnyXH1CtKK99csanCJ6oq BRmgqb4jvKWUD267J0whlsEM9PRIGgs9YY1PZi7w9S83+QAxqPuH+h1Cx3pnaUzatKez Ndi+AIUSaDJczx0EwolKfr3MKQuauXE9mdbstG5YZM4OwcXde2IXup/TL3VWUNQL+ACU VAeBH+uSNDdrVRZfsHuK2eQCYPDBTYObArctexDjHImIXKdhJod/lQGpAdcQPL6Uogr2 90QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0rAvSW2LpORwAWA4TeXlb8kifxl0Lq5pyEsdLNH+gxY=; b=EsRGYXwoDLn43bsBA7RB9AAKEGRiK4EZsaGwLWwdrpN4bOm7jn38ilGjyCqXmNcPLS VxVlL5DRj1S3LPDmMLxQq9P2HzAuNYATO+gRPMXnUmhZkHZQH6p7Br373JetaDcS6e82 VBcGKRdg8mdmMh3BxBY+ct0DUDqDnNb1ryDZBPCFdICF7JzNIUQNuXsdCDhy+1BDnBl+ vpw/sXGYx+hNICfZaORLvvl+k10VIOn8uzRCk/uj/dkL50inDhO2I20lLFjqYU4bT/7Y wUXcq3tbasjqkAOs/5ceC9zf3265TBXwavsK2bqp3mLmdHxF1lfnOyZOsIUNJs2QmH8b JEzw== X-Gm-Message-State: AHPjjUi8Xe2BWHX58eCo7iCmAVQxt6YNY/9VoDxNLQd84wf+3NEEK+tD jl60YNEqjPBLyBKg+q1QBblXSSijWCSxr2WURCk= X-Google-Smtp-Source: AOwi7QBBmLX4Kt6R+PrVAjqHCDXlfF11l31LacmRa8/kgBLeZjxwTvrj99H+FQKiqP8O6Cski1VETCbNs8uAXi2wKM8= X-Received: by 10.202.59.87 with SMTP id i84mr5758547oia.166.1505578069710; Sat, 16 Sep 2017 09:07:49 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Sat, 16 Sep 2017 09:07:48 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> From: Phillip Hallam-Baker Date: Sat, 16 Sep 2017 12:07:48 -0400 X-Google-Sender-Auth: Ld4vIl-3vhkVveoJx5r1HrDQjLc Message-ID: To: Patrick McManus Cc: doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a113cf8d006e799055950b6f6" Archived-At: X-Mailman-Approved-At: Sun, 17 Sep 2017 10:27:43 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sat, 16 Sep 2017 16:07:53 -0000 --001a113cf8d006e799055950b6f6 Content-Type: text/plain; charset="UTF-8" Responding to the thread as a whole: 1) I see no evidence that HTTP/2 is suited to Web Services or will be dominant in that role. HTTP/2 was designed to serve Web Browsing to the exclusion of all other concerns. Which was the right choice to make. Web Services that are not merely information fetch protocols rarely make any use of HTTP features at all except for framing and to increase the number of ports by using URIs as ports. Raw TCP/IP transport is no longer practical due to the large number of firewalls and NATs and 2^16 ports would be insufficient anyway. 2) Web Services over some form of QUIC are almost certain to be popular. QUIC addresses pretty much the exact same set of concerns that the use of HTTP/1.1 for Web Services does and finesses the problem of TCP/IP being designed for a different age. If QUIC was not being developed, a lot of Web Service developers might well look at HTTP/2 but as things stand, I have zero interest in HTTP/2 because I know that it is a dead end for Web Services. This is a *good thing* BTW. There are only two types of traffic: Web Browsing and non-Web browsing. Does it really make sense to suggest that they both over the same protocol? 3) This is the wrong time to do this work. Failed experiments come at the cost of creating obstacles that get in the way of real progress. The same argument is made every time one of these experiments is proposed and we get the same result. During chartering the argument is "We are just concentrating on one problem, this does not exclude anyone else", After the working group is chartered it is "Hands off our turf", after the RFCs are published and nobody is implementing them it is "we tried and we proved that nobody else could have solved the problem". There is a growing list of these failed projects, lets just pick DANE. DANE was meant to be a way to publish TLS certificates and to communicate 'must use TLS' security policy. There are numerous technical and commercial reasons that combination was doomed to fail even if the deployment platform was not DNS which makes the difficulty of everything squared. The proposal did not have support from the Web Browser providers whose co-operation was essential and killed attempts to sell DNSSEC through DNS Registrars (most of whom make their margin on WebPKI affiliate fees). Input from all stakeholders was rejected. If you recall, CAA was originally proposed by myself and Ben Laurie of Google. The reason Ben dropped out was that I was forced to remove the security policy dimension of CAA. Now given that CAs are now required to support CAA by CABForum, doesn't this mean that there was a real cost to letting the DANE group bully us out of that space? [This is not how I would do security policy now BTW, I would look to use the TXT records as described in RFC 6763 to incorporate the same sort of data that is specified in HTTP Key Pinning for Web Services.] We had a re-run of the same issues with DPRIV which began with the assertion that a solution must be found within a year. This restricted the range of technology solutions to a set that were utterly inappropriate. Currently, the WG is still functioning but it has no support from any deployment stakeholder I am aware of. The point I am making here is that DNS is the wrong layer in the stack for: * Working Groups with a narrow scope * Working Groups attempting to achieve a result in a narrow time scale * Working Groups that insist on owning the topic. * Working Groups that refuse to engage the necessary stakeholders --001a113cf8d006e799055950b6f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Res= ponding to the thread as a whole:

1) I see no evidence that HTTP/2 is suited to Web Services or wi= ll be dominant in that role. HTTP/2 was designed to serve Web Browsing to t= he exclusion of all other concerns. Which was the right choice to make.

Web Services that are not me= rely information fetch protocols rarely make any use of HTTP features at al= l except for framing and to increase the number of ports by using URIs as p= orts. Raw TCP/IP transport is no longer practical due to the large number o= f firewalls and NATs and 2^16 ports would be insufficient anyway.=C2=A0


2) Web Services over some form of QUIC= are almost certain to be popular.

QUIC addresses pretty much the exact same set of concerns that t= he use of HTTP/1.1 for Web Services does and finesses the problem of TCP/IP= being designed for a different age. If QUIC was not being developed, a lot= of Web Service developers might well look at HTTP/2 but as things stand, I= have zero interest in HTTP/2 because I know that it is a dead end for Web = Services.

<= /div>
This is a *good= thing* BTW. There are only two types of traffic: Web Browsing and non-Web = browsing. Does it really make sense to suggest that they both over the same= protocol?

=

3) This is the wrong tim= e to do this work.

Failed= experiments come at the cost of creating obstacles that get in the way of = real progress. The same argument is made every time one of these experiment= s is proposed and we get the same result. During chartering the argument is= "We are just concentrating on one problem, this does not exclude anyo= ne else", After the working group is chartered it is "Hands off o= ur turf", after the RFCs are published and nobody is implementing them= it is "we tried and we proved that nobody else could have solved the = problem".
=
There is a= growing list of these failed projects, lets just pick DANE. DANE was meant= to be a way to publish TLS certificates and to communicate 'must use T= LS' security policy. There are numerous technical and commercial reason= s that combination was doomed to fail even if the deployment platform was n= ot DNS which makes the difficulty of everything squared. The proposal did n= ot have support from the Web Browser providers whose co-operation was essen= tial and killed attempts to sell DNSSEC through DNS Registrars (most of who= m make their margin on WebPKI affiliate fees). Input from all stakeholders = was rejected.
<= br>
If you reca= ll, CAA was originally proposed by myself and Ben Laurie of Google. The rea= son Ben dropped out was that I was forced to remove the security policy dim= ension of CAA. Now given that CAs are now required to support CAA by CABFor= um, doesn't this mean that there was a real cost to letting the DANE gr= oup bully us out of that space?

[This is not how I would do security policy now BTW, I would look to= use the TXT records as described in RFC 6763 to incorporate the same sort = of data that is specified in HTTP Key Pinning for Web Services.]

We had a re-run of the same issues = with DPRIV which began with the assertion that a solution must be found wit= hin a year. This restricted the range of technology solutions to a set that= were utterly inappropriate. Currently, the WG is still functioning but it = has no support from any deployment stakeholder I am aware of.=C2=A0


The point I am making here is that DNS i= s the wrong layer in the stack for:

* Working Groups with a narrow scope
* Working Groups attempting to achieve a r= esult in a narrow time scale
* Working Groups that insist on owning the topic.
* Working Groups that refu= se to engage the necessary stakeholders=C2=A0


--001a113cf8d006e799055950b6f6-- From nobody Mon Sep 18 08:01:39 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E1F1332DF; Sun, 17 Sep 2017 11:24:09 -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 Li5i7VNx14AA; Sun, 17 Sep 2017 11:24:07 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 C32991321CB; Sun, 17 Sep 2017 11:24:07 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q11so14158328ioe.10; Sun, 17 Sep 2017 11:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cVysbBT7nGiA+m5LB9gCJsKzwWecVElpvdgjiJ4xZ3Y=; b=taKoGROe6HMroWVW6DWYpTS8+/bFbPsZQTjP+gPCPjHTN7ENtmT9oTxazJ5pPzvKE0 FE3IN074buZemD/IBfqarTnylEuYjuN5gxkWXARkKqLcVOZN1atrgXq8/5WAYjEMu/xk YNtXvIII6ijuU0TH8QcJwdZdJzqVT1q7NO43RW7kisFc1tCMqciMDYD8r/XOS19wItKP Upvutvm5TYYtPTToiJQNyUn+7/BtTOZSQJWwEaieDv98hkPySgGJEfVuiROfg9x3agW5 Okc94gzKORYmIhc89vQ+GXFcFjpkB82GdAt82yd220JD0/96eGXH9hj1BCmNhsWH+FQC gplw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cVysbBT7nGiA+m5LB9gCJsKzwWecVElpvdgjiJ4xZ3Y=; b=N4NJThz94hAbrJuEvr+OJuzZvf5F3numDBL6q5f7j2tuFYsR3uH3NWlD5/a/1EeUY0 Yfjuu/bxjV7W/Bs7/cHHvCyTHrrfarTW0D4+nFIWiZy/q7lJNi2LPZR3bbBt1nvNgb6o HubuvmcBkC0rpBmL2vYaJ2jOYrQn0ZapywDn5kcID8KM/QbU+EZ+TacW5KryzPJOYtNS ONib1Wf8a4rWgkYL8+9YfzT+4ofnT8XRaPNnyU9Vc554ezUTRxavmlZhgBAVq5hIq2A4 jehvrNnKNB/hO1YaSWiL90Ji1qNgB88vK39ob/9f1+E79+hkoagm+Qm9/u+MdjJrwotS BzXA== X-Gm-Message-State: AHPjjUhZJ7WaWa4X0Kj34uxjYoDHwUahfCxf8N4pmiFc8zbb9sZmp0Re Ot+eO9rudVQQHBBf X-Google-Smtp-Source: AOwi7QD72ViPg/FV8DLLbEM9Oilx3sbzIZRFh1Fv89vh7t8U6Qmcfm9UgpxPCHBDuUTbA9O2XZpUKA== X-Received: by 10.107.176.70 with SMTP id z67mr17688493ioe.81.1505672646690; Sun, 17 Sep 2017 11:24:06 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com (184-14-212-55.dr03.chtn.wv.frontiernet.net. [184.14.212.55]) by smtp.googlemail.com with ESMTPSA id k133sm476100itd.0.2017.09.17.11.24.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Sep 2017 11:24:05 -0700 (PDT) To: Stephen Farrell , Phillip Hallam-Baker , Patrick McManus Cc: doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> From: Tim Wicinski Message-ID: Date: Sun, 17 Sep 2017 14:24:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 18 Sep 2017 08:01:38 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Sun, 17 Sep 2017 18:24:09 -0000 On 9/16/17 12:15 PM, Stephen Farrell wrote: > > > On 16/09/17 17:07, Phillip Hallam-Baker wrote: >> We had a re-run of the same issues with DPRIV which began with the >> assertion that a solution must be found within a year. > > I don't recall any such assertion. IIRC, DPRIVE was always > considered as the start, within the IETF, of a marathon. > (At least by anyone credible.) > > Perhaps you can provide a pointer to that assertion? > > Aside from that, I'm not clear who you think is being > ignored with the current proposal, nor what you think > we ought wait upon, so it'd help me understand your > objections if you could clarify those aspects. (FWIW, > as of now, I don't share your concerns in those respects > at all.) > > S. > As DPRIV co-chair, I agree with Stephen's assertion that this was always going to be a marathon. Now Phillip is correct in some respects - I felt *a* solution for the stub to recursive resolver piece could be worked out within a year. But I've always felt the IETF was all about iteration: Let's come up with a solution; let's write some code and deploy some infrastructure; let's measure the behavior and the usefulness of what was done; and in the interim let's keep looking at other ideas. The next steps within DPRIV are around the recursive resolvers talking to authoritative servers; and this is something Terry (our wonderful AD) and myself see as a much harder problem, and one most likely that will end in failure. tim From nobody Mon Sep 18 10:20:59 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DC1132D4E; Mon, 18 Sep 2017 10:20:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWMJ6IoKYvHF; Mon, 18 Sep 2017 10:20:48 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 ED43C133018; Mon, 18 Sep 2017 10:20:47 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id j5so1233563qkd.0; Mon, 18 Sep 2017 10:20:47 -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=/KeUfW/KNVqkgDX152TrybMH8cEFoppRuB9gtpRwFAM=; b=TkJ5XBuEdXYqSIInwqqnQcNLe/cd03xy6i3HKe2JNdRw3JYiVAiuPKfDyuj7rMaiFn 3P1eW4RQZxAsCja0TiUKD5/rRM5WUWjZWN4Ydpen+xQfsW2JH2d5ECLYwUIcXL5wNaJm itb0qJGV154eidG5gkR+Cvgyd75bHpUuHAgarpB5vQDkIqWLqq9FLEYtt7bGTzgdguC9 Hf8YBtR9XnkHEJaqLke7kgUgk+quTB6mnYEdgaGDLBm43LgLYYOYf9hCkuLxVJo7RIEe /RVqjlRS96UejlT8yA79OB4pJYKZn/WxPIdqYE8xFbaVo16asQsys41ZVb/fwi3U4g9z 6Mfw== 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=/KeUfW/KNVqkgDX152TrybMH8cEFoppRuB9gtpRwFAM=; b=s92uXnCMsgcRc+Eu1AivS8ttqXyd7raABucWYN1Gy6F8Qvpe/qcCAfBF5Z0aDTMglE RcVIbBshnD7/toBT1rb72Owar1MmmCUZD22wc85xxo+VqoH07qnMkcQk4Ha/S3A0NSOG 9/T09YMEnhgSFvWGnQI731q5fQODyBnw2OvUeumxqdHGo3cldKeqv+ldGB6KlpAw+LMn 4RxcdY/Qn9eN3KK2Waw8EWwyoBrlN4jX4n1l372u5mL8hQA3OL8/E1MvznKDpJUC2gKM 6G58rVNPUKxi5RKA8ki0NJxyeCTEcwTWwPIjDH8O2SvPz+DQDGDciWE3inIvapFLLN8A 2vKg== X-Gm-Message-State: AHPjjUjjSJbn6oQQ6NUnJbCEsKInqgXlYzVeeRTqyGZz+IJecJgW1opZ 1dXSQIMfMdXW2lGji+5hj8oQ+HB4Q2BicFwt7ow= X-Google-Smtp-Source: AOwi7QBBJbC8r6Vu8VX5liuCEaXK6m54eBV2mD580BwCxZTQWYQy8k6/vAtlnVLecCKBxsePj2ntL0Pp/uYo//CDfWg= X-Received: by 10.55.18.137 with SMTP id 9mr21208957qks.208.1505755246861; Mon, 18 Sep 2017 10:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Mon, 18 Sep 2017 10:20:16 -0700 (PDT) In-Reply-To: <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> From: Ted Hardie Date: Mon, 18 Sep 2017 10:20:16 -0700 Message-ID: To: Mark Nottingham Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Type: multipart/alternative; boundary="001a11475fa29ba22e055979f644" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 18 Sep 2017 17:20:52 -0000 --001a11475fa29ba22e055979f644 Content-Type: text/plain; charset="UTF-8" On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham wrote: > > > So, I don't that this is established. One mental model for this work is > that DNS, having started with UDP and TCP as transports, has now added a > set of additional secure transports. Two of those were defined in DPRIV; > this defines another. From that perspective, any time an application > requires a DNS name to be resolved, the relevant local code would try the > set of secure transports until it got an answer. The application may not > know which is used and does not specify it; it is simply getting the DNS > answer back that allows it to proceed. > > Every time people start talking in this manner and referring to HTTP as a > "transport", I get flashbacks to WS-* and what a glorious failure that was. > > If it helps, I am happy to say "facilitating protocol". The mental model question for the charter is really: Does this add a new tool for DNS systems attempting resolution to use when previous efforts are blocked? So any DNS resolution might use it, whether from a browser, an app, or system call, but that those would not *specify* it be used? Does this add a method for Web application to directly resolve DNS resource records using a resolver self-identified in the Javascript? So DNS resolutions are instantiated and consumed by Javascript without any intermediation by the local DNS resolver or the browser's DNS rules? Does this charter aim for the working group to do both? As currently written, I see the charter describing 1. There has been an argument that it also do 2 or that 2 becomes possible when 1 is specified and is thus automatically part of the scope. If that is the case, I believe the charter needs a re-write to describe it. > > The name of the group (DNS over HTTP), the justification at the > beginning of the charter: > > > > This will enable the domain name system to function over certain paths > where existing DNS methods (UDP, TLS, and DTLS) experience problems. This > will enable the domain name system to function over certain paths where > existing DNS methods (UDP, TLS, and DTLS) > > experience problems. > > > > and Paul's input draft all point to that interpretation. Note > especially that Paul's draft provides the UDP wireformat as response. To > me, that strongly hints that the results of this get handed to the same bit > of code that would take the UDP wireformat from other transports (like UDP) > and do what it would have done with data retreived from any of those. That > behavior makes sense for DNS transported over HTTP, where you are talking > to an authoritative server or shared resolver over a new transport. > > I don't disagree that the charter lays out that the goal is to enable the > use case of DNS using HTTP semantics -- that's hopefully uncontroversial. > > > That order of operations does not make sense as a new resource type > available to web applications, in part because they can't tell from > examining the URI whether the resulting *resource* obeys CORS or not. > > It's not clear why that's an important property. Why is it necessary? > > If it goes into a browser or system cache, it is an important property; it may also be important depending on the UI result. If the JavaScript-internal resolution process feeds other parts of the page, it may even be a problem. > > There are serious attacks here that even DNSSEC won't catch, because a > malicious server and cooperating JavaScript app could give correct answers > that are non performant (like the search engine instance on the most > distant continent). > > Who would be consuming these answers? How is this different from > configuring your system to use a malicious DNS resolver (either in an > application or the OS)? > > Because the JavaScript you download could pick the resolver. The OS and browser are largely trusted; the JavaScript is largely not. > > And, if there really was a handoff to the local DNS subsystem for > parsing and processing, the JavaScript also wouldn't be able to tell > whether the result they get from that subsystem is the one that the just > retrieved (because a cache entry from some other system may have a > different SOA record and be returned as a result instead). To avoid that, > they would have build udp wireformat parsers into the downloadable > javascript. > > > > I think if you want the second, a way of making DNS resources available > to web applications, you need a very different approach; it may be > valuable, but I don't believe this charter covers it. If it is meant to, > it needs a major re-write. > > I agree there are significant risks when using DNS. I think the question > is what to do about it. > > One thing the WG could do would be to write some Security Considerations > about the different ways this could be sub-optimal or even dangerous. > > I don't see how giving the protocol a new URI scheme avoids these risks, > given that the defined resources would be available over HTTP still. > > It gives the browser something to look at. If it rejects udp-wireformat mime types being returned from HTTPS URIs but accepts them from dnsh URIs, it can handle the data differently. I don't know that browsers want to do that, mind you, I'm simple saying that the working group could decide that this was a reasonable facility to consider. Ruling out ways for the ecosystem to distinguish this from other web resources seems to be the wrong way to go, at least to me. regards, Ted > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > > --001a11475fa29ba22e055979f644 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham <mnot@mnot.n= et> wrote:

> So, I don't that this is established.=C2=A0 One mental model for t= his work is that DNS, having started with UDP and TCP as transports, has no= w added a set of additional secure transports.=C2=A0 Two of those were defi= ned in DPRIV; this defines another.=C2=A0 From that perspective, any time a= n application requires a DNS name to be resolved, the relevant local code w= ould try the set of secure transports until it got an answer.=C2=A0 The app= lication may not know which is used and does not specify it; it is simply g= etting the DNS answer back that allows it to proceed.

Every time people start talking in this manner and referring to HTTP= as a "transport", I get flashbacks to WS-* and what a glorious f= ailure that was.


If it helps, I= am happy to say "facilitating protocol".=C2=A0 The mental model = question for the charter is really:

Does this add a new t= ool for DNS systems attempting resolution to use when previous efforts are = blocked?=C2=A0 So any DNS resolution might use it, whether from a browser, = an app, or system call, but that those would not *specify* it be used?
<= br>
Does this add a method for Web application to directly resolv= e DNS resource records using a resolver self-identified in the Javascript?= =C2=A0 So DNS resolutions are instantiated and consumed by Javascript witho= ut any intermediation by the local DNS resolver or the browser's DNS ru= les?

Does this charter aim for the working group to do bo= th?

As currently written, I see the charter describing 1.= =C2=A0 There has been an argument that it also do 2 or that 2 becomes possi= ble when 1 is specified and is thus automatically part of the scope.=C2=A0 = If that is the case, I believe the charter needs a re-write to describe it.= =C2=A0
=C2=A0
> The name of the group (DNS over HTTP), the justification at the beginn= ing of the charter:
>
> This will enable the domain name system to function over certain paths= where existing DNS methods (UDP, TLS, and DTLS) experience problems. This = will enable the domain name system to function over certain paths where exi= sting DNS methods (UDP, TLS, and DTLS)
> experience problems.
>
> and Paul's input draft all point to that interpretation.=C2=A0 Not= e especially that Paul's draft provides the UDP wireformat as response.= =C2=A0 To me, that strongly hints that the results of this get handed to th= e same bit of code that would take the UDP wireformat from other transports= (like UDP) and do what it would have done with data retreived from any of = those.=C2=A0 That behavior makes sense for DNS transported over HTTP, where= you are talking to an authoritative server or shared resolver over a new t= ransport.

I don't disagree that the charter lays out that the goal is to e= nable the use case of DNS using HTTP semantics -- that's hopefully unco= ntroversial.

> That order of operations does not make sense as a new resource type av= ailable to web applications, in part because they can't tell from exami= ning the URI whether the resulting *resource* obeys CORS or not.

It's not clear why that's an important property. Why is it n= ecessary?


If it goes int= o a browser or system cache, it is an important property; it may also be im= portant depending on the UI result.=C2=A0 If the JavaScript-internal resolu= tion process feeds other parts of the page, it may even be a problem.
= =C2=A0
> There are serious attacks here that even DNSSEC won't catch, becau= se a malicious server and cooperating JavaScript app could give correct ans= wers that are non performant (like the search engine instance on the most d= istant continent).

Who would be consuming these answers? How is this different from con= figuring your system to use a malicious DNS resolver (either in an applicat= ion or the OS)?

Because the JavaScript you do= wnload could pick the resolver.=C2=A0 The OS and browser are largely truste= d; the JavaScript is largely not.
=C2=A0
> And, if there really was a handoff to the local DNS subsystem for pars= ing and processing, the JavaScript also wouldn't be able to tell whethe= r the result they get from that subsystem is the one that the just retrieve= d (because a cache entry from some other system may have a different SOA re= cord and be returned as a result instead).=C2=A0 To avoid that, they would = have build udp wireformat parsers into the downloadable javascript.
>
> I think if you want the second, a way of making DNS resources availabl= e to web applications, you need a very different approach; it may be valuab= le, but I don't believe this charter covers it.=C2=A0 If it is meant to= , it needs a major re-write.

I agree there are significant risks when using DNS. I think the ques= tion is what to do about it.

One thing the WG could do would be to write some Security Considerations ab= out the different ways this could be sub-optimal or even dangerous.

I don't see how giving the protocol a new URI scheme avoids these risks= , given that the defined resources would be available over HTTP still.


It gives the browser something to look= at.=C2=A0 If it rejects udp-wireformat mime types being returned from HTTP= S URIs but accepts them from dnsh URIs, it can handle the data differently.= =C2=A0 I don't know that browsers want to do that, mind you, I'm si= mple saying that the working group could decide that this was a reasonable = facility to consider.=C2=A0 Ruling out ways for the ecosystem to distinguis= h this from other web resources seems to be the wrong way to go, at least t= o me.

regards,

Ted

= =C2=A0
Cheers,

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



--001a11475fa29ba22e055979f644-- From nobody Mon Sep 18 10:30:04 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFBB4133070; Mon, 18 Sep 2017 10:29:56 -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 uZ7Mrk4hTkqN; Mon, 18 Sep 2017 10:29:56 -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 0B8FC132992; Mon, 18 Sep 2017 10:29:56 -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, 18 Sep 2017 10:29:53 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 18 Sep 2017 10:29:53 -0700 From: Paul Hoffman To: Ted Hardie CC: "doh@ietf.org" , IETF Thread-Topic: [Ext] [Doh] WG Review: DNS Over HTTPS (doh) Thread-Index: AQHTMKO8PoKiNsWal0q0l6Sn3okW1w== Date: Mon, 18 Sep 2017 17:29:52 +0000 Message-ID: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> 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: <1B8CD1DD7C2AB941A878EE446ED42960@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WG Review: DNS Over HTTPS (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: Mon, 18 Sep 2017 17:29:57 -0000 On Sep 18, 2017, at 10:20 AM, Ted Hardie wrote: > Does this add a new tool for DNS systems attempting resolution to use whe= n previous efforts are blocked? So any DNS resolution might use it, whethe= r from a browser, an app, or system call, but that those would not *specify= * it be used? >=20 > Does this add a method for Web application to directly resolve DNS resour= ce records using a resolver self-identified in the Javascript? So DNS reso= lutions are instantiated and consumed by Javascript without any intermediat= ion by the local DNS resolver or the browser's DNS rules? >=20 > Does this charter aim for the working group to do both? >=20 > As currently written, I see the charter describing 1. Then that may be a failure of the current charter text.=20 > There has been an argument that it also do 2 or that 2 becomes possible = when 1 is specified and is thus automatically part of the scope. If that i= s the case, I believe the charter needs a re-write to describe it. =20 In the many discussions leading up to the -00 wording for the charter (whic= h became much longer in IESG discussion), #2 was the clear use case. --Paul Hoffman= From nobody Mon Sep 18 11:17:36 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD968133055; Mon, 18 Sep 2017 11:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sfLwTJKkVZs; Mon, 18 Sep 2017 11:17:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6219132320; Mon, 18 Sep 2017 11:17:33 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8IIHApl090018 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 18 Sep 2017 13:17:12 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Paul Hoffman , Ted Hardie Cc: "doh@ietf.org" , IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> From: Adam Roach Message-ID: Date: Mon, 18 Sep 2017 13:17:10 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] [Ext] WG Review: DNS Over HTTPS (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: Mon, 18 Sep 2017 18:17:34 -0000 On 9/18/17 12:29 PM, Paul Hoffman wrote: > In the many discussions leading up to the -00 wording for the charter (which became much longer in IESG discussion) $ wc charter-ietf-doh-00-00.txt       19     127     831 charter-ietf-doh-00-00.txt $ wc charter-ietf-doh-00-06.txt       19     168    1124 charter-ietf-doh-00-06.txt I'm not sure a 41-word expansion really qualifies as "much longer," especially given that 53 of those words are new text requiring coordination with other WGs that have a vested interest in this topic. This conversation might be more productive if we hedge away from hyperbole. /a From nobody Mon Sep 18 11:36:02 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF961326ED; Mon, 18 Sep 2017 11:35:54 -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 Ot4KJ_nd3gnd; Mon, 18 Sep 2017 11:35:52 -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 B771C1241F3; Mon, 18 Sep 2017 11:35:52 -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, 18 Sep 2017 11:35:50 -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, 18 Sep 2017 11:35:50 -0700 From: Paul Hoffman To: Adam Roach CC: "doh@ietf.org" , IETF Thread-Topic: [Ext] [Doh] WG Review: DNS Over HTTPS (doh) Thread-Index: AQHTMKO8pv6JW9M6GEuDpCcjcsuo8aK7aMAAgAAFNQA= Date: Mon, 18 Sep 2017 18:35:50 +0000 Message-ID: <554260AA-653B-4C69-8AE1-E9482797EFFD@icann.org> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> 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: <0A7CF32937FA1047AA20AEE2EBE5EF25@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Doh] [Ext] WG Review: DNS Over HTTPS (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: Mon, 18 Sep 2017 18:35:54 -0000 On Sep 18, 2017, at 11:17 AM, Adam Roach wrote: >=20 > On 9/18/17 12:29 PM, Paul Hoffman wrote: >> In the many discussions leading up to the -00 wording for the charter (w= hich became much longer in IESG discussion) >=20 > $ wc charter-ietf-doh-00-00.txt > 19 127 831 charter-ietf-doh-00-00.txt >=20 > $ wc charter-ietf-doh-00-06.txt > 19 168 1124 charter-ietf-doh-00-06.txt >=20 > I'm not sure a 41-word expansion really qualifies as "much longer," espec= ially given that 53 of those words are new text requiring coordination with= other WGs that have a vested interest in this topic. Good point. > This conversation might be more productive if we hedge away from hyperbol= e. Indeed, and I apologize for injecting that last bit of hyperbole here. FWIW= , it is my intention to be a good document editor and follow WG consensus o= n what needs to be added as the eventual WG discussion evolves. --Paul Hoffman= From nobody Mon Sep 18 17:26:35 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63AB91332D7; Mon, 18 Sep 2017 17:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=UrxDNdI2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KMQXIRbB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKdTE9jtleWT; Mon, 18 Sep 2017 17:26:31 -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 C2BF6134285; Mon, 18 Sep 2017 17:26:31 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 26B5E20E7B; Mon, 18 Sep 2017 20:26:31 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 18 Sep 2017 20:26:31 -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:x-sasl-enc; s=fm1; bh=6XodGbEeEVWhrDmJ3B hzCHThDpbxAaUZFBZGB8Nwc7g=; b=UrxDNdI20nAyltiZKqh5z001IXTSjdJ/37 6Ge91teTEJz+Jt5spbn5okbH4tElzw9ON09wbi+373ZURWLhdvOVKv8UajKva7XC GmamTmgjoedWfFUv7UvoUzqDlaGENrsRFNKVI3orJP1M7FgwdlOB8wClU4i9Sq8D U+eSN11UQdhFxRI+wVpljE8w/cUckEISgqhmd83nO68QBCLFket5bLtZYD8lYJ/w z37VF4Gv84OhN2yzpD9niTc5X5OiDbEWp1Ka9nClyMQFkDBO9DxJlSWzVgJOyOcP x/seodMBVvTCv45NojEd0g+aS81lGnjSZJrsiDhycb8ISTbrAkpg== 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:x-sasl-enc; s= fm1; bh=6XodGbEeEVWhrDmJ3BhzCHThDpbxAaUZFBZGB8Nwc7g=; b=KMQXIRbB RJ15dn2UQrR3OCKAorjbq1iD1M0Nsm2lwYvP4CXL8hy674TkVvVlnyTTYkq7xlW/ EW015kyYPT5ux1MaR/sTiz2QNfWG8ACB/pZCVmfe3f4UNmzF1yfXy6Gzri5GHWYc Qz3pBgkIxcAHEQVa6V3wd2KdEbJMJZEIVM23ib3cAdRnKt6ElA9DznQDOkv0jBdW L8bPhb47c2eB3G6vziIitvWZUb9TlAbN+0pg1GNdgGkYBk/X6AMmE3GJZbJ4PY61 XmIPzMa2u27nmtPk8FP4wPojEDjEyBXErDQ45eBMnbTtsXhEhkhT410YLnhooH2z jGZ6tRkR4uNNIg== X-ME-Sender: X-Sasl-enc: UEfuyPh8mKQEzv0mgNaYtHuF8OvpbxJArd7puIfvPJMq 1505780790 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 0F8012473F; Mon, 18 Sep 2017 20:26:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Tue, 19 Sep 2017 10:26:25 +1000 Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 19 Sep 2017 00:26:34 -0000 Hi Ted, Sorry, threading is a bit confusing below (thanks, GMail). > On 19 Sep 2017, at 3:20 am, Ted Hardie wrote: >=20 > On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham = wrote: >=20 > > So, I don't that this is established. One mental model for this = work is that DNS, having started with UDP and TCP as transports, has now = added a set of additional secure transports. Two of those were defined = in DPRIV; this defines another. =46rom that perspective, any time an = application requires a DNS name to be resolved, the relevant local code = would try the set of secure transports until it got an answer. The = application may not know which is used and does not specify it; it is = simply getting the DNS answer back that allows it to proceed. >=20 > Every time people start talking in this manner and referring to HTTP = as a "transport", I get flashbacks to WS-* and what a glorious failure = that was. >=20 >=20 > If it helps, I am happy to say "facilitating protocol". The mental = model question for the charter is really: >=20 > Does this add a new tool for DNS systems attempting resolution to use = when previous efforts are blocked? So any DNS resolution might use it, = whether from a browser, an app, or system call, but that those would not = *specify* it be used? That sounds like an implementation choice, not a protocol decision. What = in the protocol could constrain that? > Does this add a method for Web application to directly resolve DNS = resource records Well, once it's available over HTTP, that's certainly possible. A quick = search for "DNS lookup online" shows many people doing that already, = albeit with different formats. > using a resolver self-identified in the Javascript? So DNS resolutions = are instantiated and consumed by Javascript without any intermediation = by the local DNS resolver or the browser's DNS rules? What does "a resolver self-identified in the Javascript" mean, exactly? Are you supposing some sort of rendezvous system where I can "install" a = DOH resolver from one origin and have it affect requests sent to = another? Doing so isn't possible on the current Web, so enabling it would require = some fairly heavy lifting at the W3C and/or WHATWG (which on the face of = it, they're not likely to think is sane). I can only hope that defining = such a thing is out of scope for this WG, as we truly don't have the = expertise here. > Does this charter aim for the working group to do both? >=20 > As currently written, I see the charter describing 1. There has been = an argument that it also do 2 or that 2 becomes possible when 1 is = specified and is thus automatically part of the scope. If that is the = case, I believe the charter needs a re-write to describe it. =20 See above. > =20 > > The name of the group (DNS over HTTP), the justification at the = beginning of the charter: > > > > This will enable the domain name system to function over certain = paths where existing DNS methods (UDP, TLS, and DTLS) experience = problems. This will enable the domain name system to function over = certain paths where existing DNS methods (UDP, TLS, and DTLS) > > experience problems. > > > > and Paul's input draft all point to that interpretation. Note = especially that Paul's draft provides the UDP wireformat as response. = To me, that strongly hints that the results of this get handed to the = same bit of code that would take the UDP wireformat from other = transports (like UDP) and do what it would have done with data retreived = from any of those. That behavior makes sense for DNS transported over = HTTP, where you are talking to an authoritative server or shared = resolver over a new transport. >=20 > I don't disagree that the charter lays out that the goal is to enable = the use case of DNS using HTTP semantics -- that's hopefully = uncontroversial. >=20 > > That order of operations does not make sense as a new resource type = available to web applications, in part because they can't tell from = examining the URI whether the resulting *resource* obeys CORS or not. >=20 > It's not clear why that's an important property. Why is it necessary? >=20 >=20 > If it goes into a browser or system cache, it is an important = property; it may also be important depending on the UI result. If the = JavaScript-internal resolution process feeds other parts of the page, it = may even be a problem. When you say "cache", do you mean HTTP or DNS? I'm afraid I still don't = get what you're looking for here. > > There are serious attacks here that even DNSSEC won't catch, = because a malicious server and cooperating JavaScript app could give = correct answers that are non performant (like the search engine instance = on the most distant continent). >=20 > Who would be consuming these answers? How is this different from = configuring your system to use a malicious DNS resolver (either in an = application or the OS)? >=20 > Because the JavaScript you download could pick the resolver. The OS = and browser are largely trusted; the JavaScript is largely not. OK, this seems to indicate you *do* think that somehow arbitrary JS can = take over DNS resolution for the system or browser. What led you to that = conclusion? > > And, if there really was a handoff to the local DNS subsystem for = parsing and processing, the JavaScript also wouldn't be able to tell = whether the result they get from that subsystem is the one that the just = retrieved (because a cache entry from some other system may have a = different SOA record and be returned as a result instead). To avoid = that, they would have build udp wireformat parsers into the downloadable = javascript. > > > > I think if you want the second, a way of making DNS resources = available to web applications, you need a very different approach; it = may be valuable, but I don't believe this charter covers it. If it is = meant to, it needs a major re-write. >=20 > I agree there are significant risks when using DNS. I think the = question is what to do about it. >=20 > One thing the WG could do would be to write some Security = Considerations about the different ways this could be sub-optimal or = even dangerous. >=20 > I don't see how giving the protocol a new URI scheme avoids these = risks, given that the defined resources would be available over HTTP = still. >=20 >=20 > It gives the browser something to look at. If it rejects = udp-wireformat mime types being returned from HTTPS URIs but accepts = them from dnsh URIs, it can handle the data differently. >=20 > I don't know that browsers want to do that, mind you, I'm simple = saying that the working group could decide that this was a reasonable = facility to consider. Ruling out ways for the ecosystem to distinguish = this from other web resources seems to be the wrong way to go, at least = to me. Again, I don't think this WG should be attempting to allow any sort of = automated control of browser or system DNS resolution from the Web = (e.g., JS, triggered by arbitrary URI schemes, mime types, whatever); = I've seen zero desire from any implementer to allow that, it's fraught = with security, privacy and other issues, and has dubious benefit. The use case that I believe most have in mind is "as a user, I want to = configure my [browser, OS] to use *this* DOH service for DNS resolution" = -- where that configuration is manual; e.g., a configuration textbox or = dropdown in the browser, or a file in /etc. It might be made more = user-friendly; e.g., it could be automatic when the user goes into the = ill-defined "private mode."=20 The current charter allows that. I *think* the issues you're concerned = about are in a very different area -- roughly, "automated control of DNS = resolution." I'm not sure where you got the sense that this was on the = table, but if it will help, write it out of the charter. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Sep 18 22:35:56 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC765134230; Mon, 18 Sep 2017 22:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4ujHB_Dx-SA; Mon, 18 Sep 2017 22:35:53 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B489F132EA7; Mon, 18 Sep 2017 22:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5268; q=dns/txt; s=iport; t=1505799353; x=1507008953; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=zvWNnSJE3JOASHeOPYQ3hdR86WoHgyA5p/rnnNackrU=; b=cdOLg2Kg8deVF/2y+NV2vTTGnOyTXxkfKH0+Qx1DDOKyuMsoQclPzZiO Q9yjsZKtdmSZMpfINaqQPT0HrBmtyiKWlzIlho5YLKmk0mgbA6RpKHOlo kaK+zeFqr07R3oc/riag1bwzNPol/m3qUDdB8oGT2NnRlIyQ8mtJs/L87 c=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgCwq8BZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhByLFJBMK5BmhU2CBAcDhTsChQ8VAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FI1YQCwQBCQoqAgJXBgEMCAEBii+pZYInJ4sBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDg+DK4Vggn2ERQESAYMygmAFoQuEOoIhjXuLV4cilTeBOTUigQILMiEIHBW?= =?us-ascii?q?HZz6GX4IyAQEB?= X-IronPort-AV: E=Sophos;i="5.42,416,1500940800"; d="asc'?scan'208,217";a="655749539" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 05:35:50 +0000 Received: from [10.61.83.137] (ams3-vpn-dhcp5002.cisco.com [10.61.83.137]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8J5ZnsX021897; Tue, 19 Sep 2017 05:35:50 GMT To: Mark Nottingham , Ted Hardie Cc: doh@ietf.org, Paul Hoffman , IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> From: Eliot Lear Message-ID: <29e7cf85-375d-2d62-18a6-7c8fc99e3336@cisco.com> Date: Tue, 19 Sep 2017 07:35:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VjF1SXRHUk3oN1ToqbNWaqM9vecj3J6xX" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 19 Sep 2017 05:35:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VjF1SXRHUk3oN1ToqbNWaqM9vecj3J6xX Content-Type: multipart/mixed; boundary="RI4NpgdsOTIGDrgD8CMQ3Eah4pOFke2tp"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham , Ted Hardie Cc: doh@ietf.org, Paul Hoffman , IETF Message-ID: <29e7cf85-375d-2d62-18a6-7c8fc99e3336@cisco.com> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> In-Reply-To: <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> --RI4NpgdsOTIGDrgD8CMQ3Eah4pOFke2tp Content-Type: multipart/alternative; boundary="------------AA193CD3734670F928F21231" Content-Language: en-US This is a multi-part message in MIME format. --------------AA193CD3734670F928F21231 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Mark, On 9/19/17 2:26 AM, Mark Nottingham wrote: > The use case that I believe most have in mind is "as a user, I want to = configure my [browser, OS] to use *this* DOH service for DNS resolution" = -- where that configuration is manual; e.g., a configuration textbox or d= ropdown in the browser, or a file in /etc. It might be made more user-fri= endly; e.g., it could be automatic when the user goes into the ill-define= d "private mode."=20 Your first sentence should probably be recognizable in the charter (it's not, and thus all the email).=C2=A0 That would at least allow for operati= ons that are congruent with existing methods so that split DNS and malware protection functions can take place.=C2=A0 It also at least roughly match= es the security considerations text already in the draft. As to the 2nd sentence, ain't nothing stopping that, but some text should probably make it into the draft that *someone* is going to know what queries you're making.=C2=A0 That's not a charter issue, of course. Eliot --------------AA193CD3734670F928F21231 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Mark,

On 9/19/17 2:26 AM, Mark Nottingham wrote:
The use case that I believe most have in mind is "as=
 a user, I want to configure my [browser, OS] to use *this* DOH service for DNS resolution" -- where that configuration=
 is manual; e.g., a configuration textbox or dropdown in the browser, or =
a file in /etc. It might be made more user-friendly; e.g., it could be au=
tomatic when the user goes into the ill-defined "private mode."=20

Your first sentence should probably be recognizable in the charter (it's not, and thus all the email).=C2=A0 That would at least allow f= or operations that are congruent with existing methods so that split DNS and malware protection functions can take place.=C2=A0 It also at= least roughly matches the security considerations text already in the draft.

As to the 2nd sentence, ain't nothing stopping that, but some text should probably make it into the draft that *someone* is going to know what queries you're making.=C2=A0 That's not a charter issue, of= course.

Eliot
--------------AA193CD3734670F928F21231-- --RI4NpgdsOTIGDrgD8CMQ3Eah4pOFke2tp-- --VjF1SXRHUk3oN1ToqbNWaqM9vecj3J6xX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZwKy4AAoJEIe2a0bZ0nozWK8H/0WbV+2KOQqULs3ODvtg5wi2 NlduaOk1kFPtFYRlqPxb7XnsBTYdwb9VCpSRPIDcK/HnVzMm4cqxS3HFiP7Cben0 K//LMibnfRktkDe1OijfTUlMGNaQKJqTOytyKXc6+iyZbiJXmUXqsmnaV2TyWJ/b 84P1F7gOaFrkGpbDMaAqwXzzstkRjyvRivKQaOVQgDtNCfmpX7Kgvrg7Zkgubc1S wyrReT0z/OlEyddcHc61YoZtHJyTYtpvB4YZTdwy7vAp24sR5rhhHaxY9oYly9IS 4MckrX9V54hDrgfGxaGkAY/FcatfCmtG9Q8LCV83Hehj+VPT2y/mFACPfa7n0UY= =pvjB -----END PGP SIGNATURE----- --VjF1SXRHUk3oN1ToqbNWaqM9vecj3J6xX-- From nobody Tue Sep 19 10:00:32 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034EF133065; Tue, 19 Sep 2017 10:00:23 -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 msSls5_0MVwG; Tue, 19 Sep 2017 10:00:21 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA38F13304E; Tue, 19 Sep 2017 10:00:20 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id o77so244249qke.9; Tue, 19 Sep 2017 10:00:20 -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=xAmGCggL0KaGwBqqZLifH04YnzaCC/+XZYbtIRraIFs=; b=RWHN6G9IbnXxNLKNsomdWpZAVpiDH0D09nxU/Em+aWPiRXIUbVcwKy4PJRgdtiy28t LuNq5PcrC1Qp8XufqoG0pqUB3wqyGp5/cc48trBWcLBaJcnbj/WGwzQgc1mX93qHMf4X 3txQ7g326MJkrjkpNyKoQ4+YJXU3fK+lqJzGtq3dYj3ufNpGjCMk+3vd/XevHFt9hoPV kPLHRnQy93wdMmJnwaeobdoDKE6BEfChwGAwQSJ6/T298JF/jp/z7In8p8Jcww7JzrU3 n47RJyv2/74iMby6yIJwpKIfIQnWpQ/SUP28x7guYtYn6qBeJ9toaNw0dLc4OOF1+Gi1 cUaQ== 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=xAmGCggL0KaGwBqqZLifH04YnzaCC/+XZYbtIRraIFs=; b=s6Q00WSYZX+U1R0DrMdLhzRd8ZkigNicSOO1lTnupAOs/QFaxIGcF4lo6fz4pPR1ue XHHeZ3HAuN87lZN23QLlrg3GS8cjQYxhiILbtJ1CRHgRo+UaprCdC1EsAtHu+asCtOHO KGArKlbapUjEa48TogfiM3EEPD5+3ePoSj6jv55tRpsS16i7qOUTP54BYioRbOkdsAb4 rn0Jk9hY2Ot5hX06EvRFzU1nikpZqOp6e1c42L1eIrAijVZ33zCY9t+R3xfDSHIww+Ic UHLIrCZCYCYmofVieZlwnDs96SsTdZU0oujBpkvohieCNEZNc1nFTK13QyBhi/ye3p1x suwA== X-Gm-Message-State: AHPjjUjH6alrpm1OwmPzLmC7Yr00Huu5AENV42fOrXcditTick404GCt Dt4JrN8W6N5qwAohbQlSruAezYES8SdBAWxFdYU= X-Google-Smtp-Source: AOwi7QCiLVeuX3+Fbh5519Wl8PzqCMgQL6h3LiAu9hFmDTWxrr8EUqV0WSXjhETvZRmjCyXsTH7dgquDkoDPfjuBBqE= X-Received: by 10.55.109.66 with SMTP id i63mr2731058qkc.19.1505840418219; Tue, 19 Sep 2017 10:00:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Tue, 19 Sep 2017 09:59:47 -0700 (PDT) In-Reply-To: <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> From: Ted Hardie Date: Tue, 19 Sep 2017 09:59:47 -0700 Message-ID: To: Mark Nottingham Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Type: multipart/alternative; boundary="94eb2c05c2a63785b005598dcb09" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 19 Sep 2017 17:00:24 -0000 --94eb2c05c2a63785b005598dcb09 Content-Type: text/plain; charset="UTF-8" Howdy, I'll try to snip pieces not salient without hindering attribution; hope that helps. On Mon, Sep 18, 2017 at 5:26 PM, Mark Nottingham wrote: > Hi Ted, > > Sorry, threading is a bit confusing below (thanks, GMail). > > > On 19 Sep 2017, at 3:20 am, Ted Hardie wrote: > > > > On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham wrote: > > > > If it helps, I am happy to say "facilitating protocol". The mental > model question for the charter is really: > > > > Does this add a new tool for DNS systems attempting resolution to use > when previous efforts are blocked? So any DNS resolution might use it, > whether from a browser, an app, or system call, but that those would not > *specify* it be used? > > That sounds like an implementation choice, not a protocol decision. What > in the protocol could constrain that? > > I'm talking about the goals here. If the intent is to have this facilitating protocol hot-swappable for any other method of interacting between a DNS client and DNS server, we have a set of tasks in front of the working group and a good idea of where the trade-offs should lean. > > > Does this add a method for Web application to directly resolve DNS > resource records > > Well, once it's available over HTTP, that's certainly possible. A quick > search for "DNS lookup online" shows many people doing that already, albeit > with different formats. > > > > using a resolver self-identified in the Javascript? So DNS resolutions > are instantiated and consumed by Javascript without any intermediation by > the local DNS resolver or the browser's DNS rules? > > What does "a resolver self-identified in the Javascript" mean, exactly? > > Are you supposing some sort of rendezvous system where I can "install" a > DOH resolver from one origin and have it affect requests sent to another? > > Can I have JavaScript retrieve a resource like https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example then use the result in place of the browser's DNS routines or the system DNS routines for retrieving https://www.major-search-engine.example/ within that JavaScrit application? If that is possible, then I need to know where the DNS data retrieved can be reused and I need to know whether the rendering distinguishes in any way between data so retrieved and data retrieved by a more trusted element. Does the data end up in the browser's DNS cache? Does a hover over an element show that this URI would be using a JavaScript supplied resolver to retrieve the location should I click? > Doing so isn't possible on the current Web, so enabling it would require > some fairly heavy lifting at the W3C and/or WHATWG (which on the face of > it, they're not likely to think is sane). I can only hope that defining > such a thing is out of scope for this WG, as we truly don't have the > expertise here. > > Interestingly, that's not what I understood others' answer to be. Their view was that since https://dns.initial-origin.example/query-for-dns?www.major-search-engine.example was within the initial-origin, resources from it would be treated as same origin. If I understood correctly the code that would limit those resources to same origin isn't present and would have to run after the UDP wireformat was parsed (otherwise there are trivial attacks in returning additional data that cache poisons whatever the scope of use turns out to be). > > > Does this charter aim for the working group to do both? > > > > As currently written, I see the charter describing 1. There has been an > argument that it also do 2 or that 2 becomes possible when 1 is specified > and is thus automatically part of the scope. If that is the case, I > believe the charter needs a re-write to describe it. > > See above. > > > > > > The name of the group (DNS over HTTP), the justification at the > beginning of the charter: > > > > > > This will enable the domain name system to function over certain paths > where existing DNS methods (UDP, TLS, and DTLS) experience problems. This > will enable the domain name system to function over certain paths where > existing DNS methods (UDP, TLS, and DTLS) > > > experience problems. > > > > > > and Paul's input draft all point to that interpretation. Note > especially that Paul's draft provides the UDP wireformat as response. To > me, that strongly hints that the results of this get handed to the same bit > of code that would take the UDP wireformat from other transports (like UDP) > and do what it would have done with data retreived from any of those. That > behavior makes sense for DNS transported over HTTP, where you are talking > to an authoritative server or shared resolver over a new transport. > > > > I don't disagree that the charter lays out that the goal is to enable > the use case of DNS using HTTP semantics -- that's hopefully > uncontroversial. > > > > > That order of operations does not make sense as a new resource type > available to web applications, in part because they can't tell from > examining the URI whether the resulting *resource* obeys CORS or not. > > > > It's not clear why that's an important property. Why is it necessary? > > > > > > If it goes into a browser or system cache, it is an important property; > it may also be important depending on the UI result. If the > JavaScript-internal resolution process feeds other parts of the page, it > may even be a problem. > > When you say "cache", do you mean HTTP or DNS? I'm afraid I still don't > get what you're looking for here. > > I mean DNS cache. My apologies for the earlier inexactness. > > > There are serious attacks here that even DNSSEC won't catch, because > a malicious server and cooperating JavaScript app could give correct > answers that are non performant (like the search engine instance on the > most distant continent). > > > > Who would be consuming these answers? How is this different from > configuring your system to use a malicious DNS resolver (either in an > application or the OS)? > > > > Because the JavaScript you download could pick the resolver. The OS and > browser are largely trusted; the JavaScript is largely not. > > OK, this seems to indicate you *do* think that somehow arbitrary JS can > take over DNS resolution for the system or browser. What led you to that > conclusion? > > The goal to use this as a swappable facilitating protocol for DNS resolution led me to that conclusion; in that usage, the resulting DNS data would populate the relevant DNS cache. Re-using the same system within JavaScript naively would have very bad properties; some segregation to handle the different levels of trust is required. > > > > > > I don't know that browsers want to do that, mind you, I'm simple saying > that the working group could decide that this was a reasonable facility to > consider. Ruling out ways for the ecosystem to distinguish this from other > web resources seems to be the wrong way to go, at least to me. > > Again, I don't think this WG should be attempting to allow any sort of > automated control of browser or system DNS resolution from the Web (e.g., > JS, triggered by arbitrary URI schemes, mime types, whatever); I've seen > zero desire from any implementer to allow that, it's fraught with security, > privacy and other issues, and has dubious benefit. > > Should I take it that you disagree with the assertion that if we build for goal 1 (a swappable facilitating protocol) that we have automatically built a mechanism that is callable within a JavaScript application (which, as I understand it, Adam and others believe)? > The use case that I believe most have in mind is "as a user, I want to > configure my [browser, OS] to use *this* DOH service for DNS resolution" -- > where that configuration is manual; e.g., a configuration textbox or > dropdown in the browser, or a file in /etc. It might be made more > user-friendly; e.g., it could be automatic when the user goes into the > ill-defined "private mode." > > Would you consider a system in which the local browser or OS tested for the availability of a DOH server at a supplied address within scope (that would be one way to re-use the current DHCP-supplied servers, for example)? The current charter allows that. I *think* the issues you're concerned > about are in a very different area -- roughly, "automated control of DNS > resolution." I'm not sure where you got the sense that this was on the > table, but if it will help, write it out of the charter. > > My concern isn't just that it be out of scope of the charter, its that it either be not in the capability set of the resulting work or well-handled in that context. Folks asserting that it could not be eliminated from the capability set for JavaScript applications caused me to focus on the latter. If the work can be constrained such that this does not arise, so much the better. regards, Ted > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > --94eb2c05c2a63785b005598dcb09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

I'll try to snip pieces not s= alient without hindering attribution; hope that helps.

On Mon, Sep 18, 2017 at = 5:26 PM, Mark Nottingham <mnot@mnot.net> wrote:
Hi Ted,

Sorry, threading is a bit confusing below (thanks, GMail).

> On 19 Sep 2017, at 3:20 am, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> On Sat, Sep 16, 2017 at 8:00 PM, Mark Nottingham <mnot@mnot.net> wrote:
>
> If it helps, I am happy to say "facilitating protocol".=C2= =A0 The mental model question for the charter is really:
>
> Does this add a new tool for DNS systems attempting resolution to use = when previous efforts are blocked?=C2=A0 So any DNS resolution might use it= , whether from a browser, an app, or system call, but that those would not = *specify* it be used?

That sounds like an implementation choice, not a protocol decision. = What in the protocol could constrain that?


I'm = talking about the goals here.=C2=A0 If the intent is to have this facilitat= ing protocol hot-swappable for any other method of interacting between a DN= S client and DNS server, we have a set of tasks in front of the working gro= up and a good idea of where the trade-offs should lean.=C2=A0
=C2=A0

> Does this add a method for Web application to directly resolve DNS res= ource records

Well, once it's available over HTTP, that's certainly possib= le. A quick search for "DNS lookup online" shows many people doin= g that already, albeit with different formats.


> using a resolver self-identified in the Javascript? So DNS resolutions= are instantiated and consumed by Javascript without any intermediation by = the local DNS resolver or the browser's DNS rules?

What does "a resolver self-identified in the Javascript" m= ean, exactly?

Are you supposing some sort of rendezvous system where I can "install&= quot; a DOH resolver from one origin and have it affect requests sent to an= other?


Can I have JavaScript retrieve a resou= rce like https://dns.initial-origin.example/query-for-dns= ?www.major-search-engine.example then use the result in place of the br= owser's DNS routines or the system DNS routines for retrieving https://www.major-search-engi= ne.example/ within that JavaScrit application?=C2=A0 If that is possibl= e, then I need to know where the DNS data retrieved can be reused and I nee= d to know whether the rendering distinguishes in any way between data so re= trieved and data retrieved by a more trusted element.=C2=A0=C2=A0 Does the = data end up in the browser's DNS cache?=C2=A0 Does a hover over an elem= ent show that this URI would be using a JavaScript supplied resolver to ret= rieve the location should I click?
=C2=A0
Doing so isn't possible on the current Web, so enabling it would requir= e some fairly heavy lifting at the W3C and/or WHATWG (which on the face of = it, they're not likely to think is sane). I can only hope that defining= such a thing is out of scope for this WG, as we truly don't have the e= xpertise here.


Interest= ingly, that's not what I understood others' answer to be.=C2=A0 The= ir view was that since=C2=A0 https://dns.initial-origin.e= xample/query-for-dns?www.major-search-engine.example=C2=A0 was within t= he initial-origin, resources from it would be treated as same origin.=C2=A0= If I understood correctly the code that would limit those resources to sam= e origin isn't present and would have to run after the UDP wireformat w= as parsed (otherwise there are trivial attacks in returning additional data= that cache poisons whatever the scope of use turns out to be).
=C2=A0

> Does this charter aim for the working group to do both?
>
> As currently written, I see the charter describing 1.=C2=A0 There has = been an argument that it also do 2 or that 2 becomes possible when 1 is spe= cified and is thus automatically part of the scope.=C2=A0 If that is the ca= se, I believe the charter needs a re-write to describe it.

See above.

>
> > The name of the group (DNS over HTTP), the justification at the b= eginning of the charter:
> >
> > This will enable the domain name system to function over certain = paths where existing DNS methods (UDP, TLS, and DTLS) experience problems. = This will enable the domain name system to function over certain paths wher= e existing DNS methods (UDP, TLS, and DTLS)
> > experience problems.
> >
> > and Paul's input draft all point to that interpretation.=C2= =A0 Note especially that Paul's draft provides the UDP wireformat as re= sponse.=C2=A0 To me, that strongly hints that the results of this get hande= d to the same bit of code that would take the UDP wireformat from other tra= nsports (like UDP) and do what it would have done with data retreived from = any of those.=C2=A0 That behavior makes sense for DNS transported over HTTP= , where you are talking to an authoritative server or shared resolver over = a new transport.
>
> I don't disagree that the charter lays out that the goal is to ena= ble the use case of DNS using HTTP semantics -- that's hopefully uncont= roversial.
>
> > That order of operations does not make sense as a new resource ty= pe available to web applications, in part because they can't tell from = examining the URI whether the resulting *resource* obeys CORS or not.
>
> It's not clear why that's an important property. Why is it nec= essary?
>
>
> If it goes into a browser or system cache, it is an important property= ; it may also be important depending on the UI result.=C2=A0 If the JavaScr= ipt-internal resolution process feeds other parts of the page, it may even = be a problem.

When you say "cache", do you mean HTTP or DNS? I'm afr= aid I still don't get what you're looking for here.


I mean D= NS cache.=C2=A0 My apologies for the earlier inexactness.

>=C2=A0 > There are serious attacks here that even DNSSEC won't c= atch, because a malicious server and cooperating JavaScript app could give = correct answers that are non performant (like the search engine instance on= the most distant continent).
>
> Who would be consuming these answers? How is this different from confi= guring your system to use a malicious DNS resolver (either in an applicatio= n or the OS)?
>
> Because the JavaScript you download could pick the resolver.=C2=A0 The= OS and browser are largely trusted; the JavaScript is largely not.

OK, this seems to indicate you *do* think that somehow arbitrary JS = can take over DNS resolution for the system or browser. What led you to tha= t conclusion?


The goal= to use this as a swappable facilitating protocol for DNS resolution led me= to that conclusion; in that usage, the resulting DNS data would populate t= he relevant DNS cache.=C2=A0 Re-using the same system within JavaScript nai= vely would have very bad properties; some segregation to handle the differe= nt levels of trust is required.
=C2=A0


>
>=C2=A0 I don't know that browsers want to do that, mind you, I'= m simple saying that the working group could decide that this was a reasona= ble facility to consider.=C2=A0 Ruling out ways for the ecosystem to distin= guish this from other web resources seems to be the wrong way to go, at lea= st to me.

Again, I don't think this WG should be attempting to allow any s= ort of automated control of browser or system DNS resolution from the Web (= e.g., JS, triggered by arbitrary URI schemes, mime types, whatever); I'= ve seen zero desire from any implementer to allow that, it's fraught wi= th security, privacy and other issues, and has dubious benefit.

Should I take it that you disagree with the assertion= that if we build for goal 1 (a swappable facilitating protocol) that we ha= ve automatically built a mechanism that is callable within a JavaScript app= lication (which, as I understand it, Adam and others believe)?

=C2=A0
The use case that I believe most have in mind is "as a user, I want to= configure my [browser, OS] to use *this* DOH service for DNS resolution&qu= ot; -- where that configuration is manual; e.g., a configuration textbox or= dropdown in the browser, or a file in /etc. It might be made more user-fri= endly; e.g., it could be automatic when the user goes into the ill-defined = "private mode."


Would you consider a system in which t= he local browser or OS tested for the availability of a DOH server at a sup= plied address within scope (that would be one way to re-use the current DHC= P-supplied servers, for example)?

The current charter allows that. I *think* the issues you're concerned = about are in a very different area -- roughly, "automated control of D= NS resolution." I'm not sure where you got the sense that this was= on the table, but if it will help, write it out of the charter.

My concern isn't just that it be out of scope of the charter= , its that it either be not in the capability set of the resulting work or = well-handled in that context.=C2=A0 Folks asserting that it could not be el= iminated from the capability set for JavaScript applications caused me to f= ocus on the latter.=C2=A0 If the work can be constrained such that this doe= s not arise, so much the better.

regards,

Ted
=C2=A0
Cheers,

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


--94eb2c05c2a63785b005598dcb09-- From nobody Tue Sep 19 10:29:01 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87471342BD; Tue, 19 Sep 2017 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSmY0rKVfBmC; Tue, 19 Sep 2017 10:28:53 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D53A1342B7; Tue, 19 Sep 2017 10:28:53 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8JHSoPS029169 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Sep 2017 12:28:51 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ted Hardie , Mark Nottingham Cc: doh@ietf.org, Paul Hoffman , IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> From: Adam Roach Message-ID: Date: Tue, 19 Sep 2017 12:28:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 19 Sep 2017 17:28:55 -0000 On 9/19/17 11:59 AM, Ted Hardie wrote: > Folks asserting that it could not be eliminated from the capability > set for JavaScript applications caused me to focus on the latter. To be fair, it's kind of hard to draw a line around what can't be done from JavaScript. https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg What's under discussion here is level of convenience. /a From nobody Wed Sep 20 00:16:07 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DBF1331F6; Wed, 20 Sep 2017 00:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=dI8L3j2r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OyKPgOCl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIwCZqMVzQv5; Wed, 20 Sep 2017 00:16:01 -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 A7CA61286C7; Wed, 20 Sep 2017 00:16:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3609E20E58; Wed, 20 Sep 2017 03:16:00 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 20 Sep 2017 03:16:00 -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:x-sasl-enc; s=fm1; bh=wpa5FzYZkHtDdvSpK5 V4ROya7mfve7AGEIc1mEVquHA=; b=dI8L3j2rp0E8TfeV0ZmdKhxmv33omHchAz IXsAysfYcsLAl2nT1/fytPvo7faP6TOHT10IxLcuqhI8h1bQdxCvc5lMM2YcI+2f /IDh68yGoCJOfUY7RQlJxueFfc/4nua3N9aJSeG89+2kxjqZIImsCtbHGGlW4J5u QkqdfJYp5oE9G0oGclJTIXcDuHAhRftXiQp1Ba7jqkTrUU5iQC38shnD3QFC/8UK m9YnnGgcJMubQ9GUliQfKRl3e58dF046wERe/KVrUE3cBZorBaKwwWYDkDnN74nZ BI87NLUHlRRnr5jaRvaDSQOkLuhyaoklyxaOWbvsfucrpUkU5esg== 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:x-sasl-enc; s= fm1; bh=wpa5FzYZkHtDdvSpK5V4ROya7mfve7AGEIc1mEVquHA=; b=OyKPgOCl TSbFea73QQBzYRXUcRlM+JGhsEt9Mf1NhKNI5qvj9MUG/BvhTMRBLPyH8LkYU+pa O0yjQqydokcXEGi6iwxQDmwqb2Z04Z5Lpc4l3SYFh44p+OBqe4+Ma2r8ifVOerNU LlGYoyOvZv5glpwhrSPHDroK3VkVafhQf3Tfg+6tL2Phj+EphmUFaoO01q15AD0h VMplhdAPW1po2ruLKZ2Kac1ZXVPb+AFZS48Ps3JwGiLrhkLWEjGAMNdfHIRFHmoQ BZ83YgrMfBQj1zthKgG1j4cxL/VbOHSqa6ErbRa9QUXhXJlueuEkvoBULUvhRr4I UyT4CMoRmPi+Bw== X-ME-Sender: X-Sasl-enc: XmyKCuOWDZS3jB2RJCo15QAUrwvREu7yuFmXNO9dNRwd 1505891758 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id A38A17FA6B; Wed, 20 Sep 2017 03:15:57 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Wed, 20 Sep 2017 17:15:53 +1000 Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <296AD098-5728-44E6-855F-91881359162C@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 07:16:05 -0000 On 20 Sep 2017, at 2:59 am, Ted Hardie wrote: >=20 > Howdy, >=20 > I'll try to snip pieces not salient without hindering attribution; = hope that helps. Thanks, doing likewise below. I've tried to manually reconstruct the = quoting; apologies if there are errors. >> > using a resolver self-identified in the Javascript? So DNS = resolutions are instantiated and consumed by Javascript without any = intermediation by the local DNS resolver or the browser's DNS rules? >>=20 >> What does "a resolver self-identified in the Javascript" mean, = exactly? >>=20 >> Are you supposing some sort of rendezvous system where I can = "install" a DOH resolver from one origin and have it affect requests = sent to another? >=20 > Can I have JavaScript retrieve a resource like = https://dns.initial-origin.example/query-for-dns?www.major-search-engine.e= xample then use the result in place of the browser's DNS routines or the = system DNS routines for retrieving = https://www.major-search-engine.example/ within that JavaScrit = application? No. The most you could do -- assuming when you say "JavaScript application" = you mean Web page (because JS can be run elsewhere, e.g., NodeJS; what's = important is the constraints that the environment put upon it) -- is = reuse that result within that page (and thanks to Service Worker, the = origin as well, unless other pages opt out of SW), yes you can, today.=20= Mind you, there's nothing special about the proposal on the table that = makes it easier.=20 Also, doing so is pretty tortured for very limited gain; off the top of = my head (handwave warning) you'd need to install a SW (or without it, = create a bunch of event handlers in the page itself) to intercept = requests, do your faux DNS, and then handle the response. This would = work for embedded assets (e.g., JS, CSS, images) reasonably well on = modern browsers, I think, but once you follow a link to another origin = (or page, if SW isn't used and you don't control that page), the "real" = DNS used would show up in the location bar, and you'd lose the ability = to interfere. This has been done before, e.g., people doing "live" load balancing / = etc. from JS. > If that is possible, then I need to know where the DNS data retrieved = can be reused and I need to know whether the rendering distinguishes in = any way between data so retrieved and data retrieved by a more trusted = element. Outside the context in which it was loaded? Nowhere. > Does the data end up in the browser's DNS cache?=20 =46rom random JS (SW or otherwise) on the Internet? It doesn't. The only = way that JS can affect the DNS cache is to request lookups, which uses = the configured resolution mechanism, not what the JS asks it to use. = I.e., there is no proposal on the table to have a new JS interface = 'setDnsResolver()', AFAICT. If the user configures the browser to use the DOH service, it might = indeed cache the results (in the DNS or HTTP caches; probably the = former, because perf on the latter is a problem in most browser = implementations).=20 Security considerations might be needed for the case when a user = transitions from DOH to anther resolution mechanism -- but really that's = not much different than changing your system DNS resolver. > Does a hover over an element show that this URI would be using a = JavaScript supplied resolver to retrieve the location should I click? That's not actually specified behaviour anywhere, last I looked.=20 >> Doing so isn't possible on the current Web, so enabling it would = require some fairly heavy lifting at the W3C and/or WHATWG (which on the = face of it, they're not likely to think is sane). I can only hope that = defining such a thing is out of scope for this WG, as we truly don't = have the expertise here. >=20 > Interestingly, that's not what I understood others' answer to be. = Their view was that since = https://dns.initial-origin.example/query-for-dns?www.major-search-engine.e= xample was within the initial-origin, resources from it would be = treated as same origin. If I understood correctly the code that would = limit those resources to same origin isn't present and would have to run = after the UDP wireformat was parsed (otherwise there are trivial attacks = in returning additional data that cache poisons whatever the scope of = use turns out to be). Same origin for the purposes of what? The use case here is really, = really ill-defined. >> > > There are serious attacks here that even DNSSEC won't catch, = because a malicious server and cooperating JavaScript app could give = correct answers that are non performant (like the search engine instance = on the most distant continent). >> > >> > Who would be consuming these answers? How is this different from = configuring your system to use a malicious DNS resolver (either in an = application or the OS)? >> > >> > Because the JavaScript you download could pick the resolver. The = OS and browser are largely trusted; the JavaScript is largely not. >>=20 >> OK, this seems to indicate you *do* think that somehow arbitrary JS = can take over DNS resolution for the system or browser. What led you to = that conclusion? >=20 > The goal to use this as a swappable facilitating protocol for DNS = resolution led me to that conclusion; in that usage, the resulting DNS = data would populate the relevant DNS cache. Re-using the same system = within JavaScript naively would have very bad properties; some = segregation to handle the different levels of trust is required. OK. If I read you correctly, you seem to be assuming that browsers (and = other systems?) will somehow automatically handle responses that use a = particular media type (or a specific URI scheme, or whatever) with = elevated privileges (e.g., inserting them into the browser/OS DNS = cache). I don't think this is part of the proposal. If someone has = proposed that, please to point to the message so we can engage that = idea. >>> > I don't know that browsers want to do that, mind you, I'm simple = saying that the working group could decide that this was a reasonable = facility to consider. Ruling out ways for the ecosystem to distinguish = this from other web resources seems to be the wrong way to go, at least = to me. >>=20 >> Again, I don't think this WG should be attempting to allow any sort = of automated control of browser or system DNS resolution from the Web = (e.g., JS, triggered by arbitrary URI schemes, mime types, whatever); = I've seen zero desire from any implementer to allow that, it's fraught = with security, privacy and other issues, and has dubious benefit. >=20 > Should I take it that you disagree with the assertion that if we build = for goal 1 (a swappable facilitating protocol) that we have = automatically built a mechanism that is callable within a JavaScript = application (which, as I understand it, Adam and others believe)? I think Adam and others believe that you *could* use this protocol from = JavaScript (in a Web browser or otherwise) in a limited fashion (as = outlined above), in that you would be bound by the security model of the = environment you're working within. I don't think that is a major use = case for this work, but it is a possible one. I don't think that anyone wants to establish new Web APIs to allow = JavaScript to manipulate the browser/OS DNS resolution process or state. = I certainly do not. Adam et al - If these statements aren't accurate, please say so. More to the point, the IETF is *not* the appropriate venue to be making = core changes to the browser security model; at the very least, if we = were doing that, we'd need to be coordinating *very* closely with the = Web Application Security WG in the W3C.=20 >> The use case that I believe most have in mind is "as a user, I want = to configure my [browser, OS] to use *this* DOH service for DNS = resolution" -- where that configuration is manual; e.g., a configuration = textbox or dropdown in the browser, or a file in /etc. It might be made = more user-friendly; e.g., it could be automatic when the user goes into = the ill-defined "private mode." >=20 > Would you consider a system in which the local browser or OS tested = for the availability of a DOH server at a supplied address within scope = (that would be one way to re-use the current DHCP-supplied servers, for = example)? Possibly. "Manual" is probably the wrong word above -- the important = part is that it's not under the control of a Web API for browsers. I = doubt we'll consider it in-scope to specify other mechanisms (e.g., we = don't control POSIX), but a protocol augmentation along those lines = *might* be in-scope (although I'd prefer to leave it out; the more we = put into this WG, the more chances of getting distracted by shiny = things).=20 >> The current charter allows that. I *think* the issues you're = concerned about are in a very different area -- roughly, "automated = control of DNS resolution." I'm not sure where you got the sense that = this was on the table, but if it will help, write it out of the charter. >=20 > My concern isn't just that it be out of scope of the charter, its that = it either be not in the capability set of the resulting work or = well-handled in that context.=20 As above, defining this protocol won't change the capability of Web = scripting by even the smallest amount. People do what they can today, = and those capabilities will be the same after this is defined. > Folks asserting that it could not be eliminated from the capability = set for JavaScript applications caused me to focus on the latter. If = the work can be constrained such that this does not arise, so much the = better. It's not a matter of constraining the work; the work isn't proposing to = operate even remotely in the way that you describe. I think we're just = having a misunderstanding, because people have multiple use cases in = mind for this protocol, and properties thereof have been mixed up. AIUI those use cases are, roughly: 1. Configure your browser/OS to use a DOH service for DNS resolution (as = above) -- this will affect browser/OS state, because it's being used for = DNS; however, it's not being done from JS. 2. Call a DOH service from Javascript (for some reason) -- note this is = just like any other HTTP request; it doesn't affect browser/OS state = outside of the same origin model. Yes, you can still build a = browser-in-a-browser and mess with things inside that context, but = that's already true today. 3. Future handwavy things like making DNS updates over HTTP -- very = ill-defined and not important for this discussion -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 20 10:18:17 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A9413303F; Wed, 20 Sep 2017 10:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 nyAMx4NGrPoF; Wed, 20 Sep 2017 10:18:10 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 B9C04133020; Wed, 20 Sep 2017 10:18:09 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id f15so3490912qtf.7; Wed, 20 Sep 2017 10:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iXr/Jsa/YABvqqXMuqlXkonDDwKdX1cWgp8rfxYYq2U=; b=I+eTB+auERzJJII/+oodozMp0QuFSzqaEX2pMlqnoW7MvGFwGuLZvDtSmnKyXxPWK5 Mi9/wq4s2HUSUd4gR/X/jRIS2IBH+vviahFcdmWAVht6gA1Td9i/Cegbvhb/ZNz/WCWW Nz1XFomZoZ56G2sM5rsYyQTjuXIskkpCTtFjVuoXNNIkgXe9O9eYROcr+4c220m6QNBl TtF0RqqHdWtv0uQ66U5Ic2xj8UOgg181uMcRdZfzb4veHwI19UrIc4734LKhRRC4RciI pHDzSxDspa0iCfS+3sAvmHi7Hv14I7H135HuXrtZUA3wle7TXLlsxpGYJNQ9RfRG2cZV VYXg== 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=iXr/Jsa/YABvqqXMuqlXkonDDwKdX1cWgp8rfxYYq2U=; b=kHpCHw8wATDIcX7UEoDplr6F4P46qiO8WPrGBNw/N9xQWBq/IiAgL7MUb4J/OF0zPn r2lR4rwiIcuKZxOo/1MiNpc3lgdx6c7fGFtSNwVpPMkatik64QEAJd/R9Ej/Jjqm5Dl/ 6mFbrF76O+zX7J5FsDF/SZ22s5TLkkRf9PRJJdu6ewRfv75Fd08vd+rEwxh8JK9mWlNq OXEP9W2xf/8QRjAsIA/uen+TFIv0SRAaPg3Dv5GQaYVHCp+D+W+fqIgdXPVQn1NvEn25 PRBG9r7vorOy6iOSx0EOPTeC3xtfsbLOseTKVZskLRPC1Oi65au1gvuKGKsB6bPq4ljM zj3w== X-Gm-Message-State: AHPjjUjL8kPkJzrdEK4y1+eXTvbp0Wop7Jjx73+9rcqu7WVGoH3jRhgK WspoaqYgiOAyx/2GijA5OQuY92synQuMhIC5Rno= X-Google-Smtp-Source: AOwi7QC5OEq5TdJJqlkckhqeWDrleJ9iqlxsCLO8X8qKZzNsikxXAgSyX9BRlGv1gOD9qLEz8q8A9jp/o7o9Ckfp/Q8= X-Received: by 10.237.59.26 with SMTP id p26mr8815729qte.304.1505927888430; Wed, 20 Sep 2017 10:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Wed, 20 Sep 2017 10:17:37 -0700 (PDT) In-Reply-To: <296AD098-5728-44E6-855F-91881359162C@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> <296AD098-5728-44E6-855F-91881359162C@mnot.net> From: Ted Hardie Date: Wed, 20 Sep 2017 10:17:37 -0700 Message-ID: To: Mark Nottingham Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Type: multipart/alternative; boundary="94eb2c190786d8eb2a0559a228db" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 17:18:15 -0000 --94eb2c190786d8eb2a0559a228db Content-Type: text/plain; charset="UTF-8" Howdy, Comments in-line, with some snippage to help keep it readable. On Wed, Sep 20, 2017 at 12:15 AM, Mark Nottingham wrote: > > >> What does "a resolver self-identified in the Javascript" mean, exactly? > >> > >> Are you supposing some sort of rendezvous system where I can "install" > a DOH resolver from one origin and have it affect requests sent to another? > > > > Can I have JavaScript retrieve a resource like > https://dns.initial-origin.example/query-for-dns?www. > major-search-engine.example then use the result in place of the browser's > DNS routines or the system DNS routines for retrieving > https://www.major-search-engine.example/ within that JavaScrit > application? > > No. > > The most you could do -- assuming when you say "JavaScript application" > you mean Web page Yes, I mean JavaScript application downloaded into a browser. > (because JS can be run elsewhere, e.g., NodeJS; what's important is the > constraints that the environment put upon it) -- is reuse that result > within that page (and thanks to Service Worker, the origin as well, unless > other pages opt out of SW), yes you can, today. > > Mind you, there's nothing special about the proposal on the table that > makes it easier. > > I have to disagree with this. Standardizing this method should make this easier by having a common format produced by servers and consumed by clients. > Also, doing so is pretty tortured for very limited gain; off the top of my > head (handwave warning) you'd need to install a SW (or without it, create a > bunch of event handlers in the page itself) to intercept requests, do your > faux DNS, and then handle the response. This would work for embedded assets > (e.g., JS, CSS, images) reasonably well on modern browsers, So the scope of the problem is: a malicious piece of JavaScript can embed a DNS service into a web page such that some resources can be retrieved using its resolution rather than the browser or system library. It's not clear how the user would determine that this was the case, so there is a risk of mis-attribution within the web page. That there is no intent to allow that information to be further propagated is certainly useful to know, but if I understand you (and Adam) correctly, this problem must be handled somewhere because of the intersection of this proposal and JavaScript capabilities in a modern browser. As a charter question, is the description of the problem and/or proposals around it in scope for this proposed working group, or do we need to pass th problem to someone else. If someone else, who? > > > > > > The goal to use this as a swappable facilitating protocol for DNS > resolution led me to that conclusion; in that usage, the resulting DNS data > would populate the relevant DNS cache. Re-using the same system within > JavaScript naively would have very bad properties; some segregation to > handle the different levels of trust is required. > > OK. If I read you correctly, you seem to be assuming that browsers (and > other systems?) will somehow automatically handle responses that use a > particular media type (or a specific URI scheme, or whatever) with elevated > privileges (e.g., inserting them into the browser/OS DNS cache). I don't > think this is part of the proposal. If someone has proposed that, please to > point to the message so we can engage that idea. > > I think you and I agree that if an OS or browser configuration frob specifies a recursive resolver that uses DOH, that the results go where ever they would have gone had the same information come in via UDP, TCP, TLS, or DTLS. From the information in this email, we agree that taking DNS responses from a DOH recursive resolver specified in a download JavaScript application would currently be limited to that application and those from the same origin (and that building anything to take it further would be unwise). There's some work to do on how to handle misattribution within that context, but it is not the same scope as the OS/browser configured data. > I think Adam and others believe that you *could* use this protocol from > JavaScript (in a Web browser or otherwise) in a limited fashion (as > outlined above), in that you would be bound by the security model of the > environment you're working within. I don't think that is a major use case > for this work, but it is a possible one. > > I don't think that anyone wants to establish new Web APIs to allow > JavaScript to manipulate the browser/OS DNS resolution process or state. I > certainly do not. > > Adam et al - If these statements aren't accurate, please say so. > > More to the point, the IETF is *not* the appropriate venue to be making > core changes to the browser security model; at the very least, if we were > doing that, we'd need to be coordinating *very* closely with the Web > Application Security WG in the W3C. > > Should we be passing the charter by the Web Application Security WG in the W3C now for comments? > As above, defining this protocol won't change the capability of Web > scripting by even the smallest amount. People do what they can today, and > those capabilities will be the same after this is defined. > > It will change the relationship of that Web scripting capability with the DNS (or at least make that relationship much easier). Given where the DNS is in our stack, that's an important change. If an attacker can take information from an origin and have it treated as DNS data, it become the foundation of retrievals from other origins. To hideously over-simplify, the same origin security model presumes that resources from an origin share a scope. But if the origin is a recursive resolver among other capabilities, the resources retrieved may provide data about where to get other resources from outside that scope. As long as there no APIs which push that data past the same origin boundary, the problem with that is limited to misattribution within the same origin. But it is still a problem because of the role DNS info plays. > > Folks asserting that it could not be eliminated from the capability set > for JavaScript applications caused me to focus on the latter. If the work > can be constrained such that this does not arise, so much the better. > > It's not a matter of constraining the work; the work isn't proposing to > operate even remotely in the way that you describe. I think we're just > having a misunderstanding, because people have multiple use cases in mind > for this protocol, and properties thereof have been mixed up. > > AIUI those use cases are, roughly: > > 1. Configure your browser/OS to use a DOH service for DNS resolution (as > above) -- this will affect browser/OS state, because it's being used for > DNS; however, it's not being done from JS. > > Agreed, and I think this a very valuable piece of work to get done, especially for the multiplexing properties of H2 or QUIC. > 2. Call a DOH service from Javascript (for some reason) -- note this is > just like any other HTTP request; it doesn't affect browser/OS state > outside of the same origin model. Yes, you can still build a > browser-in-a-browser and mess with things inside that context, but that's > already true today. > > While this is no doubt unintended, this tends to give a "everything is already ruined" flavor to your response. If we're standardizing this, I think we need to take how this data is integrated and presented as part of the overall deployment problem. If we're not the right folks to do that part of the work, I think we need to get the right folks involved as soon as possible and to put coordination with that community into the charter along with DNSOP and the others already listed. 3. Future handwavy things like making DNS updates over HTTP -- very > ill-defined and not important for this discussion > > Yeah, I can't even tell from this whether you mean clients updating their info a la DNS dynamic update a la RFC 3007 or you mean push style updates of fresh responses from a recursive resolver. You can certainly leave the first out. Whether you can leave the second out or not depends on an interaction between the HTTP caching model and the DNS caching model (That is, if a configured DOH server pushes a new response to a query that hasn't been asked yet, it would go into the HTTP cache in anticipation of the question being asked. When, though, that would get parsed and turned into DNS data isn't clear to me.) regards, Ted --94eb2c190786d8eb2a0559a228db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

Comments in-line, with some snipp= age to help keep it readable.

On Wed, Sep 20, 2017 at 12:15 AM, Mark Nottingham <mnot@mnot.= net> wrote:

>> What does "a resolver self-identified in the Javascript"= mean, exactly?
>>
>> Are you supposing some sort of rendezvous system where I can "= ;install" a DOH resolver from one origin and have it affect requests s= ent to another?
>
> Can I have JavaScript retrieve a resource like https://dns.initial-origin.example/q= uery-for-dns?www.major-search-engine.example then use the result i= n place of the browser's DNS routines or the system DNS routines for re= trieving https://www.major-search-engine.example/ w= ithin that JavaScrit application?

No.

The most you could do -- assuming when you say "JavaScript application= " you mean Web page

Yes, I mean JavaS= cript application downloaded into a browser.
=C2=A0
(because JS can be run elsewhere, e.g., NodeJS; = what's important is the constraints that the environment put upon it) -= - is reuse that result within that page (and thanks to Service Worker, the = origin as well, unless other pages opt out of SW), yes you can, today.

Mind you, there's nothing special about the proposal on the table that = makes it easier.


I have to disagree with this.=C2=A0 St= andardizing this method should make this easier by having a common format p= roduced by servers and consumed by clients.=C2=A0

=C2=A0=
Also, doing so is pretty tortured for very limited gain; off the top of my = head (handwave warning) you'd need to install a SW (or without it, crea= te a bunch of event handlers in the page itself) to intercept requests, do = your faux DNS, and then handle the response. This would work for embedded a= ssets (e.g., JS, CSS, images) reasonably well on modern browsers,

So the scope of the problem is:=C2=A0 a malicious p= iece of JavaScript can embed a DNS service into a web page such that some r= esources can be retrieved using its resolution rather than the browser or s= ystem library.=C2=A0 It's not clear how the user would determine that t= his was the case, so there is a risk of mis-attribution within the web page= .=C2=A0

That there is no intent to allow that informatio= n to be further propagated is certainly useful to know, but if I understand= you (and Adam) correctly, this problem must be handled somewhere because o= f the intersection of this proposal and JavaScript capabilities in a modern= browser.=C2=A0

As a charter question, is the descriptio= n of the problem and/or proposals around it in scope for this proposed work= ing group, or do we need to pass th problem to someone else.=C2=A0 If someo= ne else, who?

=


>
> The goal to use this as a swappable facilitating protocol for DNS reso= lution led me to that conclusion; in that usage, the resulting DNS data wou= ld populate the relevant DNS cache.=C2=A0 Re-using the same system within J= avaScript naively would have very bad properties; some segregation to handl= e the different levels of trust is required.

OK. If I read you correctly, you seem to be assuming that browsers (= and other systems?) will somehow automatically handle responses that use a = particular media type (or a specific URI scheme, or whatever) with elevated= privileges (e.g., inserting them into the browser/OS DNS cache). I don'= ;t think this is part of the proposal. If someone has proposed that, please= to point to the message so we can engage that idea.


I think you an= d I agree that if an OS or browser configuration frob specifies a recursive= resolver that uses DOH, that the results go where ever they would have gon= e had the same information come in via UDP, TCP, TLS, or DTLS.=C2=A0 From t= he information in this email, we agree that taking DNS responses from a DOH= recursive resolver specified in a download JavaScript application would cu= rrently be limited to that application and those from the same origin (and = that building anything to take it further would be unwise).=C2=A0 There'= ;s some work to do on how to handle misattribution within that context, but= it is not the same scope as the OS/browser configured data.
=C2=A0
I think Adam and others believe that you *could* use this protocol f= rom JavaScript (in a Web browser or otherwise) in a limited fashion (as out= lined above), in that you would be bound by the security model of the envir= onment you're working within. I don't think that is a major use cas= e for this work, but it is a possible one.

I don't think that anyone wants to establish new Web APIs to allow Java= Script to manipulate the browser/OS DNS resolution process or state. I cert= ainly do not.

Adam et al - If these statements aren't accurate, please say so.

More to the point, the IETF is *not* the appropriate venue to be making cor= e changes to the browser security model; at the very least, if we were doin= g that, we'd need to be coordinating *very* closely with the Web Applic= ation Security WG in the W3C.

Should we be passing the char= ter by the Web Application Security WG in the W3C now for comments?


As above, defining this protocol won't change the capability of = Web scripting by even the smallest amount. People do what they can today, a= nd those capabilities will be the same after this is defined.


It will change= the relationship of that Web scripting capability with the DNS (or at leas= t make that relationship much easier).=C2=A0 Given where the DNS is in our = stack, that's an important change.=C2=A0 If an attacker can take inform= ation from an origin and have it treated as DNS data, it become the foundat= ion of retrievals from other origins.

To hideously over-s= implify, the same origin security model presumes that resources from an ori= gin share a scope.=C2=A0 But if the origin is a recursive resolver among ot= her capabilities, the resources retrieved may provide data about where to g= et other resources from outside that scope.=C2=A0

As long as there = no APIs which push that data past the same origin boundary, the problem wit= h that is limited to misattribution within the same origin.=C2=A0 But it is= still a problem because of the role DNS info plays.

=C2=A0
>=C2=A0 Folks asserting that it could not be eliminated from the capabil= ity set for JavaScript applications caused me to focus on the latter.=C2=A0= If the work can be constrained such that this does not arise, so much the = better.

It's not a matter of constraining the work; the work isn't p= roposing to operate even remotely in the way that you describe. I think we&= #39;re just having a misunderstanding, because people have multiple use cas= es in mind for this protocol, and properties thereof have been mixed up.=C2=A0
AIUI those use cases are, roughly:

1. Configure your browser/OS to use a DOH service for DNS resolution (as ab= ove) -- this will affect browser/OS state, because it's being used for = DNS; however, it's not being done from JS.

Agreed, and I think this a very valuable piece of wor= k to get done, especially for the multiplexing properties of H2 or QUIC.

=C2=A0
2. Call a DOH service from Javascript (for some reason) -- note this is jus= t like any other HTTP request; it doesn't affect browser/OS state outsi= de of the same origin model. Yes, you can still build a browser-in-a-browse= r and mess with things inside that context, but that's already true tod= ay.


While this is no doubt unintended, thi= s tends to give a "everything is already ruined" flavor to your r= esponse.=C2=A0 If we're standardizing this, I think we need to take how= this data is integrated and presented as part of the overall deployment pr= oblem. If we're not the right folks to do that part of the work, I thin= k we need to get the right folks involved as soon as possible and to put co= ordination with that community into the charter along with DNSOP and the ot= hers already listed.

3. Future handwavy things like making DNS updates over HTTP -- very ill-def= ined and not important for this discussion

<= br>
Yeah, I can't even tell from this whether you mean client= s updating their info a la DNS dynamic update=C2=A0 a la RFC 3007 or you me= an push style updates of fresh responses from a recursive resolver.=C2=A0 Y= ou can certainly leave the first out.=C2=A0 Whether you can leave the secon= d out or not depends on an interaction between the HTTP caching model and t= he DNS caching model (That is, if a configured DOH server pushes a new resp= onse to a query that hasn't been asked yet, it would go into the HTTP c= ache in anticipation of the question being asked.=C2=A0 When, though, that = would get parsed and turned into DNS data isn't clear to me.)

regards,

Ted
=C2=A0
--94eb2c190786d8eb2a0559a228db-- From nobody Wed Sep 20 10:25:23 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AD813202D; Wed, 20 Sep 2017 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD6PtDXyuRt7; Wed, 20 Sep 2017 10:25:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB23126D0C; Wed, 20 Sep 2017 10:25:05 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8KHP2qx073667 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Sep 2017 12:25:03 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ted Hardie , Mark Nottingham Cc: doh@ietf.org, Paul Hoffman , IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> <296AD098-5728-44E6-855F-91881359162C@mnot.net> From: Adam Roach Message-ID: <2bc5fab5-ce23-54d9-7440-6d55940560cd@nostrum.com> Date: Wed, 20 Sep 2017 12:24:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 17:25:09 -0000 On 9/20/17 12:17, Ted Hardie wrote: > That there is no intent to allow that information to be further > propagated is certainly useful to know, but if I understand you (and > Adam) correctly, this problem must be handled somewhere because of the > intersection of this proposal and JavaScript capabilities in a modern > browser. This can be done with or without any work in the IETF. If the hack mnot describes is possible[1], then having a standardized format for launching such queries (rather than doing the *exact* same thing in a proprietary syntax) neither helps nor hinders the attack. That said, I want to stress quite heavily that I don't think this kind of attack is possible due to the scoping rules around which resources a service worker is allowed to handle. /a ____ [1] I'm extremely dubious that this could be pulled off even for normal resources; for HTTPS-secured resources, replacing the host with the result of DNS resolution would cause cert validation to fail, so it definitely can't be mounted there. From nobody Wed Sep 20 15:28:24 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7620132026; Wed, 20 Sep 2017 15:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=rQDGqjZ5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GnhypxkP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Ag6u9HyNHPO; Wed, 20 Sep 2017 15:28:19 -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 D1AAA1320D8; Wed, 20 Sep 2017 15:28:03 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3BC3620B87; Wed, 20 Sep 2017 18:28:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 20 Sep 2017 18:28:03 -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:x-sasl-enc; s=fm1; bh=Lyqwr/20hcgWg9WZk1 MY1lU1b+idtDYMXZEt+MYdlic=; b=rQDGqjZ5PzHgL1/GFqEUjGIRGW1xF7KCS8 5lnL9TxeUsjH6HTZ3eG4OGSq/oLQT+MIU27fi2NsJoFXbEisRBI35gD2ZRf72W+r YqopOyDtdGKVdb6sTee8M0c1uWyFecMqRAYDGWxOvnH+B9JoyoMYsw5wLQiAqyU5 R5pdBKnalougSQzcq8zhvGVYksYcW+hnAB8/62b8yKnSAazbhyItf7plVM6eRhdR IDTwTdVkVC0hSM+WsnnEbhGhoeUAHaxyvjjd7Tn30emXczzCfAVrFmbF5H0Cq012 tbM65ucC+Jm9ROMEX+DiuBMZ3gggVimLtKdEe+V7EYHlUXOvqPew== 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:x-sasl-enc; s= fm1; bh=Lyqwr/20hcgWg9WZk1MY1lU1b+idtDYMXZEt+MYdlic=; b=GnhypxkP p1X/c3SvrmxhOzFO1IVjdGHseoW+RMu0nvuyTPgkZHkjgEUfq2SwHbHcqFqFDRdF KQa0cvCkdv2eesY2xAvuJtKRZdt3PVvbfcIE9SoL6Z4zhkfXxXyUhAG/U61xBeuC XReL8uM0nKV3stopJqCBnDgQYBXuZXih8a0eyuzuPJoWKFpnpsPHt/qwqu3dryXd VzJDvY5iFj2Nq6IWEWxl+IEToNkyhsAwCukyLzDkyoCeoiVIbBNEsCW3usMzvzx/ jjwsQUnj1eU6t/70PguS6SI2UjhPYknzHbG/93wWsM500jXTU8dE0YXgzP341mJl mB5tIPmHlWcJEg== X-ME-Sender: X-Sasl-enc: jv70vaKIfJZx/KZpuAIRMpN0Rco9g5sCbwht2KihDaSI 1505946482 Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id CC6C97E202; Wed, 20 Sep 2017 18:28:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Thu, 21 Sep 2017 08:27:57 +1000 Cc: Adam Roach , doh@ietf.org, Paul Hoffman , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <50B5D46F-CD7C-4D6A-8218-E8C0EB1A5C0A@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <0EA5CC8C-D4B0-47F4-A8CF-950BDB1A1D55@mnot.net> <32479A66-5D72-48CF-8C33-2D131AEB2B5B@mnot.net> <89896E61-3275-4214-BEC5-59D40B6DDA4A@mnot.net> <296AD098-5728-44E6-855F-91881359162C@mnot.net> To: Ted Hardie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 22:28:23 -0000 On 21 Sep 2017, at 3:17 am, Ted Hardie wrote: >=20 >> Mind you, there's nothing special about the proposal on the table = that makes it easier. >=20 > I have to disagree with this. Standardizing this method should make = this easier by having a common format produced by servers and consumed = by clients. =20 In the case you're concerned about -- hostile JS -- the server that = hosts the malicious JS is the same party that produces the poisoned DNS = response. Even if it's cross-origin, the attack implies that they're = coordinating. Defining the wire format for those messages is trivial; I = suppose we're doing a small amount of work for them, but that work isn't = any barrier to the attack. > So the scope of the problem is: a malicious piece of JavaScript can = embed a DNS service into a web page such that some resources can be = retrieved using its resolution rather than the browser or system = library. No. The scope of the problem is that once someone malicious has = Javascript executing within a context, it's effectively game over for = that context. Much of the focus of Web Application Security over the = last few years has been on reducing that attack surface, especially = where it's not intentional (e.g., CSP).=20 Again, there is no magical way for JavaScript to plug itself into the = system DNS library. There *is* a magical way for JavaScript to monkey = patch pretty much anything within the page load -- that's what we're = talking about here. What this WG does doesn't affect that ability, even = on the margins; it's already there. > It's not clear how the user would determine that this was the case, = so there is a risk of mis-attribution within the web page. =20 This is a pre-existing risk, and browser vendors, the WHATWG and W3C = have spend significant time considering and mitigating it (in a = nutshell, only trust the browser chrome, which is *not* under the = control of JS). We do not own this problem. > That there is no intent to allow that information to be further = propagated is certainly useful to know, but if I understand you (and = Adam) correctly, this problem must be handled somewhere because of the = intersection of this proposal and JavaScript capabilities in a modern = browser. =20 It's already handled. > As a charter question, is the description of the problem and/or = proposals around it in scope for this proposed working group, or do we = need to pass th problem to someone else. If someone else, who? It's not in-scope here, and since it's already handled, we don't need to = pass it anywhere else. > I think you and I agree that if an OS or browser configuration frob = specifies a recursive resolver that uses DOH, that the results go where = ever they would have gone had the same information come in via UDP, TCP, = TLS, or DTLS. Yes, provided it was from the same source. > =46rom the information in this email, we agree that taking DNS = responses from a DOH recursive resolver specified in a download = JavaScript application would currently be limited to that application = and those from the same origin (and that building anything to take it = further would be unwise). Where 'context' is defined by the Web security model (which, like DNS, = is specified a bit all-over-the-place, but still works somehow) -- yes. > There's some work to do on how to handle misattribution within that = context, but it is not the same scope as the OS/browser configured data. I strongly disagree that there's work to do -- this is already within = the existing security model of the Web platform.=20 > Should we be passing the charter by the Web Application Security WG in = the W3C now for comments? If that would help us move along, sure. >> As above, defining this protocol won't change the capability of Web = scripting by even the smallest amount. People do what they can today, = and those capabilities will be the same after this is defined. >=20 > It will change the relationship of that Web scripting capability with = the DNS (or at least make that relationship much easier). Given where = the DNS is in our stack, that's an important change. If an attacker can = take information from an origin and have it treated as DNS data, it = become the foundation of retrievals from other origins. >=20 > To hideously over-simplify, the same origin security model presumes = that resources from an origin share a scope. But if the origin is a = recursive resolver among other capabilities, the resources retrieved may = provide data about where to get other resources from outside that scope. = =20 >=20 > As long as there no APIs which push that data past the same origin = boundary, the problem with that is limited to misattribution within the = same origin. But it is still a problem because of the role DNS info = plays. Right, but this is already possible today, and easy for someone to = implement, because the Web allows you to create little protocols between = JS and the server on-the-fly. >> 2. Call a DOH service from Javascript (for some reason) -- note this = is just like any other HTTP request; it doesn't affect browser/OS state = outside of the same origin model. Yes, you can still build a = browser-in-a-browser and mess with things inside that context, but = that's already true today. >=20 > While this is no doubt unintended, this tends to give a "everything is = already ruined" flavor to your response. That indeed wasn't intentional; the Web still works pretty well, = although I wouldn't bet on the long-term stability of the hair colour of = any given Web security professional. > If we're standardizing this, I think we need to take how this data is = integrated and presented as part of the overall deployment problem. If = we're not the right folks to do that part of the work, I think we need = to get the right folks involved as soon as possible and to put = coordination with that community into the charter along with DNSOP and = the others already listed. Imagine we're charting a working group for a financial data format -- = it's important that it has integrity and authority, and it's a target = for attackers, as are DNS records. The position you're taking seems to = be (roughly) that we need to make sure that people don't use the = standard financial data format to misrepresent other people's finances = in the case that there's a malicious piece of JS on a Web page.=20 Without trivialising that attack, having a defined format for the data = doesn't change its nature (and remember, we're not even really defining = a format; the current proposal is to reuse an existing format in HTTP = messages), and (again) we lack the expertise and authority in this area. I'm fine if we feel we need to confirm this with WebAppSec or other = parties before chartering. Beyond that, IMO adding any tasks to the WG's = plate to address it is a poor use of the IETF's resources. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Sep 20 15:54:21 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A3513304A; Wed, 20 Sep 2017 15:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oyGOlS2lqQEE; Wed, 20 Sep 2017 15:54:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4C171243F6; Wed, 20 Sep 2017 15:54:18 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8KMsAbI029051 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Sep 2017 17:54:11 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org, IETF-Announce References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> From: Adam Roach Message-ID: Date: Wed, 20 Sep 2017 17:54:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 22:54:20 -0000 The dichotomy you lay out doesn't make sense because HTTP already has a well-defined security model. As it stands, HTTPS  implies the use of trusted public roots, and CAB Forum Baseline Requirements section 9.2.1 forbids the issuance of a cert for IP addresses. One of the things that is appealing about HTTPS as a substrate (for better or worse) is that it has a well-defined and proven scalable system for the kind of security issues you describe below. The issue with putting discovery in this charter is that it's the wrong community of interest and expertise for what you propose. I would imagine that this is the same reason that RFC3315bis is being done in DHC rather than V6OPS (although -- full disclosure -- that decision is a bit outside of what I tend to track). /a On 9/20/17 10:14 AM, Toerless Eckert wrote: > On Fri, Sep 15, 2017 at 08:44:53AM -0700, The IESG wrote: > [...] >> Specification of how the DNS data may be used for new use cases, and >> the discovery of the DOH servers, are out of scope for the working group. > I disagree on this becoming a working group unless the charter says either: > > a) Discovery is in scope > > I have no specific preferences of what discovery is done, i just > think that the security discussion needs to take the discovery being used > into account. I can already see how DoH clients will just use some > configured IP address for the DoH server and accept whatever self-signed > TLS certs are being offered. And the industry thinks its great security > improvement because it uses TLS. I am sure there are enough people willing > to work on DoH that would be able to write down how to do that discovery piece > more securely, so why stop them doing it by writing "out of charter". > > or > > b) Security is optional. The documents will sprinkle some security fairy > dust in by mandating simple buzzwords like TLS Vmax so we can escape further > security discussions. > > ;-) > > Cheers > Toerless > From nobody Wed Sep 20 16:39:57 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190DE132199; Wed, 20 Sep 2017 16:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6G2wznPqjino; Wed, 20 Sep 2017 16:39:54 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5625C132198; Wed, 20 Sep 2017 16:39:54 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8KNdmWq036650 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Sep 2017 18:39:49 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at From: Adam Roach To: Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org, IETF-Announce References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> Message-ID: <825f487d-7f8c-db26-13bb-8d3a2febcb56@nostrum.com> Date: Wed, 20 Sep 2017 18:39:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 23:39:56 -0000 Correction -- it was flagged to me that I read the BR text too quickly; the prohibition here is against RFC 1918 IP addresses, not IP addresses in general. The general notion stands, however, that cert holders of IP address certs need to first demonstrate control of that address to obtain the cert in the same way as certs that refer to names. /a On 9/20/17 5:54 PM, Adam Roach wrote: > The dichotomy you lay out doesn't make sense because HTTP already has > a well-defined security model. As it stands, HTTPS  implies the use of > trusted public roots, and CAB Forum Baseline Requirements section > 9.2.1 forbids the issuance of a cert for IP addresses. One of the > things that is appealing about HTTPS as a substrate (for better or > worse) is that it has a well-defined and proven scalable system for > the kind of security issues you describe below. > > The issue with putting discovery in this charter is that it's the > wrong community of interest and expertise for what you propose. I > would imagine that this is the same reason that RFC3315bis is being > done in DHC rather than V6OPS (although -- full disclosure -- that > decision is a bit outside of what I tend to track). > > /a > > On 9/20/17 10:14 AM, Toerless Eckert wrote: >> On Fri, Sep 15, 2017 at 08:44:53AM -0700, The IESG wrote: >> [...] >>> Specification of how the DNS data may be used for new use cases, and >>> the discovery of the DOH servers, are out of scope for the working >>> group. >> I disagree on this becoming a working group unless the charter says >> either: >> >> a) Discovery is in scope >> >> I have no specific preferences of what discovery is done, i just >> think that the security discussion needs to take the discovery being >> used >> into account. I can already see how DoH clients will just use some >> configured IP address for the DoH server and accept whatever self-signed >> TLS certs are being offered. And the industry thinks its great security >> improvement because it uses TLS. I am sure there are enough people >> willing >> to work on DoH that would be able to write down how to do that >> discovery piece >> more securely, so why stop them doing it by writing "out of charter". >> >> or >> >> b) Security is optional. The documents will sprinkle some security fairy >> dust in by mandating simple buzzwords like TLS Vmax so we can escape >> further >> security discussions. >> >> ;-) >> >> Cheers >>      Toerless >> > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh From nobody Wed Sep 20 19:56:54 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512AC132C2A; Wed, 20 Sep 2017 19:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcvGI2H7Cj4I; Wed, 20 Sep 2017 19:56:45 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E02C132193; Wed, 20 Sep 2017 19:56:45 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id 93so3867822iol.4; Wed, 20 Sep 2017 19:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WM9PZxqF+tEX83LxWcTtLXdDUDMUstwgjO3sPHPTzK0=; b=sbd7hPzFBgtuJCIX6bDOpIxygWuqmiw2wdoJFwJtbebG1dMi1BWIB053Jv/FhcvP3F IsZEd26uc8fEpZiliXC4kKHodnr9+RA8Dxver8zFG4zGCfjImQybXIERVev15wQqputU YhEiOZAZYMkQluwYE4xwOIV0mIYYABLKPGydUzaD8POjJwq4nTFG2x9W43VpjzGV4pMz JoVxEk7UR4N29D3sD++KxH/j6k8i5TrTB3j9yzATS7AyiEM1f1+2Lwd5ssKsM8Ry8wQS 1pLaT3mjFOxoz778/pzIxShYqmDItnRZ9pOTmyOG2S/lwR8ThbswnpBFApXjkB3kKqah zudA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WM9PZxqF+tEX83LxWcTtLXdDUDMUstwgjO3sPHPTzK0=; b=rFGGicnFobhv9sTu6WVsn+Q2hTcYxpXBBR7r9n0M6YuV/BDIVFwMCKZc5seYxZGh6W MwAqX9Fe/tRU23sbvt5kt5XKin4S/NzJQnWAmmGKbrAyu9iQ0QEzvMuFZX4d43ojRXT3 dZbrMEptXlA4Ac9nxsAYYF3fpaDNJ6FZYTvpYVHsQUQuzH3dU4aFTSSyQa44Vdpi7EEP CkF+9NEna3yuYeYtLRdfQDWf2PWyJQwghG4Ho6P72GpIbD/Ff0pKcHVEULXnBIYYGvqk gKl8mM8wKYctfx/FZXxsxOK+uOVaOt3q4SmsSootMHfW5Jbwze6OywuCk77s+bXKfssD 8yuw== X-Gm-Message-State: AHPjjUiaPXmzXcz27aC4oAtNtHzS6g7DgK3DSeTp3wiBbnndpf4AzZQB nZegcwiBhaBeA0BbyuI3FyYJnAB2EZ0FoENZY7AUJw== X-Google-Smtp-Source: AOwi7QD/auY7pxO5diW7HLeMKCrj8vwJB8hCwpcTnzmRcQLHrXN3QDzSsjV9Narjz1Vv8NzVGtozNhpgZI6fKNxsMpA= X-Received: by 10.202.168.21 with SMTP id r21mr867014oie.39.1505962604448; Wed, 20 Sep 2017 19:56:44 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Wed, 20 Sep 2017 19:56:43 -0700 (PDT) In-Reply-To: <20170920235150.GB27965@faui40p.informatik.uni-erlangen.de> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <825f487d-7f8c-db26-13bb-8d3a2febcb56@nostrum.com> <20170920235150.GB27965@faui40p.informatik.uni-erlangen.de> From: Phillip Hallam-Baker Date: Wed, 20 Sep 2017 22:56:43 -0400 X-Google-Sender-Auth: GVdarUT3-oVApmT_Ur1saKjkNhQ Message-ID: To: Toerless Eckert Cc: Adam Roach , doh@ietf.org, IETF Discussion Mailing List , IETF-Announce Content-Type: multipart/alternative; boundary="001a113cf33c156fca0559aa3e97" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 02:56:47 -0000 --001a113cf33c156fca0559aa3e97 Content-Type: text/plain; charset="UTF-8" Replying to many threads. 1) I am glad to hear that it is agreed that any WG in this area will 'be a marathon'. This is an important problem and it needs to be done right. And that means discussing the set of use cases to be addressed, developing requirements and only then looking at solutions. Do it right or not at all. 2) WS-* did too achieve its principal goal of making work for consultants. It looked promising at first and then... 3) We might well want to delay a decision on this issue until after the IAB ename workshop which might well lead to a game changer. 4) I agree with Mark Nottingham that this is an API thing and that IETF does not own the specs where the key APIs are defined. That is WebAPIs for JS (W3C) and POSIX. But here is the thing, if IETF says a DNS interface should look like X then by golly, I bet W3C and POSIX etc. will be only too happy to follow the lead. And the strange thing is that IETF has already got a DNS Interface which is really, really good and not the ones I proposed: https://tools.ietf.org/html/rfc6763 It has Apple's name on the spec so there is one major platform on board. And it is 2013 and supported by quite a bit of running code. The only real problem with the spec is that it is presented as 'one option' on how to do service discovery. Please, do not give me six ways to do a thing, give me one. And do not let application developers choose either. Pick one method that serves all the requirements and tell people to stick to it unless there is reason not to. Standards are all about taking away choices that don't matter. Have six ways to implement service discovery and I have to implement whichever one is picked for a protocol myself. Pick just one as the default and it will be there for me in a library. Yes, we can grandfather legacy protocols like HTTP and SMTP. But lets not force everyone to implement everything. The only problem I have with RFC6763 is that the power of the idea had to be hidden to get through process. This draft takes the ideas in RFC6763 and takes them to their logical conclusion: http://prismproof.org/Documents/draft-hallambaker-json-web-service.html In short, what I think the Javascript, C, C# API for service discovery should look like is: Connection = Interface.GetService (
, ) for example: Connection = Interface.GetService ("example.com", "_http._tcp") That is it. I want all the extraneous stuff to go away or be hidden as options. It should be possible for the DNS records to force use of a security enhancement (e.g. a specific version of TLS with specific trust anchor) That API could be implemented using existing DNS protocol at the client certainly. The incentive to change the client-resolver protocol would be motivated by latency, not by functionality. The big problem with DNS is that the protocol is only reliable for one request and one response and even if you could do multiple requests in one packet, the discovery mechanisms are more complex and inherently require multiple round trips. --001a113cf33c156fca0559aa3e97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Rep= lying to many threads.

1)= I am glad to hear that it is agreed that any WG in this area will 'be = a marathon'. This is an important problem and it needs to be done right= . And that means discussing the set of use cases to be addressed, developin= g requirements and only then looking at solutions. Do it right or not at al= l.

2) WS-* did too achiev= e its principal goal of making work for consultants. It looked promising at= first and then...

3) We = might well want to delay a decision on this issue until after the IAB ename= workshop which might well lead to a game changer.

4) I agree with Mark Nottingham that this is an A= PI thing and that IETF does not own the specs where the key APIs are define= d. That is WebAPIs for JS (W3C) and POSIX.=C2=A0


But here is the thing, if IETF says a DNS interface should lo= ok like X then by golly, I bet W3C and POSIX etc. will be only too happy to= follow the lead. And the strange thing is that IETF has already got a DNS = Interface which is really, really good and not the ones I proposed:

https://= tools.ietf.org/html/rfc6763

<= /div>
It has Apple's name on the spec so th= ere is one major platform on board. And it is 2013 and supported by quite a= bit of running code. The only real problem with the spec is that it is pre= sented as 'one option' on how to do service discovery.

Please, do not= give me six ways to do a thing, give me one. And do not let application de= velopers choose either. Pick one method that serves all the requirements an= d tell people to stick to it unless there is reason not to. Standards are a= ll about taking away choices that don't matter. Have six ways to implem= ent service discovery and I have to implement whichever one is picked for a= protocol myself. Pick just one as the default and it will be there for me = in a library.

Yes, we can grandfather legacy protocols like HTTP and SMTP. Bu= t lets not force everyone to implement everything.


The only problem I have with RFC6763 is that the power of t= he idea had to be hidden to get through process. This draft takes the ideas= in RFC6763 and takes them to their logical conclusion:

http://prismproof.org/Documents/draft-hallambaker-json-web-se= rvice.html


In short, what I = think the Javascript, C, C# API for service discovery should look like is:<= /div>

Co= nnection =3D Interface.GetService (<address>, <protocol>)
=

for exa= mple:=C2=A0

Connection =3D Interface.GetService ("example.com", "_http._tcp")

That is it. I wan= t all the extraneous stuff to go away or be hidden as options. It should be= possible for the DNS records to force use of a security enhancement (e.g. = a specific version of TLS with specific trust anchor)


That API could be implemented using existing DNS protocol a= t the client certainly. The incentive to change the client-resolver protoco= l would be motivated by latency, not by functionality. The big problem with= DNS is that the protocol is only reliable for one request and one response= and even if you could do multiple requests in one packet, the discovery me= chanisms are more complex and inherently require multiple round trips.


--001a113cf33c156fca0559aa3e97-- From nobody Thu Sep 21 00:02:47 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0213292F; Thu, 21 Sep 2017 00:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8R1i-haZbkg; Thu, 21 Sep 2017 00:02:42 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBC513308F; Thu, 21 Sep 2017 00:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7493; q=dns/txt; s=iport; t=1505977362; x=1507186962; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=SxXrumKWy9gGpr7lw9K8dYM1/AbwoJzdXCYAUs1GBU4=; b=SvOLhGaiY9gITM8RRe1vnMIUCoG6ZNH8eWYtF4w47hJKM+gHTq4jZkfw N/iV9PmjsMJ+bETzdg6t3bv1qDIgM59fHVVldnLckNoXkkNxIp6coAIiP ls9wZLpxxP78RAzV+ZAT2MkLKvkdntLDBmxYaxOkH9bs0h/bbYXTxoHBb w=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAQC4YsNZ/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgy2BEW6EHYsUkE0rkGuHUAcDhTsChSwUAQIBAQEBAQEBayiFGQE?= =?us-ascii?q?FI0gOEAsEFCoCAlcGAQwIAQEQih+nPYInJ4pXAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBDg+DK4U3K4J9iA6CYAWhE4Q7giGNe4tXhySVOoE5NiFBTDIhCBwVSYUZHIF?= =?us-ascii?q?pPolYAQEB?= X-IronPort-AV: E=Sophos;i="5.42,424,1500940800"; d="asc'?scan'208,217";a="655804045" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 07:02:39 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8L72dU3006047; Thu, 21 Sep 2017 07:02:39 GMT To: Adam Roach , Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: Date: Thu, 21 Sep 2017 09:02:41 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="shAxErH3h3UbOorpaSKGwQKjQfTD08wbp" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 07:02:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --shAxErH3h3UbOorpaSKGwQKjQfTD08wbp Content-Type: multipart/mixed; boundary="qBCSsBhiFXSRp64crhVWTl9AsmONhcJvL"; protected-headers="v1" From: Eliot Lear To: Adam Roach , Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org Message-ID: Subject: Re: WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> In-Reply-To: --qBCSsBhiFXSRp64crhVWTl9AsmONhcJvL Content-Type: multipart/alternative; boundary="------------A8644F12EB540089CC268460" Content-Language: en-US This is a multi-part message in MIME format. --------------A8644F12EB540089CC268460 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On 9/21/17 12:54 AM, Adam Roach wrote: > The issue with putting discovery in this charter is that it's the > wrong community of interest and expertise for what you propose. I > would imagine that this is the same reason that RFC3315bis is being > done in DHC rather than V6OPS (although -- full disclosure -- that > decision is a bit outside of what I tend to track). The IETF has provenance over the DNS standards, and that ought not be so quickly relinquished.=C2=A0 That includes discovery, which we have covere= d in the past through mechanisms such as DHCP and RA.=C2=A0 We needn't be the = only ones to speak on the subject nor need there be only a single method defined within IETF, but not speaking about it at all runs the risk of creating a massive mess for enterprise deployments, because if the wrong resolver is discovered, any number of functions commonly used in enterprises will break, not the least of which would be malware detection.=C2=A0 Perhaps enterprises could put up with that if they knew = how to regain the capability, and that ties back to discovery (and scoping). Within the IETF, because the group isn't formed, you can't say whether or not you have the correct community of interest engaged to do any of the work because you have bypassed the BoF process that asks important questions.=C2=A0 In fact, in this thread, apart from two people (myself a= nd PHB), I'm not sure ANYONE outside the author or the IESG and IAB has actually stood up and said they're interested in this work.=C2=A0 But eve= n putting that aside, because you haven't held a BoF, you don't really know whether or not you will have the right people in the room to handle discovery.=C2=A0 And people are having trouble answering THAT question because the goal is not clear (although mnot seems to have some notions which sound ok). What bothers me about this discussion is that adding a DHCP option is not difficult, and the current operating model of the dhcp working group is that they don't do options, but leave that to other wgs.=C2=A0 And so = you are creating a vacuum for this possibility through the exclusion clause in the charter. I am**not saying that the work has to be done all at once, by the way, or in one document.=C2=A0 The discussion on the IETF list demonstrates, i= f nothing else, that at least one clear theory of operation should also be documented. Eliot --------------A8644F12EB540089CC268460 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi,

On 9/21/17 12:54 AM, Adam Roach wrote:=
The issue with putting discovery in this charter is that it's the wrong community of interest and expertise for what you propose. I would imagine that this is the same reason that RFC3315bis is being done in DHC rather than V6OPS (although -- full disclosure -- that decision is a bit outside of what I tend to track).

The IETF has provenance over the DNS standards, and that ought not be so quickly relinquished.=C2=A0 That includes discovery, which we h= ave covered in the past through mechanisms such as DHCP and RA.=C2=A0 We needn't be the only ones to speak on the subject nor need there be only a single method defined within IETF, but not speaking about it at all runs the risk of creating a massive mess for enterprise deployments, because if the wrong resolver is discovered, any number of functions commonly used in enterprises will break, not the least of which would be malware detection.=C2=A0 Perhaps enterprises could = put up with that if they knew how to regain the capability, and that ties back to discovery (and scoping).

Within the IETF, because the group isn't formed, you can't say whether or not you have the correct community of interest engaged to do any of the work because you have bypassed the BoF process that asks important questions.=C2=A0 In fact, in this thread, apart from t= wo people (myself and PHB), I'm not sure ANYONE outside the author or the IESG and IAB has actually stood up and said they're interested in this work.=C2=A0 But even putting that aside, because you haven't = held a BoF, you don't really know whether or not you will have the right people in the room to handle discovery.=C2=A0 And people are having trouble answering THAT question because the goal is not clear (although mnot seems to have some notions which sound ok).

What bothers me about this discussion is that adding a DHCP option is not difficult, and the current operating model of the dhcp working group is that they don't do options, but leave that to other wgs.=C2=A0 And so you are creating a vacuum for this possibility thro= ugh the exclusion clause in the charter.

I am not saying that the work has to be done all at once, by the way, or in one document.=C2=A0 The discussion on the IETF list demonstrates, if nothing else, that at least one clear theory of operation should also be documented.

Eliot


--------------A8644F12EB540089CC268460-- --qBCSsBhiFXSRp64crhVWTl9AsmONhcJvL-- --shAxErH3h3UbOorpaSKGwQKjQfTD08wbp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZw2QSAAoJEIe2a0bZ0nozqmEIAIA74zoWAxfq/twphGIzruwG Km9tkmeTkPS4CE4k0xeCT7Jb+O/IxDNirpD8KI6gm+CF6HJWpCl3N70LV0dDz9iP xiZ8Y4Zj9HTMKbFNTgGi3/bngeS/AUmULRqOuI5U7Tf7tmcUzHzXv1hopMhcrYid KxmxQu5OMPtj3GHOZx7ohkPF2U8CnNMXlE6BZrJjkpQSe0x3oJylm+8mOTGI0hc2 xK5LDXSO10a+fDoklp051zyLuJGZZIiNWUheikf1kp1PcR346i/aWOZOd5+HYhef PQ2Wn+j/yMFLoJaULdRw+X/SrEnmOTMdXXBaU11zVjQfjZFmeLX2bAVdATcyjwQ= =pkLA -----END PGP SIGNATURE----- --shAxErH3h3UbOorpaSKGwQKjQfTD08wbp-- From nobody Thu Sep 21 00:45:48 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240E6133072; Thu, 21 Sep 2017 00:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4np-C6xWBGwE; Thu, 21 Sep 2017 00:45:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CD3132941; Thu, 21 Sep 2017 00:45:45 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8L7jYhB017177 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Sep 2017 02:45:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Eliot Lear , Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> From: Adam Roach Message-ID: Date: Thu, 21 Sep 2017 02:45:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 07:45:47 -0000 On 9/21/17 2:02 AM, Eliot Lear wrote: > In fact, in this thread, apart from two people (myself and PHB), I'm > not sure ANYONE outside the author or the IESG and IAB has actually > stood up and said they're interested in this work. Quoting the DISPATCH minutes for IETF 99: > Alexey: Art ADs will talk to Int and Sec ADs about dprive. Don't have an > answer now. It's clear there is some interest. Need to find a place for it. > > Cullen: show of hands willing to read drafts and do work. Wow - tons. /a From nobody Thu Sep 21 01:34:50 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2132E13307B for ; Thu, 21 Sep 2017 01:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3DUxe1yOiNh for ; Thu, 21 Sep 2017 01:34:47 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7174127517 for ; Thu, 21 Sep 2017 01:34:46 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id 4B100175A05 for ; Thu, 21 Sep 2017 01:34:46 -0700 (PDT) Received: (qmail 28332 invoked from network); 21 Sep 2017 08:34:45 -0000 Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 21 Sep 2017 08:34:45 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= In-Reply-To: Date: Thu, 21 Sep 2017 01:34:14 -0700 Cc: Patrick McManus , doh@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 08:34:48 -0000 > On Sep 16, 2017, at 9:07, Phillip Hallam-Baker = wrote: >=20 > 1) I see no evidence that HTTP/2 is suited to Web Services or will be = dominant in that role. HTTP/2 was designed to serve Web Browsing to the = exclusion of all other concerns. Which was the right choice to make. HTTP/2 is also better for services with many small requests, in = particular on high latency connections (or where each response might be = slow to start=E2=80=A6). Ask= From nobody Thu Sep 21 01:40:20 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F9134463 for ; Thu, 21 Sep 2017 01:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu0MirUZUigb for ; Thu, 21 Sep 2017 01:40:17 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98553132620 for ; Thu, 21 Sep 2017 01:40:17 -0700 (PDT) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mbox1.develooper.com (Postfix) with ESMTPS id BE1851758C1 for ; Thu, 21 Sep 2017 01:35:11 -0700 (PDT) Received: (qmail 28373 invoked from network); 21 Sep 2017 08:35:10 -0000 Received: from c-67-188-112-34.hsd1.ca.comcast.net (HELO ?10.0.200.101?) (ask@mail.dev@67.188.112.34) by smtp.develooper.com with ESMTPA; 21 Sep 2017 08:35:10 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) From: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= In-Reply-To: Date: Thu, 21 Sep 2017 01:35:09 -0700 Cc: IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> To: doh@ietf.org X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 08:40:19 -0000 I find it curious that much of the debate has been about a particular = =E2=80=9CDNS consumer=E2=80=9D use case; I think dns-over-http can do = more (and as was pointed out, application APIs seem a bit out of scope). If you think of the DNS =E2=80=9Cflow=E2=80=9D as consumer =E2=80=94 client =E2=80=94 resolver server =E2=80=94 auth (just to make my example above clearer; in case I am mixing up the = proper terms used here, another example): application =E2=80=94 OS stub resolver =E2=80=94 [network] =E2=80=94 = bind/powerdns resolver/=E2=80=A6 =E2=80=94 bind/nsd/powerdns auth/=E2=80=A6= While I=E2=80=99d like access to lower level DNS information in browser = javascript as much as everyone else, limiting =E2=80=9Cdoh=E2=80=9D as = just a facility to bypass the OS resolver (and maybe the resolver = server) seems a bit limited. I think the target should be something that = could (eventually) be used in the rest of the =E2=80=9Cflow=E2=80=9D, = too. =46rom the dnsoverhttp group last November: > On Nov 22, 2016, at 20:47, Shane Kerr = wrote: >=20 > One thing that really stuck with me at the dnsoverhttp bar-BoF was = when someone said that DNS is adopting features that look like HTTP (DNS = sessions handling, DNS RR server-side push, etc.), and that HTTP is = adopting features that look like DNS (sending certificate chains, = providing address information, etc.). The someone was me. My thought is that if we=E2=80=99re changing the DNS protocol (or adding = another=E2=80=A6) there might be a big practical advantage in building = on the huge implementation investments being made in QUIC. The =E2=80=9Cvalue=E2=80=9D in DNS is the delegation and data model, not = the current =E2=80=9Cbits on the wire=E2=80=9D protocol. For future = features (privacy, encryption between resolvers and auth, etc) maybe a = different protocol would be appropriate. (Still quoting Shane) > I wonder if our models are starting to break down? Having two = protocols > with seemingly very little in common adopting the same features kind = of > implies that our abstractions are broken, right? It is (eventually) working out for IPv6! :-) Ask From nobody Thu Sep 21 01:57:33 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767461344C7; Thu, 21 Sep 2017 01:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7fkVO1BCh2p; Thu, 21 Sep 2017 01:57:23 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610CA1344C6; Thu, 21 Sep 2017 01:57:23 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8L8vJae029052 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 21 Sep 2017 03:57:19 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: =?UTF-8?Q?Ask_Bj=c3=b8rn_Hansen?= , doh@ietf.org Cc: IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Thu, 21 Sep 2017 03:57:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 08:57:24 -0000 On 9/21/17 3:35 AM, Ask Bjørn Hansen wrote: > While I’d like access to lower level DNS information in browser javascript as much as everyone else, limiting “doh” as just a facility to bypass the OS resolver (and maybe the resolver server) seems a bit limited. I think the conversation has perhaps become side-tracked by an example I used for pedagogical purposes. If you look at the text in the charter and the text in the named input document, the limitation you posit isn't present. /a From nobody Thu Sep 21 02:29:15 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959E9134611; Thu, 21 Sep 2017 02:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiWj-ssS10KT; Thu, 21 Sep 2017 02:29:12 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F86D13460E; Thu, 21 Sep 2017 02:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1811; q=dns/txt; s=iport; t=1505986152; x=1507195752; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=LkrwtUWCdAIvGW0lZpo4x7qMMRm9fYPq73+iZrXyVSo=; b=LuG292OvO9pbptmsLpN2KrcvMNFX/UDEBSsgNRlq5RP7bX0PFH8nYseL 3n1yqbc1cRFR9M3PkHSzcTIajCmi1mPVDtWyhi0UWGezOGREz9pM4FBKz tv4/KkpRG/kJomi00OE4QUyJM4VNZm1qjsj6AZidzJ+VqIrTQ8vv7u82Y 4=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQALhsNZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhB2LFJBMmGYHA4U7AoUyFAECAQEBAQEBAWsohRkGI1YQC0I?= =?us-ascii?q?CAlcGAQwIAQGKL6c2gieKfgEBAQEBAQEBAQEBAQEBAQEBAREPgyuFYoJ9iA6CY?= =?us-ascii?q?AWhE4Q7giGNe4F7AYlbhySVOoE5NiGBDTIhCBwVh2c+iVgBAQE?= X-IronPort-AV: E=Sophos;i="5.42,424,1500940800"; d="asc'?scan'208";a="697353440" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 09:28:46 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8L9SkcH011531; Thu, 21 Sep 2017 09:28:46 GMT To: Adam Roach , Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> From: Eliot Lear Message-ID: <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> Date: Thu, 21 Sep 2017 11:28:48 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N2OkAmpcSDnBPE0mb2whCPgwOfBA8sK92" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 09:29:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N2OkAmpcSDnBPE0mb2whCPgwOfBA8sK92 Content-Type: multipart/mixed; boundary="PeS9WRbaoTu1Xbi9FwTwK2BUv7IREw6S8"; protected-headers="v1" From: Eliot Lear To: Adam Roach , Toerless Eckert , ietf@ietf.org Cc: doh@ietf.org Message-ID: <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> In-Reply-To: --PeS9WRbaoTu1Xbi9FwTwK2BUv7IREw6S8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US You still don't have a reasonable answer for discovery. --PeS9WRbaoTu1Xbi9FwTwK2BUv7IREw6S8-- --N2OkAmpcSDnBPE0mb2whCPgwOfBA8sK92 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZw4ZQAAoJEIe2a0bZ0nozZiYH/2D2BoT07KWYPsVT8FEkJm8y iZc3xQA34s7zpqUrBVEus0iJJ723T5Id9JwiP7WUdUYnzKMbRRJFehnX4i/+V6Sj QcLpiTEYvPNZ4KfiNfuCtePB7D/1vH/K1u3xoydIfwdtoR9gGhbgxzxrHfSSBhBV eCPPXnMZ37drMZy5xEudgFqz+4XGRFT1hvfOvEKzsnw+fnzxGsDnyxpeubREmfYY JYCIW6HkPeE7xUNrRh8bhP/xcitV2qHWSrnLdCe7WUqk8FEMzsJaeDvUryIcxSTn tQGUHJJwTPlWvyEnlmAYVVkbWFqS9S18pIEMmiEV2MqUy8wtxCodkK3LK5Pytws= =549z -----END PGP SIGNATURE----- --N2OkAmpcSDnBPE0mb2whCPgwOfBA8sK92-- From nobody Thu Sep 21 04:41:24 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9F4134AEB; Thu, 21 Sep 2017 04:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=QWEHxwUi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kBNFLATG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9di5cB06dHHO; Thu, 21 Sep 2017 04:41:12 -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 CB798134AF5; Thu, 21 Sep 2017 04:41:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DBBEE20D58; Thu, 21 Sep 2017 07:41:08 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 21 Sep 2017 07:41:08 -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:x-sasl-enc; s=fm1; bh=IYVFAnST+pvMgDH5Xj RccJU6vhtMCWlZEI6K6Vt3ojU=; b=QWEHxwUiXx55lhYKNDKVcyhKjAdeSYj56G 9zTnNX6XiYA5Ld+l9BjyaUH+c6ITYynxYuNa+BVtF9F85uON6PKGqM/fGC34ubkk +ikVGC4maECWNVWpab2ehkHharjGBwdH+5a2RUfbg36P5GH54+NYw6m3TudpSj5J YyKoZdafoRjCMov9QJd5n7lf27VZ/Nsv0souk9naxzp38EiApmhcsN4tFgG2fWRT GvyUqOdhYETMMik7yuiNeZ/wUTWe+z7gnfJ3f0lwUmBUItlvJ7rrDr0YU8wN1cbY KI+b0rPjFAGATnhHjEKZEWtpZG8A1/wXBSqNAL95VTpR8nXBTM8g== 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:x-sasl-enc; s= fm1; bh=IYVFAnST+pvMgDH5XjRccJU6vhtMCWlZEI6K6Vt3ojU=; b=kBNFLATG bITxCGxkbrhU9dF8h0TYXZK+A2aUDIQJ7/DXHIDRsKp1HGVPBdeEJTQmzyw450Gt rcevas6j0sYf+aP/yWpGiBJoDR9enjmUWnMHyNC1Gb3oC8V0zNiVhlaWl9HjU8xz D8X5MgDzKHnIqMydttrxgKNaWJLKbwELkH4xAlTs5OXeJymSk/6pEaveL1JA8MZD 7OpnEKIw5WA/VmG8V9ER8YIBengNUdMBNWZ/5e4FAGT7HzHtebBjNsRPk4U7AJyU /n3dK5s+/NZ7Ct4ezPDhtTWbSp6vAzhxTOJmVJ4tgoBpFraPZi2AookKVt+eXnrB tnp4PbXKqCcRYQ== X-ME-Sender: X-Sasl-enc: 27A5CWka7o+IEi6GLUzOEdwC8QXJ2KhR/Mfd/MlQkYoG 1505994068 Received: from [192.168.1.25] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 7673F2436A; Thu, 21 Sep 2017 07:41:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> Date: Thu, 21 Sep 2017 21:41:02 +1000 Cc: Adam Roach , IETF , doh@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 11:41:15 -0000 On 21 Sep 2017, at 7:28 pm, Eliot Lear wrote: >=20 > You still don't have a reasonable answer for discovery. Discovery isn't necessary for the primary use case -- user-driven = configuration of their browser. We can specify a DHCP option, but since it won't have any qualitative = benefits over "normal" DHCP-configured DNS, I suspect it will get almost = no implementation or deployment. So it's effectively busy work for the = WG. -- Mark Nottingham https://www.mnot.net/ From nobody Thu Sep 21 04:56:47 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91029134B34; Thu, 21 Sep 2017 04:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18aA3T4Z3P6T; Thu, 21 Sep 2017 04:56:37 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3B9134B39; Thu, 21 Sep 2017 04:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5203; q=dns/txt; s=iport; t=1505994996; x=1507204596; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=oZLj8IhbonyfYcaHwetvAmtKa0kSIm3NZJ/Xr4+moo4=; b=iJUmpjZJOMMLcwnGoh+wODVRaRwBUqP3lF9qc5gs6UqN6te4dk8mOhTw Bp+jrODt+W//+wTjPLx8EJi5pXqr2gXGXbq5qAZ2TnsjXlTy+UgSih9Uh r0/V4RGNbGoUe+1NtwUlAOLNaf1FEh4t86YSZhsIiF0pIkLiflj3VNr8v 0=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CHAQA+qMNZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uJ4N2ixSQTQkikGuHUAcDhTsChFUVAQIBAQEBAQEBayiFGAE?= =?us-ascii?q?BAQECASNWBQsLBAoKKgICVwYNBgIBAYonCKZ/gicnilcBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEOD4MrhWILgnKIDoJgBaEThDuCIY17ghOFaoNahySVOoE5NSKBDTI?= =?us-ascii?q?hCBwVh2c+NokiAQEB?= X-IronPort-AV: E=Sophos;i="5.42,425,1500940800"; d="asc'?scan'208,217";a="697356832" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Sep 2017 11:56:34 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8LBuYbV027207; Thu, 21 Sep 2017 11:56:34 GMT To: Mark Nottingham Cc: Adam Roach , IETF , doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> From: Eliot Lear Message-ID: <7a70c140-9905-db14-66a3-b9bd4ea02fff@cisco.com> Date: Thu, 21 Sep 2017 13:56:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pPT8WMEb28JQgESOad4IsaeJq2gx0BdR6" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 11:56:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pPT8WMEb28JQgESOad4IsaeJq2gx0BdR6 Content-Type: multipart/mixed; boundary="Eqb02s9PqD8PwtbnhTKITeAsSFI0M2139"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham Cc: Adam Roach , IETF , doh@ietf.org Message-ID: <7a70c140-9905-db14-66a3-b9bd4ea02fff@cisco.com> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> In-Reply-To: <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> --Eqb02s9PqD8PwtbnhTKITeAsSFI0M2139 Content-Type: multipart/alternative; boundary="------------F93C025C938BFCBB9A90B80F" Content-Language: en-US This is a multi-part message in MIME format. --------------F93C025C938BFCBB9A90B80F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mark, I'll stop after this message.=C2=A0 Please see below: On 9/21/17 1:41 PM, Mark Nottingham wrote: > On 21 Sep 2017, at 7:28 pm, Eliot Lear wrote: >> You still don't have a reasonable answer for discovery. > Discovery isn't necessary for the primary use case -- user-driven confi= guration of their browser. Earlier you wrote: > The use case that I believe most have in mind is "as a user, I want to = configure my [browser, OS] to use *this* DOH service for DNS resolution" = -- where that configuration is manual; e.g., a configuration textbox or d= ropdown in the browser, or a file in /etc. Please get your story straight.=C2=A0 Bypassing enterprise DNS entails al= l the risks I previously mentioned.=C2=A0 No one here as mentioned a means = to mitigate those risks.=C2=A0 The only way I can think of is by tying this function into the OS and using the existing discovery mechanisms.=C2=A0 B= ut if all you've got as a browser, everything looks like Javascript, I suppo= se. Eliot --------------F93C025C938BFCBB9A90B80F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Mark,

I'll stop after this message.=C2=A0 Please see below:


On 9/21/17 1:41 PM, Mark Nottingham wrote:
On 21 Sep 2017, at 7:28 pm, Eliot Lear <lear@cisco.com&g=
t; wrote:

You still don't have a reasonable answer for discovery.

Discovery isn't necessary for the primary use case -- user-driven configu=
ration of their browser.

Earlier you wrote:
The use case that I believe most=
 have in mind is "as a user, I want to configure my [browser, OS] to use =
*this* DOH service for DNS resolution" -- wher=
e that configuration is manual; e.g., a configuration textbox or dropdown=
 in the browser, or a file in /etc.


Please get your story straight.=C2=A0 Bypassing enterprise DNS ent= ails all the risks I previously mentioned.=C2=A0 No one here as mentione= d a means to mitigate those risks.=C2=A0 The only way I can think of is= by tying this function into the OS and using the existing discovery mechanisms.=C2=A0 But if all you've got as a browser, everything lo= oks like Javascript, I suppose.

Eliot

--------------F93C025C938BFCBB9A90B80F-- --Eqb02s9PqD8PwtbnhTKITeAsSFI0M2139-- --pPT8WMEb28JQgESOad4IsaeJq2gx0BdR6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZw6j1AAoJEIe2a0bZ0nozQEwH/RR5gkcjdJJKEcRBYGJyZVzo 7zv+NBUlgR7Y4KJ5JdaMo6HSJn2V3dbQ06LOqX0UD/vqBxHWasayWRedueK8rJ6D 911OQBELJVQjT2t1NIJioClykB0PkeJHqsZC7Q+uCHbXm6liEtT3EnY7svPWC09Q qie7vDAOvzG4jc4D34kSD2ClLKgKvuUN7VDF/cjECMNTCQktw4kXCBVtr4HrtWeS ImalKijso4vxnRo3nwBsPa0JEGtA/NgGlwH+BM/FcgGbDFKTbNAE3zdx6RhI2dhf uwSCERMabdEVd9xukMh4njiay07Jddgx6ltUbnNsSdhJFMk/inzYJUPPSurWwN8= =WQSn -----END PGP SIGNATURE----- --pPT8WMEb28JQgESOad4IsaeJq2gx0BdR6-- From nobody Thu Sep 21 05:12:37 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD9C132055; Thu, 21 Sep 2017 05:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U5DsOLsZMDo; Thu, 21 Sep 2017 05:12:22 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9A5A9132949; Thu, 21 Sep 2017 05:12:20 -0700 (PDT) X-AuditID: c1b4fb3a-9e1d49c0000051a3-e4-59c3aca282a7 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5C.B2.20899.2ACA3C95; Thu, 21 Sep 2017 14:12:18 +0200 (CEST) Received: from [147.214.163.22] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 21 Sep 2017 14:12:17 +0200 To: CC: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: <86d3aee8-57bf-5baf-2fda-0849b3ba35f2@ericsson.com> Date: Thu, 21 Sep 2017 14:12:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010602090608030402090603" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdVHfRmsORBl/mKFpcu3uRzeLZxvks DkweS5b8ZApgjOKySUnNySxLLdK3S+DK2HdxL1vBF8+KbT9PMjcwnnbuYuTkkBAwkVi/tI2t i5GLQ0jgCKPEjD3NUM5mRokbvY3sIFXCAjoSjx4/YgWxRQSEJY48+gcWZxYQkti2aDMjiC0k 4Cux/MEXJhCbTcBC4uaPRjYQm1fAXuLHpFlgNouAqsSstxfAakQFYiR+XnrEAlEjKHFy5hMw m1PAT2Jt10+wI5gFuhkljvVMYoVYoC3R0NTBCnG2ksT1eddZJjAKzELSPwtZzyywA80k5m1+ yAxha0ssW/gayhaXaPqyEqrGWmLGr4NsELaixJTuh+wQtqnE66MfGSFsI4l3exrZFzByrmIU LU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjJGDW35b7WA8+NzxEKMAB6MSD+/dqMORQqyJZcWV uYcYVYDmPNqw+gKjFEtefl6qkgjv2RqgNG9KYmVValF+fFFpTmrxIUZpDhYlcV6HfRcihATS E0tSs1NTC1KLYLJMHJxSDYzmjTMflf1l7vvW/aAq/FtweGUc8873JrUfd8RLbvgfa/nO4GrK ecPObR7/tC3L92XMOVh6sXSxx8xdWcxLhK0sG9qLmziO/c/apvW9KuYZv/y347odAa0iZvq5 AfPnhnHnq+inlMc2GLnfLTr1aZEKs8gZpaOm9xWWdtSFtKvbyduEfv2yTImlOCPRUIu5qDgR AM46D3yZAgAA Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 12:12:28 -0000 --------------ms010602090608030402090603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, The issue with this charter I have is that unless you specify one or=20 several usages one can't evaluate or write security considerations or=20 even discuss the actual security properties of the resulting component.=20 Or rather the statement you can do is very limited. And I think the=20 below quote from the charter is quite misleading, even if accurate. Den 2017-09-15 kl. 17:44, skrev The IESG: > The use of HTTPS > provides integrity and confidentiality, and it also allows the transpor= t to > interoperate with common HTTPS infrastructure and policy. So, yes HTTPS will provide two properties. The DNS data provided are=20 from the "entity" given by Server's cert, and it is provided=20 confidentiality and integrity protected between that server and my=20 client. However, without discussing a particular usage of this format,=20 the system security properties and especially what trust I can place in=20 the data as well as what privacy that is provided is unknown. Just to show how strange this can be lets compare two different usages=20 with quite different properties are present. 1. After having connected to a web site, the web application uses its=20 own servers to resolve the DNS information for resources the client side = application needs by submitting those resolve requests to the same=20 origin server. In this case we keep the usage within the same trust=20 domain. The distributed web application uses the mechanism internally=20 with resolvers that it is configured to be trusted. Each web service has = its own resolver and the DNS resolution is internal and separated=20 between applications. 2. Using some autoconf setting, the free WIFI access point at Joe's=20 Coffe announces a DNS over HTTPS stub resolver. The only difference from = current DHCP DNS server setting is that the communication between the=20 client and resolver at the gateway is that communication is secured,=20 thus preventing active and passive attacks from other entities in the=20 same WIFI/LAN. But otherwise the trust possible in responses from the=20 resolver has not changed. Nor has the privacy aspects in respect to the=20 infrastructure and what happens upstream of the LAN gateway. I am quite worried that by simply defining a format and not discuss how=20 it will be used, people will lock on to those three words from the=20 charter: "integrity and confidentiality" and think this resolves everythi= ng. Also which "old" use cases that is really intended to cover and by which = entities are really not clear. As "new use cases" are ruled out of=20 scope. So, is the browser contacting an recursive resolver without going = through OS a new or an OLD use case? I really want more clarity on what the WG really should do as its first=20 steps and what usage considerations it needs to write! Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms010602090608030402090603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzA5MjExMjEyNDdaMC8GCSqGSIb3DQEJBDEiBCCjN59/JoCpCPA+sd3L 5iAxifL/wqQDX557UCG4ye/OWDBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEANhv4Dl4cObA1p5+HZqHf7snfYs89ojZzCEhLwyspG5GvXiL9 bZwIxOZsWhveYHc7taV8yCmfKw3KLRnOG/cl6zbGePGpVQyHiEflKQP9xXL5lW70Bstl6lO8 BdPZyrzAtSGMClR+8PaFuBlvSWEo6ngEoRgSXWx/ZLFC/xZsONaRTm0ZysdnqVUWOg3y8Aca ntQCrR7rZ8Qxi/cpRlUes8NBu2hGdj1b6YK7zpB6ch31/Mnbn6Me4rzPndFaZqxrX9KcsDnc Ws+yUh9WWhfqppEYKDfINZhhP8ygkgJKbuVYmNFP8xdvm9Bpiog6lzrXRINgzCQyh6TNq95g apEc3wAAAAAAAA== --------------ms010602090608030402090603-- From nobody Thu Sep 21 07:05:50 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC0613235C; Thu, 21 Sep 2017 07:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5EcxfY5KDOD; Thu, 21 Sep 2017 07:05:42 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 A0F241321C7; Thu, 21 Sep 2017 07:05:42 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id i50so6025421qtf.0; Thu, 21 Sep 2017 07:05:42 -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=lMohJdrmCgkmS/NG1Akpmgjj6UIGTVHxHLTITK5Nyb0=; b=rhRih2hqRDC2vYs7IHxybH3zy9Yi8i3X4yx1B5WAe3Vkaq+Rb4sHzxiJLp+AU84zVW cc149tKdOvKjaNadkFolIb98hvOGARJYN3BTymMn0ZTTb0iuc2tAPCrc77hcNKdxzmGI j89FfR+bS8vpUKXK73Q/70rFx6fjrLtmKg+70w2XJQI0Dzdi9BdYB17J1O0KcT3cDHE2 yPDOWHCDQBspjlBqc6qhlpukFPlYI5ckqXE6SZKXOLhp1GaY3affxsJhdaX6eYGjMjjV V5T+HDpZd0ceR7W144YGzMwymxjuOnYsEBlzezBRE9BH2J4aHUAiiJNOB68roqSSQjN2 mZ7w== 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=lMohJdrmCgkmS/NG1Akpmgjj6UIGTVHxHLTITK5Nyb0=; b=FCSGFUKm6P/zBYZn6PUWOpA7PboQgzpXAyKgrhPK0s7gHfl3SB2ibBhpGVVVru7K7O B52lCtg8HBkbm/v3wHZRH16o9AwelltN821IFBPBA99CJRSd5DkksDauArxqStK4jCdb VVGTWJZPAzGG8H3pyvRLGOBynswzMiWETSH45faQ4q0IXPQJP5X+aMOgF7Yl0axKfFbM Ymu04gQw7dOqRht/6WjEpn16a+yQNdVTIpaqG1BHpWKu/bkDxFxTM2NQ/XJbQG8Rlz7p tHfmSh9IXMFUA0kJJ0zP0A7EuWIOJ4h7JQhUbO9xxNsZWeIEibYrr1gUHNK7ECY8nPVc cUtg== X-Gm-Message-State: AHPjjUjowmKAnE/bOCbU+8MA9mMzu35DctPOPSxgRwKrOiaWA3udK6Gg 2tZCjDXEuypB5R+NoyjKLybQY88Uq5go5e56FgE= X-Google-Smtp-Source: AOwi7QAmAWNIQ7VVde/NXUCLiawIv/ETpRWMjjT9FDIfHwZD7O2bbynLyPr9i0YTrpeS+Owfk9L3jiSa9gdgZQhCS3k= X-Received: by 10.200.3.159 with SMTP id t31mr3400274qtg.338.1506002741516; Thu, 21 Sep 2017 07:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Thu, 21 Sep 2017 07:05:10 -0700 (PDT) In-Reply-To: <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> From: Ted Hardie Date: Thu, 21 Sep 2017 07:05:10 -0700 Message-ID: To: Mark Nottingham Cc: Eliot Lear , doh@ietf.org, Adam Roach , IETF Content-Type: multipart/alternative; boundary="f4030435bd30705c330559b396d2" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 14:05:44 -0000 --f4030435bd30705c330559b396d2 Content-Type: text/plain; charset="UTF-8" On Thu, Sep 21, 2017 at 4:41 AM, Mark Nottingham wrote: > On 21 Sep 2017, at 7:28 pm, Eliot Lear wrote: > > > > You still don't have a reasonable answer for discovery. > > Discovery isn't necessary for the primary use case -- user-driven > configuration of their browser. > > We can specify a DHCP option, but since it won't have any qualitative > benefits over "normal" DHCP-configured DNS, I suspect it will get almost no > implementation or deployment. So it's effectively busy work for the WG. > > I think you're underestimating the value of a switch to a multiplexing facilitating protocol/transport. Once this has gotten its legs under it, I suspect that this approach for connecting to caching resolver will perform better than any of traditional upd/tcp connections or the tls/dtls approaches DPRIVE created. And there is some discussion on that to be done, especially around whether you can re-use the current DHCP option (since it does not specify a port) and try this opportunistically or you should use a new option. Just my view, of course, Ted > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --f4030435bd30705c330559b396d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 21, 2017 at 4:41 AM, Mark Nottingham <mnot@mnot.n= et> wrote:
On 21 Sep 2017, at 7= :28 pm, Eliot Lear <lear@cisco.com= > wrote:
>
> You still don't have a reasonable answer for discovery.

Discovery isn't necessary for the primary use case -- user-drive= n configuration of their browser.

We can specify a DHCP option, but since it won't have any qualitative b= enefits over "normal" DHCP-configured DNS, I suspect it will get = almost no implementation or deployment. So it's effectively busy work f= or the WG.


I thi= nk you're underestimating the value of a switch to a multiplexing facil= itating protocol/transport.=C2=A0 Once this has gotten its legs under it, I= suspect that this approach for connecting to caching resolver will perform= better than any of traditional upd/tcp connections or the tls/dtls approac= hes DPRIVE created.

And there is some discussion on that = to be done, especially around whether you can re-use the current DHCP optio= n (since it does not specify a port) and try this opportunistically or you = should use a new option.

Just my view, of course,

=
Ted

=C2=A0

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

____________________________= ___________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--f4030435bd30705c330559b396d2-- From nobody Thu Sep 21 10:41:08 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8EDC1321A6; Thu, 21 Sep 2017 10:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzLljDzhQaMg; Thu, 21 Sep 2017 10:41:00 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 A50D4132199; Thu, 21 Sep 2017 10:41:00 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id h66so12541762ioh.11; Thu, 21 Sep 2017 10:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=fLFMggws0E42Y/MJxTUrwwWIgMVAJrKPugaKvfCaruQ=; b=bOTVwy9mghq/4+p39X5bDAUlIEQlYEwSYZy60AcSKWy6Q9KlI83bsQ89UcGP735qEW a/HAymtwzXPCK8Y60ILSMhk+qZT0+17KVu2Tgoewf/jkcCR7kA70F3jZYf9JfwLU933+ TNtwNsj6Lknp0kK7bICLEenEaAiTyNXHrB9FyOmVi8NAvsTmLIqzmQYzG9sH7B9OC/7X 7dYfKebAgfvyMrLUgJ4q9v8B092Gk0s3aYSz79+a1QbD20e9pRN+qTEXwsZOL/T8E4rT xrrY3ndlfwqo+BbsCuu9d31BMKyqf1Xp2RHrvP4SayruPmSNvPX9uwRYX7kavj+ZZ6jm agzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=fLFMggws0E42Y/MJxTUrwwWIgMVAJrKPugaKvfCaruQ=; b=KbqtETswiXdUgg6qVo3T9cB/7ZiXcAP+Pip94aM5++BL0yhN0QRUqv/bb3sjm7bO89 8GkSMk3pacRYnswJIPYAGAF0EQZLHBJeWlldkWWPOtqOyXwaPJbtoJWXxL2ovR38yzGh 3aewnOyJ1LJzKwZZcA1yrA9gpewQ5Zat6/igwyR16ulIpzKYljFM57nprfCj1KQfo4X+ lWiuX37IEXdzT6U2FJ5m9LcMaMdDH7Fi6oDrPPpYgAki5LlbWKsd2IjctS602ZAEvQ0h VxFqhxSy/yQUPb+Ul8uRTKHYVTIlPB9jvQHilDuxwYr3wm2oo+CqMu9wfDWw1ArxSnVQ 0FXw== X-Gm-Message-State: AHPjjUjLhQuFBbmjDAW9Wj5JRoQWLhzG5iCMhc9bGbNkJ5HYyAuqlqEw Xe7TbeZgYU69RTyax9Sc2OZN6prz7MLRLARmuhc= X-Google-Smtp-Source: AOwi7QDd4n6hkFwghTMs/WSKmxyoV2cs3XeEhkGNYLafWyK8daIlyFhOMROtqxn3U+XBMvBxb8pLbIm5knHwhvm8oYA= X-Received: by 10.202.75.66 with SMTP id y63mr3020620oia.5.1506015659940; Thu, 21 Sep 2017 10:40:59 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Thu, 21 Sep 2017 10:40:59 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> From: Phillip Hallam-Baker Date: Thu, 21 Sep 2017 13:40:59 -0400 X-Google-Sender-Auth: TLcExzaOzSCrm67ryA3qngm6ROE Message-ID: To: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= Cc: Patrick McManus , doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a113dc0a66fe3ed0559b6989f" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Thu, 21 Sep 2017 17:41:02 -0000 --001a113dc0a66fe3ed0559b6989f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 21, 2017 at 4:34 AM, Ask Bj=C3=B8rn Hansen wrote: > > > > On Sep 16, 2017, at 9:07, Phillip Hallam-Baker > wrote: > > > > 1) I see no evidence that HTTP/2 is suited to Web Services or will be > dominant in that role. HTTP/2 was designed to serve Web Browsing to the > exclusion of all other concerns. Which was the right choice to make. > > HTTP/2 is also better for services with many small requests, in particula= r > on high latency connections (or where each response might be slow to > start=E2=80=A6). > =E2=80=8BIf Web Services actually used HTTP features other than Firewall by= pass and framing of transactions, then HTTP/2 might be attractive. =E2=80=8BGiven ho= w little of the HTTP stack is used and given that QUIC is a much closer match, that is the route I want to take. I think it likely QUIC will eat up COAP as well. Just think of QUIC a way of doing TCP/2 in a way that is compatible with the protocol stacks as deployed in the field. At some point there will be a way to specify the service endpoint in a consistent fashion. --001a113dc0a66fe3ed0559b6989f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Sep 21= , 2017 at 4:34 AM, Ask Bj=C3=B8rn Hansen <ask@develooper.com> wrote:


> On Sep 16, 2017, at 9:07, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>
> 1) I see no evidence that HTTP/2 is suited to Web Services or will be = dominant in that role. HTTP/2 was designed to serve Web Browsing to the exc= lusion of all other concerns. Which was the right choice to make.

HTTP/2 is also better for services with many small requests, in part= icular on high latency connections (or where each response might be slow to= start=E2=80=A6).

=E2=80=8BIf Web Services actually used HT= TP features other than Firewall bypass and framing of transactions, then HT= TP/2 might be attractive. =E2=80=8BGiven how little of the HTTP stack is us= ed and given that QUIC is a much closer match, that is the route I want to = take.

I think it likely Q= UIC will eat up COAP as well.=C2=A0

Just think of QUIC a way of doing TCP/2 in a way that is compati= ble with the protocol stacks as deployed in the field. At some point there = will be a way to specify the service endpoint in a consistent fashion.
=C2=A0
--001a113dc0a66fe3ed0559b6989f-- From nobody Thu Sep 21 18:07:55 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D78B713239C; Thu, 21 Sep 2017 18:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=rtwkG8mC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GaMPNz05 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwyC_E1t3dWl; Thu, 21 Sep 2017 18:07:44 -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 D741913209C; Thu, 21 Sep 2017 18:07:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3CDFC213F1; Thu, 21 Sep 2017 21:07:43 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 21 Sep 2017 21:07:43 -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:x-sasl-enc; s=fm1; bh=/jiGUis0inqL6Y0lhl uCiUPWGUKAjYhKUeJLLzX8VgQ=; b=rtwkG8mCuTUU9BF8Db5O/9Lqo+C9h1d8z9 akGeOjqUn7AUGZS/lhmHaxOiZrHCN23evzbolCScwGvuJJD4LCbcVP+e0+d9izaG Hti7e8lCeHCsaG6z/+0ZPw6fJTOxhrkz8jkVzVC2MNdlBwiixTZtQSKh6rfVZ87v Fqe/JmEAyKLUoZiWWvrXyWXTR/owARYeCgZL6bdTpRy3HZ2GCbdkhnnfeaG1V+gZ 3VZW4NsI8SvUiW7gzMDtSBjfSuUFkEJMbkrX8ygZxVu3C9tTv3zyGzMXpatutsLm vN7LQePpaENyjwfEYHLwjDSJ9YKZBo1q3egC4w900YwYtvt+ZOug== 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:x-sasl-enc; s= fm1; bh=/jiGUis0inqL6Y0lhluCiUPWGUKAjYhKUeJLLzX8VgQ=; b=GaMPNz05 kBce928uslQnx0kpFUTB+n7p37siCvgnF8fZEENxdkavN9lmRc8UncTlclnqOwOt nDn4IQP2tPLL540EVYQhLA2xEYrfh0JxWddJBaXXiwjASINekyvduSo3h0Pq4xP/ ShXYcp7cqieyKXKLYsRfM96+ZGMufeF2SL3EOFP0Z+eJcBDNYJdHEX4hz5OxLGMD jn1EsXzHYwuN3srtiafUhAAF9p2MWU4qKGwPnLqmAzY2PwEA32sCJN4WaJQ3qBT/ pQWnceWyB6R1nJJ2+uoelrBzFBZb4OOL1kLAuOqAgS2qs5XUdNCHf/ckZZ6wPo8y DoilIdjW5pfgGQ== X-ME-Sender: X-Sasl-enc: LSh5SSloizhcuDTV1OZNJkBBWo3tqDxu/Awjn++QNot/ 1506042462 Received: from [10.223.64.64] (unknown [1.152.254.127]) by mail.messagingengine.com (Postfix) with ESMTPA id 59DB07E1D2; Thu, 21 Sep 2017 21:07:42 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E434DE27-F265-4E29-B446-D02CDEEDCFC9 Mime-Version: 1.0 (1.0) From: Mark Nottingham X-Mailer: iPhone Mail (15A372) In-Reply-To: Date: Fri, 22 Sep 2017 11:07:38 +1000 Cc: =?utf-8?Q?Ask_Bj=C3=B8rn_Hansen?= , doh@ietf.org, IETF Content-Transfer-Encoding: 7bit Message-Id: <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> To: Phillip Hallam-Baker Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 01:07:47 -0000 --Apple-Mail-E434DE27-F265-4E29-B446-D02CDEEDCFC9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I suppose, although it would be good to understand if perf problems to a dhc= p configured resolver are widely encountered.=20 I wouldn=E2=80=99t be against text in the charter that allows the wg to cons= ider mirroring currently defined (by the ietf) dns discovery mechanisms. I=E2= =80=99d be against definition of new ones.=20 Sent from my iPhone > On 22 Sep 2017, at 3:40 am, Phillip Hallam-Baker w= rote: >=20 >=20 >> On Thu, Sep 21, 2017 at 4:34 AM, Ask Bj=C3=B8rn Hansen wrote: >>=20 >>=20 >> > On Sep 16, 2017, at 9:07, Phillip Hallam-Baker w= rote: >> > >> > 1) I see no evidence that HTTP/2 is suited to Web Services or will be d= ominant in that role. HTTP/2 was designed to serve Web Browsing to the exclu= sion of all other concerns. Which was the right choice to make. >>=20 >> HTTP/2 is also better for services with many small requests, in particula= r on high latency connections (or where each response might be slow to start= =E2=80=A6). >=20 > =E2=80=8BIf Web Services actually used HTTP features other than Firewall b= ypass and framing of transactions, then HTTP/2 might be attractive. =E2=80=8B= Given how little of the HTTP stack is used and given that QUIC is a much clo= ser match, that is the route I want to take. >=20 > I think it likely QUIC will eat up COAP as well.=20 >=20 > Just think of QUIC a way of doing TCP/2 in a way that is compatible with t= he protocol stacks as deployed in the field. At some point there will be a w= ay to specify the service endpoint in a consistent fashion. >=20 > =20 --Apple-Mail-E434DE27-F265-4E29-B446-D02CDEEDCFC9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I suppose, although it would be good to und= erstand if perf problems to a dhcp configured resolver are widely encountere= d. 

I wouldn=E2=80=99t be against text in the charte= r that allows the wg to consider mirroring currently defined (by the ietf) d= ns discovery mechanisms. I=E2=80=99d be against definition of new ones. = ;

Sent from my iPhone

On= 22 Sep 2017, at 3:40 am, Phillip Hallam-Baker <phill@hallambaker.com> wrote:


On Thu, Sep 21, 2017 at 4:34 AM, Ask Bj=C3=B8rn Hansen <ask@develooper= .com> wrote:


> On Sep 16, 2017, at 9:07, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
>
> 1) I see no evidence that HTTP/2 is suited to Web Services or will be d= ominant in that role. HTTP/2 was designed to serve Web Browsing to the exclu= sion of all other concerns. Which was the right choice to make.

HTTP/2 is also better for services with many small requests, in parti= cular on high latency connections (or where each response might be slow to s= tart=E2=80=A6).

=E2=80=8BIf Web Services actually used HTTP f= eatures other than Firewall bypass and framing of transactions, then HTTP/2 m= ight be attractive. =E2=80=8BGiven how little of the HTTP stack is used and g= iven that QUIC is a much closer match, that is the route I want to take.

I think it likely QUIC will ea= t up COAP as well. 

Ju= st think of QUIC a way of doing TCP/2 in a way that is compatible with the p= rotocol stacks as deployed in the field. At some point there will be a way t= o specify the service endpoint in a consistent fashion.

=  
= --Apple-Mail-E434DE27-F265-4E29-B446-D02CDEEDCFC9-- From nobody Thu Sep 21 22:03:59 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4B91331B0; Thu, 21 Sep 2017 22:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tND3q_8dFE5Q; Thu, 21 Sep 2017 22:03:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36965133083; Thu, 21 Sep 2017 22:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2873; q=dns/txt; s=iport; t=1506056636; x=1507266236; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=f9dvuq+bPXNeF0M7F7mxIEQZgzLqdWxRkdf7cv6d+ZQ=; b=Hw8TccQLjN1A2ATGHuecjjpgKtaC/rSyBf27lfVhRE//xQGf4/66hC0V SSDgbxVfJmpg8VOu30IiJqPgiPQmGb/1j2YOKtDQnyTH4WszADWoFPml1 cj/oabb5ZhJ5yDHafEBIKNhPZ/FMHN8EmOXhVkIKwz6N4HsU7D2t7r8si 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AQAzmcRZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhB2LFJBQK5g7BwOFOwKEVhUBAgEBAQEBAQFrKIUZAQUjVhA?= =?us-ascii?q?LDgoqAgJXBgEMCAEBii+nLoIniwMBAQEBAQEBAQEBAQEBAQEBAQERD4MrhWKCf?= =?us-ascii?q?YgOgmAFoROEO4IhjXyBe4ldhyaVPoE5NSJBTDIhCBwVh2c+jA4BAQE?= X-IronPort-AV: E=Sophos;i="5.42,426,1500940800"; d="asc'?scan'208";a="697390132" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 05:03:54 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8M53rrK029267; Fri, 22 Sep 2017 05:03:53 GMT To: Mark Nottingham , Phillip Hallam-Baker Cc: =?UTF-8?Q?Ask_Bj=c3=b8rn_Hansen?= , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> From: Eliot Lear Message-ID: Date: Fri, 22 Sep 2017 07:03:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HM2VgX90GHwrtQJxsIHuEW32jwSosPLsk" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 05:03:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HM2VgX90GHwrtQJxsIHuEW32jwSosPLsk Content-Type: multipart/mixed; boundary="Goh6svpePto3ETCjmJWQnAn6rC5dQKCS7"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham , Phillip Hallam-Baker Cc: =?UTF-8?Q?Ask_Bj=c3=b8rn_Hansen?= , doh@ietf.org, IETF Message-ID: Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> In-Reply-To: <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> --Goh6svpePto3ETCjmJWQnAn6rC5dQKCS7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi, On 9/22/17 3:07 AM, Mark Nottingham wrote: > I suppose, although it would be good to understand if perf problems to > a dhcp configured resolver are widely encountered.=C2=A0 > > I wouldn=E2=80=99t be against text in the charter that allows the wg to= > consider mirroring currently defined (by the ietf) dns discovery > mechanisms. I=E2=80=99d be against definition of new ones. I know I wrote my last message would be my last, but I thought it would be useful to indicate that the above would be fine with me. Eliot --Goh6svpePto3ETCjmJWQnAn6rC5dQKCS7-- --HM2VgX90GHwrtQJxsIHuEW32jwSosPLsk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZxJm+AAoJEIe2a0bZ0noz7+YIAM6tnpERC0HW+G37BWFJselU FaD9xt9UJTupqVpDD9jYL53SUYxmBzjri6RzSWZiwx3bR9b2qSCPgHf+l/POuT4a Ef6AYMqvLBPl6adZGhk0mThxJjCiZiHiqqIO8ciC1G3/7snng3FOWEkwZQxSl05f L1Gj6jv2WXrZEjWKMqlsWsqfoyKXcIrIgvjIxfDyTki3ZI5zXoxFesZR+ifkwiP6 +XDA57Ck7Qh9y3IDpsTRkfDI8+MY0bpp06eCYrvEQxpgi5fTYsb/XonesHB0iXUs OS9qJfBSfTDFEvg3jqfkpGQ3J20NR/LJuXTjNIJ3X3Ws+l8DEgS5jHsRgLMCFQ8= =SzWc -----END PGP SIGNATURE----- --HM2VgX90GHwrtQJxsIHuEW32jwSosPLsk-- From nobody Fri Sep 22 08:31:31 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90F4132705; Wed, 20 Sep 2017 08:15:09 -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, HEADER_FROM_DIFFERENT_DOMAINS=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 CAzNzwHB0FWg; Wed, 20 Sep 2017 08:15:03 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFEE1321A0; Wed, 20 Sep 2017 08:15:03 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 672F058C4BF; Wed, 20 Sep 2017 17:14:59 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3919CB0CC42; Wed, 20 Sep 2017 17:14:59 +0200 (CEST) Date: Wed, 20 Sep 2017 17:14:59 +0200 From: Toerless Eckert To: ietf@ietf.org Cc: IETF-Announce , doh@ietf.org Message-ID: <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 22 Sep 2017 08:31:29 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 15:15:10 -0000 On Fri, Sep 15, 2017 at 08:44:53AM -0700, The IESG wrote: [...] > Specification of how the DNS data may be used for new use cases, and > the discovery of the DOH servers, are out of scope for the working group. I disagree on this becoming a working group unless the charter says either: a) Discovery is in scope I have no specific preferences of what discovery is done, i just think that the security discussion needs to take the discovery being used into account. I can already see how DoH clients will just use some configured IP address for the DoH server and accept whatever self-signed TLS certs are being offered. And the industry thinks its great security improvement because it uses TLS. I am sure there are enough people willing to work on DoH that would be able to write down how to do that discovery piece more securely, so why stop them doing it by writing "out of charter". or b) Security is optional. The documents will sprinkle some security fairy dust in by mandating simple buzzwords like TLS Vmax so we can escape further security discussions. ;-) Cheers Toerless From nobody Fri Sep 22 08:31:36 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5724132199; Wed, 20 Sep 2017 16:50:38 -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, HEADER_FROM_DIFFERENT_DOMAINS=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 qa08N3k9VwZu; Wed, 20 Sep 2017 16:50:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24EC132198; Wed, 20 Sep 2017 16:50:35 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 220BF58C4AF; Thu, 21 Sep 2017 01:50:32 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 08BF7B0CC4B; Thu, 21 Sep 2017 01:50:31 +0200 (CEST) Date: Thu, 21 Sep 2017 01:50:31 +0200 From: Toerless Eckert To: Adam Roach Cc: ietf@ietf.org, doh@ietf.org, IETF-Announce Message-ID: <20170920235031.GA27965@faui40p.informatik.uni-erlangen.de> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 22 Sep 2017 08:31:29 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 23:50:39 -0000 Thanks, Adam Your first paragraph is looking to me like a stub of the explanation that i am looking for. Eg: The DoH server MUST include a domain name, which then allows you to validate the certificate in the same way against public root as any other domain names, etc. pp. You still need some resolution from that domain name to IP address which may not be DNS, but it would not have a security impact anymore. Thats whats called the resolution and may be out of charter ? Did this capture the essence ? How about the issues known from browsers with public roots. Good enough tom make DoH consistent with the issues your browser already has ? Cheers Toerless On Wed, Sep 20, 2017 at 05:54:09PM -0500, Adam Roach wrote: > The dichotomy you lay out doesn't make sense because HTTP already > has a well-defined security model. As it stands, HTTPS implies the > use of trusted public roots, and CAB Forum Baseline Requirements > section 9.2.1 forbids the issuance of a cert for IP addresses. One > of the things that is appealing about HTTPS as a substrate (for > better or worse) is that it has a well-defined and proven scalable > system for the kind of security issues you describe below. > > The issue with putting discovery in this charter is that it's the > wrong community of interest and expertise for what you propose. I > would imagine that this is the same reason that RFC3315bis is being > done in DHC rather than V6OPS (although -- full disclosure -- that > decision is a bit outside of what I tend to track). > > /a > > On 9/20/17 10:14 AM, Toerless Eckert wrote: > >On Fri, Sep 15, 2017 at 08:44:53AM -0700, The IESG wrote: > >[...] > >>Specification of how the DNS data may be used for new use cases, and > >>the discovery of the DOH servers, are out of scope for the working group. > >I disagree on this becoming a working group unless the charter says either: > > > >a) Discovery is in scope > > > >I have no specific preferences of what discovery is done, i just > >think that the security discussion needs to take the discovery being used > >into account. I can already see how DoH clients will just use some > >configured IP address for the DoH server and accept whatever self-signed > >TLS certs are being offered. And the industry thinks its great security > >improvement because it uses TLS. I am sure there are enough people willing > >to work on DoH that would be able to write down how to do that discovery piece > >more securely, so why stop them doing it by writing "out of charter". > > > >or > > > >b) Security is optional. The documents will sprinkle some security fairy > >dust in by mandating simple buzzwords like TLS Vmax so we can escape further > >security discussions. > > > >;-) > > > >Cheers > > Toerless > > -- --- tte@cs.fau.de From nobody Fri Sep 22 08:31:39 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18401321B6; Wed, 20 Sep 2017 16:51:55 -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, HEADER_FROM_DIFFERENT_DOMAINS=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 Xeo84hMvuPe9; Wed, 20 Sep 2017 16:51:54 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31877132198; Wed, 20 Sep 2017 16:51:54 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 7677558C4FA; Thu, 21 Sep 2017 01:51:50 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 63982B0CC4B; Thu, 21 Sep 2017 01:51:50 +0200 (CEST) Date: Thu, 21 Sep 2017 01:51:50 +0200 From: Toerless Eckert To: Adam Roach Cc: ietf@ietf.org, doh@ietf.org, IETF-Announce Message-ID: <20170920235150.GB27965@faui40p.informatik.uni-erlangen.de> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <825f487d-7f8c-db26-13bb-8d3a2febcb56@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <825f487d-7f8c-db26-13bb-8d3a2febcb56@nostrum.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 22 Sep 2017 08:31:29 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Wed, 20 Sep 2017 23:51:56 -0000 Whow, that sounds grizzly for dynamically allocated IP addresses on broadband links. On Wed, Sep 20, 2017 at 06:39:47PM -0500, Adam Roach wrote: > Correction -- it was flagged to me that I read the BR text too > quickly; the prohibition here is against RFC 1918 IP addresses, not > IP addresses in general. The general notion stands, however, that > cert holders of IP address certs need to first demonstrate control > of that address to obtain the cert in the same way as certs that > refer to names. > > /a > > On 9/20/17 5:54 PM, Adam Roach wrote: > >The dichotomy you lay out doesn't make sense because HTTP already > >has a well-defined security model. As it stands, HTTPS implies > >the use of trusted public roots, and CAB Forum Baseline > >Requirements section 9.2.1 forbids the issuance of a cert for IP > >addresses. One of the things that is appealing about HTTPS as a > >substrate (for better or worse) is that it has a well-defined and > >proven scalable system for the kind of security issues you > >describe below. > > > >The issue with putting discovery in this charter is that it's the > >wrong community of interest and expertise for what you propose. I > >would imagine that this is the same reason that RFC3315bis is > >being done in DHC rather than V6OPS (although -- full disclosure > >-- that decision is a bit outside of what I tend to track). > > > >/a > > > >On 9/20/17 10:14 AM, Toerless Eckert wrote: > >>On Fri, Sep 15, 2017 at 08:44:53AM -0700, The IESG wrote: > >>[...] > >>>Specification of how the DNS data may be used for new use cases, and > >>>the discovery of the DOH servers, are out of scope for the > >>>working group. > >>I disagree on this becoming a working group unless the charter > >>says either: > >> > >>a) Discovery is in scope > >> > >>I have no specific preferences of what discovery is done, i just > >>think that the security discussion needs to take the discovery > >>being used > >>into account. I can already see how DoH clients will just use some > >>configured IP address for the DoH server and accept whatever self-signed > >>TLS certs are being offered. And the industry thinks its great security > >>improvement because it uses TLS. I am sure there are enough > >>people willing > >>to work on DoH that would be able to write down how to do that > >>discovery piece > >>more securely, so why stop them doing it by writing "out of charter". > >> > >>or > >> > >>b) Security is optional. The documents will sprinkle some security fairy > >>dust in by mandating simple buzzwords like TLS Vmax so we can > >>escape further > >>security discussions. > >> > >>;-) > >> > >>Cheers > >> Toerless > >> > > > >_______________________________________________ > >Doh mailing list > >Doh@ietf.org > >https://www.ietf.org/mailman/listinfo/doh > -- --- tte@cs.fau.de From nobody Fri Sep 22 08:31:44 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26D134323; Fri, 22 Sep 2017 05:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlegsVoF3J74; Fri, 22 Sep 2017 05:12:50 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 A576213431F; Fri, 22 Sep 2017 05:12:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:36369) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dvMp6-000yW3-3A (Exim 4.89) (return-path ); Fri, 22 Sep 2017 13:12:49 +0100 Date: Fri, 22 Sep 2017 13:12:48 +0100 From: Tony Finch To: Ted Hardie cc: Mark Nottingham , doh@ietf.org, IETF In-Reply-To: Message-ID: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Fri, 22 Sep 2017 08:31:29 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 12:12:52 -0000 Ted Hardie wrote: > I think you're underestimating the value of a switch to a multiplexing > facilitating protocol/transport. Once this has gotten its legs under it, I > suspect that this approach for connecting to caching resolver will perform > better than any of traditional upd/tcp connections or the tls/dtls > approaches DPRIVE created. DNS over TCP already supports out-of-order responses. The reason it has historically not performed very well is that server implementations have handled queries on a TCP connection serially rather than concurrently. But this is improving. BIND 9.11 (for example) supports concurrent queries with out-of-order responses over TCP and TCP fast open, so queries over TCP should perform well, and better than UDP for large responses. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Faeroes, Southeast Iceland: Southeasterly 4 or 5, increasing 6 to gale 8 later. Moderate or rough, occasionally very rough later. Showers, rain later. Good, becoming moderate or poor later. From nobody Fri Sep 22 09:01:01 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B170B134513; Fri, 22 Sep 2017 09:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEEyl73dOPOm; Fri, 22 Sep 2017 09:00:57 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001: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 9CE42134516; Fri, 22 Sep 2017 09:00:46 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id v36so4098348ioi.1; Fri, 22 Sep 2017 09:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GjR0WOAbC9ExvNeujs21iMPGZ5kZV4i3bVXLjxf9+kk=; b=TXftlTYyDwNS/21X8s4Ij8fz2ngACxkNuLeXDhWc4akbLg4BQDkrorBJFZu1BL9oGd MDsq9JBeelf0GjmTQ9c8ghFTQpQf7XsTlOkeE90JsG8xYfDrbiQWzAnFcl3qMmnqEpLC j07iH144FTEoKXNM7CtCJUZzO2N4zZ5ZTmND5lW/H+qnzHV9O9yVufbWiAXM06WpfS3a /C+bw/wLHzra/+A9tkpmxSzKNZ/tkJZK2mJcclZ77Rhagxxh0ccW/0MWoendmQA3Ehbo ZSeBrPDixFPX766nULpG0TGNx/6+LWyIKO6JxMzUh4IOGD8Y0X0yHY3ZGWEQo0aAEjuv A7cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GjR0WOAbC9ExvNeujs21iMPGZ5kZV4i3bVXLjxf9+kk=; b=lDT2vfaFQSPgt5bA692tjOnImpEKwOw7BhtagOYY03fmEpEWYcIDHfDhAJsGQEw9Cg ukyX2Tfnqhf8czhW/sif37yGMuHDUq1osteW2Xp09zYKActuUWNHKy90quLX/mSEv6ON /3o4Txf4JqFJsFn1smgUpL3lOoUimV735Wc4WM4R8Bhg2hZ58J0N2QH51vXAyCeFuM7o ZYh9j+3vi6PbN4cfPzphATEfBRfZNXSDu5CQdrSzlRP0S/wQ5lgj4OhCDZr0MtGLtIrP yht6R7TqnUPYN+yBhrIQU8M008vwJeK+tcMHY4Xx1hNpTZyrOaGHsRiTji6jlMq6oQyb 4EXA== X-Gm-Message-State: AHPjjUhmz3CCp+Pt6XfqbBRmMsyPUrnmRKSjBesfbPV3tt4TIoeH80dN vCbvD7fqAyFseL/y1x5o8V5eURJvUka9QD7xCkQ= X-Google-Smtp-Source: AOwi7QBjTJSeT0fkDLl+S0vdWYIo3El8TadxjQR42JsQJN8wLfEDxYvz71mLMhdrTTJCxCz6Tcr8f211sCTASedn/hQ= X-Received: by 10.202.168.21 with SMTP id r21mr7289615oie.39.1506096045017; Fri, 22 Sep 2017 09:00:45 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.46.177 with HTTP; Fri, 22 Sep 2017 09:00:43 -0700 (PDT) In-Reply-To: <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <42309404-8991-5d1d-7834-59087f273d41@nostrum.com> <271db5c4-8d29-5a0d-cf7f-58e1e3831c30@cs.tcd.ie> <05C29362-CD48-429C-92FA-7F402869E58C@vpnc.org> <1e8323a8-4afc-397f-209e-099ffca212f6@cs.tcd.ie> <5BD60394-42BD-45E4-A964-A7F53C540FBC@mnot.net> From: Phillip Hallam-Baker Date: Fri, 22 Sep 2017 12:00:43 -0400 X-Google-Sender-Auth: 5E6NBLfJgOLDITSPn8V-f7VqGnE Message-ID: To: Mark Nottingham Cc: =?UTF-8?Q?Ask_Bj=C3=B8rn_Hansen?= , doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a113cf33cc2ed510559c94fd8" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 16:00:59 -0000 --001a113cf33cc2ed510559c94fd8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 21, 2017 at 9:07 PM, Mark Nottingham wrote: > I suppose, although it would be good to understand if perf problems to a > dhcp configured resolver are widely encountered. > > I wouldn=E2=80=99t be against text in the charter that allows the wg to c= onsider > mirroring currently defined (by the ietf) dns discovery mechanisms. I=E2= =80=99d be > against definition of new ones. > =E2=80=8B+1 =E2=80=8BI think that everyone really needs to take a look at this spec: https://tools.ietf.org/html/rfc6763. It is not the best description of a general DNS discovery mechanism because it was not allowed to be presented as such. It had to be couched as an 'option'. The DNS folk think that the answer to every problem is a new RR and they are oblivious to the fact that the DNS protocol does not allow that. Even if you can populate the records into the DNS your provider uses, the fact that you can only query for one record at a time or for all records makes use of multiple RRs for discovery unworkable. What I would like to see is 'take RFC6763 as the starting point and define a common set of tags for use in TXT'=E2=80=8B --001a113cf33cc2ed510559c94fd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On = Thu, Sep 21, 2017 at 9:07 PM, Mark Nottingham <mnot@mnot.net> wr= ote:
I suppose, alt= hough it would be good to understand if perf problems to a dhcp configured = resolver are widely encountered.=C2=A0

I wouldn=E2=80=99= t be against text in the charter that allows the wg to consider mirroring c= urrently defined (by the ietf) dns discovery mechanisms. I=E2=80=99d be aga= inst definition of new ones.=C2=A0

=E2=80=8B+1= =C2=A0


=E2= =80=8BI think that everyone really needs to take a look at this spec: https://tools.ietf.org/html/rfc6= 763. It is not the best description of a general DNS discovery mechanis= m because it was not allowed to be presented as such. It had to be couched = as an 'option'.=C2=A0

The DNS folk think that the answer to every problem is a new RR and th= ey are oblivious to the fact that the DNS protocol does not allow that. Eve= n if you can populate the records into the DNS your provider uses, the fact= that you can only query for one record at a time or for all records makes = use of multiple RRs for discovery unworkable.


What I would like to see is 'take RFC6763 as the starting po= int and define a common set of tags for use in TXT'=E2=80=8B

--001a113cf33cc2ed510559c94fd8-- From nobody Fri Sep 22 09:37:12 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86406134531; Fri, 22 Sep 2017 09:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, 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 WXvC7VnUiUm2; Fri, 22 Sep 2017 09:37:03 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1B658132E24; Fri, 22 Sep 2017 09:37:03 -0700 (PDT) Received: from mail-lf0-f49.google.com (mail-lf0-f49.google.com [209.85.215.49]) by linode64.ducksong.com (Postfix) with ESMTPSA id 4546A3A0B6; Fri, 22 Sep 2017 12:37:01 -0400 (EDT) Received: by mail-lf0-f49.google.com with SMTP id a18so1653938lfl.13; Fri, 22 Sep 2017 09:37:01 -0700 (PDT) X-Gm-Message-State: AHPjjUh5LZBNZ4oXUIF3rL868MwoN2lS8ecNdbIhV7oTc1V5MyGhrcd9 x2WZZBeWK0O8qP9Q4+dg+V6TbvKQrVng0LZLMBY= X-Google-Smtp-Source: AOwi7QD7qxNi3qestqIsLZA+xRM1hL+0fl59iVzOTxN6VCoMBPDUoTwno3+IRkp0FxSZX73+ZNgURTUF0NZWyJ6OUbg= X-Received: by 10.25.22.106 with SMTP id m103mr2284504lfi.168.1506098219922; Fri, 22 Sep 2017 09:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.200 with HTTP; Fri, 22 Sep 2017 09:36:58 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> From: Patrick McManus Date: Fri, 22 Sep 2017 12:36:58 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Warren Kumari Cc: Tony Finch , Ted Hardie , doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a11407d24653b710559c9d1e7" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 16:37:05 -0000 --001a11407d24653b710559c9d1e7 Content-Type: text/plain; charset="UTF-8" On Fri, Sep 22, 2017 at 12:24 PM, Warren Kumari wrote: > > Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858 > ("Specification for DNS over Transport Layer Security (TLS)"). > > double yup. https >=h2 offers a couple, really minor in the grand scheme of things, similar advantages beyond that too. One is a rather seamless (no additional specification necessary) upgrade to httpOverQuic when that happens which will help with the tcp level in-order suboptimality.. the other is multiplexing within any partial response (as opposed to just reordering whole responses) that is blocking the wire (slow to generate additional records, or big things like axfr..). They're just nice to haves but they should help with the tail cases. > > DPRIVE solves much of this, but one weakness is that it is still > clearly DNS traffic. yep. --001a11407d24653b710559c9d1e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 22, 2017 at 12:24 PM, Warren Kumari <<= a href=3D"mailto:warren@kumari.net" target=3D"_blank">warren@kumari.net= > wrote:

Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858 ("Specification for DNS over Transport Layer Security (TLS)").
double yup. https >=3Dh2 offers a couple, really m= inor in the grand scheme of things, similar advantages beyond that too. One= is a rather seamless (no additional specification necessary) upgrade to ht= tpOverQuic when that happens which will help with the tcp level in-order su= boptimality.. the other is multiplexing within any partial response (as opp= osed to just reordering whole responses) that is blocking the wire (slow to= generate additional records, or big things like axfr..). They're just = nice to haves but they should help with the tail cases.
=C2= =A0

DPRIVE solves much of this, but one weakness is that it is still
clearly DNS traffic.

yep.

<= br>
--001a11407d24653b710559c9d1e7-- From nobody Fri Sep 22 10:23:42 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA04D134554; Fri, 22 Sep 2017 10:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb2B6KHog8dv; Fri, 22 Sep 2017 10:23:24 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4BD13452A; Fri, 22 Sep 2017 10:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2561; q=dns/txt; s=iport; t=1506101003; x=1507310603; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9HUpSDNCTs+P4Isd1f5/YtnKvyuj3a3zeAag0HjuIJA=; b=h9IP1w5fsi+WyBhfinxIWR3Eu5kXgxrFfE7Ga7fhzxlaPPefGIh4XLGw Q02zwIgdgKGSxu2CRNTPaUg9aDLcwepgvILqbRPfZEvR8WCPsZfmiovWK 28No8J9CxDUnKm0ucu9s5ErXIMnOtm4cwEWEUQ3Qk7oh6GVCpGMRAIt50 s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AQAkRsVZ/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD5uhB2LFJBPCSKYOgcDhTsChGcUAQIBAQEBAQEBayiFGQEFI1Y?= =?us-ascii?q?QCxgqAgJXBgEMCAEBii+mfoInixQBAQEBAQEBAQEBAQEBAQEBAQERD4MrhTcrC?= =?us-ascii?q?4JyiA6CYAWhF4Q7giGOAIF7AYlfhymVRIE5NiGBDjIhCB0Vh2g+imEBAQE?= X-IronPort-AV: E=Sophos;i="5.42,427,1500940800"; d="asc'?scan'208";a="654856057" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Sep 2017 17:23:21 +0000 Received: from [10.61.237.201] ([10.61.237.201]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v8MHNKTN004173; Fri, 22 Sep 2017 17:23:21 GMT To: Warren Kumari , Tony Finch Cc: Ted Hardie , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> From: Eliot Lear Message-ID: <0d059767-51eb-d583-1122-a11f4ba9a4aa@cisco.com> Date: Fri, 22 Sep 2017 19:23:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O3kh75vLitbb3Tx8NNWRVOU8XRLDagaOx" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 17:23:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --O3kh75vLitbb3Tx8NNWRVOU8XRLDagaOx Content-Type: multipart/mixed; boundary="5NrCiCHSDVe6FJehsmE3lcAkW72L3rx8F"; protected-headers="v1" From: Eliot Lear To: Warren Kumari , Tony Finch Cc: Ted Hardie , doh@ietf.org, IETF Message-ID: <0d059767-51eb-d583-1122-a11f4ba9a4aa@cisco.com> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> In-Reply-To: --5NrCiCHSDVe6FJehsmE3lcAkW72L3rx8F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Warren, Just a point of information: On 9/22/17 6:24 PM, Warren Kumari wrote: > Unfortunately you cannot separate case 1 from case 2 -- if you make it > something that enterprise folk can detect / block (on BYOD devices) > then you have provided that facility to everyone. Good guys generally have an existing security association with the device (if a bad guy has a security association with the box, we call it 0wn3d). Eliot --5NrCiCHSDVe6FJehsmE3lcAkW72L3rx8F-- --O3kh75vLitbb3Tx8NNWRVOU8XRLDagaOx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJZxUcPAAoJEIe2a0bZ0nozI0AH/3AXm2CZpO8SWJ+ZYmg+w98G TbkoXGmtzcuRkgvbLl6/3vBtYCTaOcglgrtd1tl4TkCK2mg9YvZxgLsZSNNQPWh/ MmOYT+HzuNP7h6IyArC3qEDt+UtVyEeYBjBlon64h9xqXb1Z6NwTSOXZ2EfwE9NI GsjSAsOwgnmJYIvBN5dMfmsrqxkF6vyHd4UxP+qgui4uIN9Ja2Br5hPrj8CkeHNg VfonasLSsx96b7V6Rk85gx/dN3bOvxN0skihsdzj0c+xpUEAxEoMyP4V57esEm9d LPq5Xq61nk4jR0/kLX0c5/fqJ5qkf1dM2vZFOfg8dAD5DNiHWahy36peayZqENo= =kp// -----END PGP SIGNATURE----- --O3kh75vLitbb3Tx8NNWRVOU8XRLDagaOx-- From nobody Fri Sep 22 13:53:30 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 717CC134535 for ; Fri, 22 Sep 2017 09:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Rxjv33habFP for ; Fri, 22 Sep 2017 09:24:47 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA12B134530 for ; Fri, 22 Sep 2017 09:24:45 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id r74so5397466wme.4 for ; Fri, 22 Sep 2017 09:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zgfibPyeGydfI1bIsTT0DssylYO2CNJ8CA58LkQpw+0=; b=qq4ME2wFD51JqqRR0JKKZu3w671JycQe7bFKoRJ95rNBIFogjGtvKOOYPez4BkMYce SLWqALpcoAmePXP+q1fnsEBhF/lSmLiWspUrKnFIKtAMtKpwMZS6w4B/OMMf3sNQvFbD WjA3o++P/GMmQc9pYQIFJLsEz8g0AZSlLpazQiZQkPUZfHIlZqolYD+g6mwie6eI4SRh nirEMRI0OmxfSAfArfOgHHxqA30p7+MWu+sk2AE2VrX9KoK4L62VvIfz/jEPdkZE5Hu/ ysajaQguAUIFuI8VTJRuVm/j+EF/d+AYPMaKQT1x2y6zFIdx3Uu+nvwtCmh0E2SqHX83 CsaA== 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=zgfibPyeGydfI1bIsTT0DssylYO2CNJ8CA58LkQpw+0=; b=RfiFwB1ZySw9sgjzDEhRF6PztrKveeoMsKNeUPfB5bnjfe5xKnymU8RcsFhySKjMS9 VEZ9/h8Ypu/CeQl4/e78zl17A8x1cLI4+v/JC9gZ+fPSrkTTrawTUCBGacs5CINWFE5X X4kOvjLSbKuEfNe03RlAG0/cvenKq9K4cQqPWXhFXO3oIFvgP52KNmQY4wmFf07Jb0qK Oz0g+hYPXXEIJo3aNQSbqMSidoRn56+FXV920S96spMS4GntnP5YLuJVrcbCR1RJcTer ogoGDDaCj7iQly4ahPMNYQ2k8scT9k553JAvoXl3WHaVZK6dkfw9we8PUZG7eSvCeKlm cJgg== X-Gm-Message-State: AHPjjUiW9TyZeu/gBjxSQiVtoWwmh5+FAujLLDdUxDKHIOIx2rFOyySb UYw/cFrIdvkZy8JkGiuWpBW1XUX+scJf5G8zh3mwrg== X-Google-Smtp-Source: AOwi7QAp63+QrnSxi4umpfCM/5h6lZL48C/e8rbHcvltvGZZb0ymYWIMjpsNMeph7vz2pBYi1yUXysfGS2I+lnClJ4I= X-Received: by 10.28.210.204 with SMTP id j195mr218535wmg.124.1506097483881; Fri, 22 Sep 2017 09:24:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Fri, 22 Sep 2017 09:24:02 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> From: Warren Kumari Date: Fri, 22 Sep 2017 12:24:02 -0400 Message-ID: To: Tony Finch Cc: Ted Hardie , doh@ietf.org, IETF Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 22 Sep 2017 13:53:29 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 16:24:48 -0000 On Fri, Sep 22, 2017 at 8:12 AM, Tony Finch wrote: > Ted Hardie wrote: > >> I think you're underestimating the value of a switch to a multiplexing >> facilitating protocol/transport. Once this has gotten its legs under it, I >> suspect that this approach for connecting to caching resolver will perform >> better than any of traditional upd/tcp connections or the tls/dtls >> approaches DPRIVE created. > > DNS over TCP already supports out-of-order responses. The reason it has > historically not performed very well is that server implementations have > handled queries on a TCP connection serially rather than concurrently. > > But this is improving. BIND 9.11 (for example) supports concurrent queries > with out-of-order responses over TCP and TCP fast open, so queries over > TCP should perform well, and better than UDP for large responses. > Yup -- RFC7766, S6.2.1.1 says you should do this, as does RFC7858 ("Specification for DNS over Transport Layer Security (TLS)"). So, these are only my personal views / no hats / etc, but to my mind one of the main reasons that I'd like to see Doh! succeed is for censorship resistance (in parallel with the dprive work). Currently plain-text DNS leaks a huge amount of privacy information; DPRIVE solves much of this, but one weakness is that it is still clearly DNS traffic[0]. This allows bad, evil, no-good totalitarian regimes to block it and force you to use resolvers under their control and so can control what you can reach, or watch where you are going and send the secret police to "re-educate" you if you are looking at things you shouldn't be. . . Now, reread the previous sentence with s/ bad, evil, no-good totalitarian regimes / friendly corporate IT folk / and s/ the secret police / human resources /. This allows friendly corporate IT folk to block it and force you to use resolvers which they control and so can contol what you can reach, or watch where you are going and send human resources to re-educate you if you are looking at things you shouldn't be. This is (I believe) what Elliot was pointing out -- this is important information for enterprises - it is used to limit liability, ensure employees are not "wasting time", and corporate security to detect that they need to re-image Bob's machine *again* because he persists in clicking questionable links and installing random bits of malware. Unfortunately you cannot separate case 1 from case 2 -- if you make it something that enterprise folk can detect / block (on BYOD devices) then you have provided that facility to everyone. I believe that this is simply the "encryption should be outlawed / backdoored because it helps ." argument in another guise[1]. If Doh! is done right in my view it should be indistinguishable from other web traffic and / or the collateral damage from blocking it would be (hopefully!) politically untenable. W [0]: either because it is using the domain-s ports (853) or through fingerprinting / heuristics of the TLS stream if you do something like just run it over port 443. [1]: luckily this isn't at all controversial, and isn't going to suck this thread down another rat-hole. > Tony. > -- > f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode > Faeroes, Southeast Iceland: Southeasterly 4 or 5, increasing 6 to gale 8 > later. Moderate or rough, occasionally very rough later. Showers, rain later. > Good, becoming moderate or poor later. > -- 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 Fri Sep 22 13:53:36 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C4F132D53 for ; Fri, 22 Sep 2017 12:48:23 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 qydvmhHbPnUX for ; Fri, 22 Sep 2017 12:48:22 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 E2F76132D18 for ; Fri, 22 Sep 2017 12:48:21 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id z39so1656263wrb.8 for ; Fri, 22 Sep 2017 12:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ztOBYbGPh/QZ7m6HC3QkFUJXhkPVyAdYXgJEOaLq1OU=; b=UOZp2s4grSeNtAwQQjH4VsNyxRCob1plM6SKGv8UnzgkoyxRX4EemxkaHgpJBiOw/b WfvWa+wrAN4CJLzaJDpTkOhrWV4P81IWsALpvTWGkvcAbCz/a9/SUIaDI25CV4yeKswG xZYW/7rZAlKb0plQgL86EaVHurMQtFGfmoxvbsdiIhIxUJwlJT6F3GEH5pHfQyiRau1s rnijovMCQRMLVfDY1Ti+iqwg+B8f0Kza+9DvqzQKMbAUjePhJbyvfK67wa/HphhOq94T Q5+gMCn7xqdcZ9fvaaWqKzJ0hrWTQWyQHieB9bmrmYTej5QulOvE3LN3Uyjm6D7MvKZC vvRA== 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=ztOBYbGPh/QZ7m6HC3QkFUJXhkPVyAdYXgJEOaLq1OU=; b=hRdkDnnAOWjOedvOFKJUNGUF7xFuw0AE4d69XP5RviLoiOtZKIu9UTxFIUF38tbWxO Tej7bOuGjyJtn291zL5tonpgVNuQbASmAdMIZdCzadgBcqLHnDYLC+HkObHPNLUJUINm 1AoTWTWklXYNlBsYdr5FBqgtR/9QK5hF7oduOcMqrZFVN2446aSg9A0C6AEOYSwwFLRO qrgMI20ORMwxeQRjRtBe50i9n0x7UxHG6Utnit0VPKBe70G4nZerMXpnLQ/BGixJRCC2 QE3DSckar7K5v9k4NwUKSHZfZQIrax/AbkmE3acByb+XnPjMn/byZ2RT4vnBe5+GYlXS aEBw== X-Gm-Message-State: AHPjjUj3MZWVaEsVUMM8MF2SSRUXAKks0P3A6jHThiaABzR9P2doCd3j tjoXdp71NQw1FZk5y/v4e8/wkBTO+3MRlk1gh7mzLg== X-Google-Smtp-Source: AOwi7QC/ELzLY5lPJPFWyk8wtS47R+QdTUx2G1gliyi9s2W6kJWbUW6pn19cKKUP5vGpDhntTlc+U7qB7qGXE1IIvoI= X-Received: by 10.223.177.211 with SMTP id r19mr205795wra.2.1506109700038; Fri, 22 Sep 2017 12:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Fri, 22 Sep 2017 12:47:39 -0700 (PDT) In-Reply-To: <0d059767-51eb-d583-1122-a11f4ba9a4aa@cisco.com> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <5e9cb711-d798-c6b9-d6c3-c7619bcbadd7@cisco.com> <2E3B3E8E-7C8D-4662-B5C8-D11C390EE5ED@mnot.net> <0d059767-51eb-d583-1122-a11f4ba9a4aa@cisco.com> From: Warren Kumari Date: Fri, 22 Sep 2017 15:47:39 -0400 Message-ID: To: Eliot Lear Cc: Tony Finch , Ted Hardie , doh@ietf.org, IETF Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 22 Sep 2017 13:53:29 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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, 22 Sep 2017 19:48:24 -0000 On Fri, Sep 22, 2017 at 1:23 PM, Eliot Lear wrote: > Hi Warren, > > Just a point of information: > > > On 9/22/17 6:24 PM, Warren Kumari wrote: >> Unfortunately you cannot separate case 1 from case 2 -- if you make it >> something that enterprise folk can detect / block (on BYOD devices) >> then you have provided that facility to everyone. > > Good guys generally have an existing security association with the > device (if a bad guy has a security association with the box, we call it > 0wn3d). Yes, and no (and why I specified BYOD) -- a number of enterprises allow employees to bring in personal phones / tablets / computers and use them on the corporate network... without requiring that they install a profile / place the devices under management -- I've lost the reference (I'd thought it was off the BYOD wikipedia page), but the number of organizations doing this was scary (to me!). Now, perhaps these same organizations don't currently monitor their employee usage through DNS... W > > Eliot > > -- 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 Mon Sep 25 07:58:03 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8EE1332D7; Mon, 25 Sep 2017 03:24:28 -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 eS7nFBeAnl8k; Mon, 25 Sep 2017 03:24:27 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDD213320C; Mon, 25 Sep 2017 03:24:27 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id u130so5745204oib.11; Mon, 25 Sep 2017 03:24:27 -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=WvAp0Rxs0sDtlxtMD/AYmNjiSQf1uICOcS1RhzLHHiA=; b=ukAvMFmPEOoNKQQlWnQcUh1TFuw75Lcqe1h/CI/YR0MXHkgZbGHSkqXtW+/o40Ty2d dQfiavbtUHOJIogHDuQWUlY2eA/XqMwO520BqmNySzdH4R8WdkHOyvjA7kor4cYy226u 5H7yfKNmYItBM7+ie/Xd0+NOMKhQRN3hnj2e0fBzkU8wPtOc5aBGStyY1kYLYAcclyfu +xRX436uGFWUb9Qu+UnKfoXfb9z1qzcex20EhCO/OEeYm5cerrDR6QHJHqIM3x3gr2HW 0H32bmaJt7hTjwDgjBB/qMvytm1K8h7VHDD/bm0zd1ISg6w2zRWSdjrAJDQFT8l+R+g5 UmNA== 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=WvAp0Rxs0sDtlxtMD/AYmNjiSQf1uICOcS1RhzLHHiA=; b=chaPLGVdLWptge4hamysSrjZUW3tErqJKRhWWoSbuwhBNg7VX2OJ/rePLLavEmPKhx YipvD28Xuc1yHdrISFAkb4zaJ0g/hihPn8uuoWvZyKrWIR9WxKMue//jQLJTH6aCf5nL HhQ6xsqUNHJ5ZXGpzmmqfypOMIOHjXwr/EnKNxrIbmMyFbd3Gk2Cp5yzdY9D2xqLzpm4 U9mfEA+/MOwJhonXV6wPtrTQrnl2qGmbtr8DHGLbJ6/Vubzs9Y+9IhU/xqEXRqgUEAiz VlGpZRIH6FDlvydZ43TSAzt+jR9fgmbHA2jjRDP2Im9DM26JWOXe028T/2xPPRF0aK1/ j8Pw== X-Gm-Message-State: AHPjjUhtnq7HIuilPwAHYTGvrUxUs+/2zB53AMkNHRWeodPspL94kJol VHr+WrxnAQMM2qV/6h8eLV9BMP+bzbJJSn3DNvI= X-Google-Smtp-Source: AOwi7QCx23b+fY/jqBg5nu5Nco1Py6F3kwsCSKY2OBL5TVVnpoNAIEqYiLk0SMsKm1OP+i9P4zxLWZg4yMijsQdhshs= X-Received: by 10.157.51.76 with SMTP id u12mr25384otd.113.1506335066560; Mon, 25 Sep 2017 03:24:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Mon, 25 Sep 2017 03:24:25 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Mon, 25 Sep 2017 20:24:25 +1000 Message-ID: To: Ted Hardie Cc: IETF , doh@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Mon, 25 Sep 2017 07:58:02 -0700 Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 10:24:29 -0000 (I apologize for not reading all 62 messages in this thread first before replying. Damned vacations.) On Sat, Sep 16, 2017 at 2:44 AM, Ted Hardie wrote: > I appreciate the charter's use of "HTTPS" as a signal that these are > intended to be TLS-protected HTTP sessions. I note, however, that there is > considerable ambiguity still present. HTTPS can mean HTTP 1.1 over TLS, > HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon (in some > deployments it already means that). I think that this is not just fine, but correct. I would object to a change. We should target HTTP, not a specific version of it. > While the working group may, of course, change that to > support HTTP 1.1 and/or QUIC, it might be useful for the charter to indicate > which of these is potentially in scope. I would assume, from the title, that it does not matter which of these protocols is used, therefore the HTTP working group is the primary point of collaboration. > If the community is sure now that > HTTP over QUIC is in scope, for example, having that noted in the charter by > adding the QUIC working group to list of working groups to consult would be > useful. If the QUIC working group produces something that is incapable of carrying HTTP semantics, then they have failed. Badly. Similarly, if this proposed working group produces a protocol that relies on semantics of a particular version of HTTP such that it cannot be used with QUIC, then they too have failed. I don't see any need to consult with QUIC specifically. I predict that we can use informal channels, since many of the same people will be in the two rooms. > [...] The working group could, of course, > change that, but it would seriously shift the direction of its input > document to do so). If we do that, then we are not meeting the charter as stated. >> Apr 2018 - [...] > > I admire the optimism in this. It was originally Dec 2017, so this is about 3 times as long. From nobody Mon Sep 25 15:56:10 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152E71345E1; Mon, 25 Sep 2017 15:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5pXLfwOU1sY; Mon, 25 Sep 2017 15:56:07 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB411345DF; Mon, 25 Sep 2017 15:56:06 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8PMu5wi067613 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Sep 2017 17:56:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: IETF Cc: doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> Date: Mon, 25 Sep 2017 17:56:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA26A737521FBF11CDD570BA" Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 22:56:09 -0000 This is a multi-part message in MIME format. --------------EA26A737521FBF11CDD570BA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thanks to everyone who commented on the proposed charter for DNS-over-HTTPS. I have noted four main categories of discussion: 1. Whether to rule specific versions of HTTP in or out of scope of the charter.  While the consensus here was rough, there were more proponents of leaving the version out than baking it in. I further observe that leaving version out of the charter does not preclude the WG from reaching consensus that requires or precludes certain versions from being used. 2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough, but I find slightly more people in favor of allowing discovery than those opposed to its inclusion. I will be adding language to the charter proposal that allows such work if those parties interested in specifying such mechanisms show up in the working group. If no such critical mass shows up, the WG will be allowed to close without performing such specification. 3. Scope of work: whether DNS-over-HTTPS servers are accessed normal stub resolver libraries or via JavaScript. The proposed charter now contains text clarifying that the JavaScript use case is not the primary motivation, but that the WG will not take steps to preclude it. 4. Regarding the question of whether to perform the work at all (or whether to perform the work now): the analysis for starting a working group generally hinges on whether a viable group of willing and capable participants exists to complete such work, without regard to those who wish the work not to take place. While exceptions to this generality may certainly exist, I find no reason the proposed working group is special in this dimension. The revised version of the proposed charter can now be found at: https://datatracker.ietf.org/doc/charter-ietf-doh/ /a --------------EA26A737521FBF11CDD570BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks to everyone who commented on the proposed charter for DNS-over-HTTPS. I have noted four main categories of discussion:

  1. Whether to rule specific versions of HTTP in or out of scope of the charter.  While the consensus here was rough, there were more proponents of leaving the version out than baking it in. I further observe that leaving version out of the charter does not preclude the WG from reaching consensus that requires or precludes certain versions from being used.

  2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough, but I find slightly more people in favor of allowing discovery than those opposed to its inclusion. I will be adding language to the charter proposal that allows such work if those parties interested in specifying such mechanisms show up in the working group. If no such critical mass shows up, the WG will be allowed to close without performing such specification.

  3. Scope of work: whether DNS-over-HTTPS servers are accessed normal stub resolver libraries or via JavaScript. The proposed charter now contains text clarifying that the JavaScript use case is not the primary motivation, but that the WG will not take steps to preclude it.

  4. Regarding the question of whether to perform the work at all (or whether to perform the work now): the analysis for starting a working group generally hinges on whether a viable group of willing and capable participants exists to complete such work, without regard to those who wish the work not to take place. While exceptions to this generality may certainly exist, I find no reason the proposed working group is special in this dimension.

The revised version of the proposed charter can now be found at:

https://datatracker.ietf.org/doc/charter-ietf-doh/

/a

--------------EA26A737521FBF11CDD570BA-- From nobody Mon Sep 25 16:03:42 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A052F1345DB; Mon, 25 Sep 2017 16:03:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sr0WcguEduay; Mon, 25 Sep 2017 16:03:32 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 58CA6132697; Mon, 25 Sep 2017 16:03:32 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id a128so8387072qkc.5; Mon, 25 Sep 2017 16:03:32 -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=BcLusH/GP5YxnfuF+thc+JvFtD8tf18dDdL19/rY6b0=; b=LvuddKT9T26I1L1ikCuMlgX9rl+L4vyERqPf/pfyxp30azCqCqR0so0YIexowj9opG QQZG66NhZb5OgPu7qYC3AJxDFYt3lEswvBiJEMoWCmauDc1HCWdJzv+ihSMtTZo41lxH MDJ2TArxs4cd+z1WIj12fBZZUSQhTPUsxGjjhK/HSLpmlGcXjhjrGkQ7YkK4KJRWtz6A TgfcNoiTIXD5+lY+812idUbZ0hGT7PB3wXivhEHw+LF8GsC3WLitJZ8aY9Aq8esqpN9a S2xnj6D4tAK/HSHKi9KJFvGon7W04w51GyR1WXaw7KV1TseH3XfFSs3+JxE2rGYdX2Wx Ey6g== 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=BcLusH/GP5YxnfuF+thc+JvFtD8tf18dDdL19/rY6b0=; b=sbrF9BkpY2In5wsqlIKQqmEPFx+IvqLdDoJQfmRsKD2hj67TFY6f6YZGN9tBsr+a0b rqzk2tYffvOCM50GW0MwGP842Vz9J1KcKPYToZynBXQvewcPyuIh8HHtpdqo5vgdHXmC 3oZZnUNVyY/OEstrAmPAzPrZY7Q9sZRv+o/fUPT9w4w09WoQrmYpbST6a9h7ojNJIXGU 7ENJymmJzQSTrIe/47Mfduriwm+MBsWnTuXvoCzhmAvhl+flSNY1neRrayb8xdPdy/ZV s3+KUoE7EzV2MEYrMUQb0jNPXS9ZAmC4u2zYfQPXmkU4iZ0q3ZEXryljkFP49nyt9LkK bLug== X-Gm-Message-State: AHPjjUgNWn5XGOSAXJ71TsWEpOk6aA6X4SaKtkk0XQEkBhdWeRP08SIM WhK3m6KRfKo6lQB4jeSFIKh2Swnu93a6JUXLAb4RFA== X-Google-Smtp-Source: AOwi7QAkvmXWmV/wHkUFv5kGkhLZHedMIpVDMdvPnhqx+zoy/VtW4dk4SlWHbKi/QCtbzKqFH2EFYWoLMPmiCKJi2wU= X-Received: by 10.55.159.130 with SMTP id i124mr12756504qke.339.1506380611294; Mon, 25 Sep 2017 16:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.27.42 with HTTP; Mon, 25 Sep 2017 16:03:00 -0700 (PDT) In-Reply-To: <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> From: Ted Hardie Date: Mon, 25 Sep 2017 16:03:00 -0700 Message-ID: To: Adam Roach Cc: IETF , doh@ietf.org Content-Type: multipart/alternative; boundary="001a114d38ee3b995f055a0b9112" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 23:03:35 -0000 --001a114d38ee3b995f055a0b9112 Content-Type: text/plain; charset="UTF-8" Adam, Thanks for summarizing the discussion and its outcomes. Looking at the revised charter, I noticed that it currently says "The use of HTTPS and its existing PKI provides integrity and confidentiality, and it also allows the transport to interoperate with common HTTPS infrastructure and policy." The choice not to specify a particular version means that there may be more than one transport. You may wish to rephrase this or elide it to reflect the decision taken on that point. regards, Ted On Mon, Sep 25, 2017 at 3:56 PM, Adam Roach wrote: > Thanks to everyone who commented on the proposed charter for > DNS-over-HTTPS. I have noted four main categories of discussion: > > > 1. Whether to rule specific versions of HTTP in or out of scope of the > charter. While the consensus here was rough, there were more proponents of > leaving the version out than baking it in. I further observe that leaving > version out of the charter does not preclude the WG from reaching consensus > that requires or precludes certain versions from being used. > > 2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough, > but I find slightly more people in favor of allowing discovery than those > opposed to its inclusion. I will be adding language to the charter proposal > that allows such work if those parties interested in specifying such > mechanisms show up in the working group. If no such critical mass shows up, > the WG will be allowed to close without performing such specification. > > 3. Scope of work: whether DNS-over-HTTPS servers are accessed normal > stub resolver libraries or via JavaScript. The proposed charter now > contains text clarifying that the JavaScript use case is not the primary > motivation, but that the WG will not take steps to preclude it. > > 4. Regarding the question of whether to perform the work at all (or > whether to perform the work now): the analysis for starting a working group > generally hinges on whether a viable group of willing and capable > participants exists to complete such work, without regard to those who wish > the work not to take place. While exceptions to this generality may > certainly exist, I find no reason the proposed working group is special in > this dimension. > > The revised version of the proposed charter can now be found at: > > https://datatracker.ietf.org/doc/charter-ietf-doh/ > > /a > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --001a114d38ee3b995f055a0b9112 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Adam,

Thanks for summarizing t= he discussion and its outcomes.=C2=A0 Looking at the revised charter, I not= iced that it currently says "The use of HTTPS and its existing PKI pro= vides integrity and confidentiality, and it also allows the transport to in= teroperate with common HTTPS infrastructure and policy."=C2=A0 The cho= ice not to specify a particular version means that there may be more than o= ne transport.=C2=A0 You may wish to rephrase this or elide it to reflect th= e decision taken on that point.

regards,

Ted
<= div>


On Mon, Sep 25, 2017 at 3:56 PM, Adam Roach <adam@= nostrum.com> wrote:
=20 =20 =20
Thanks to everyone who commented on the proposed charter for DNS-over-HTTPS. I have noted four main categories of discussion:

  1. Whether to rule specific versions of HTTP in or out of scope of the charter.=C2=A0 While the consensus here was rough, there wer= e more proponents of leaving the version out than baking it in. I further observe that leaving version out of the charter does not preclude the WG from reaching consensus that requires or precludes certain versions from being used.

  2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough, but I find slightly more people in favor of allowing discovery than those opposed to its inclusion. I will be adding language to the charter proposal that allows such work if those parties interested in specifying such mechanisms show up in the working group. If no such critical mass shows up, the WG will be allowed to close without performing such specification.

  3. Scope of work: whether DNS-over-HTTPS servers are accessed normal stub resolver libraries or via JavaScript. The proposed charter now contains text clarifying that the JavaScript use case is not the primary motivation, but that the WG will not take steps to preclude it.

  4. Regarding the question of whether to perform the work at all (or whether to perform the work now): the analysis for starting a working group generally hinges on whether a viable group of willing and capable participants exists to complete such work, without regard to those who wish the work not to take place. While exceptions to this generality may certainly exist, I find no reason the proposed working group is special in this dimension.

The revised version of the proposed charter can now be found at:

https://= datatracker.ietf.org/doc/charter-ietf-doh/<= font color=3D"#888888">

/a


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


--001a114d38ee3b995f055a0b9112-- From nobody Mon Sep 25 16:12:04 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3913A1345E4; Mon, 25 Sep 2017 16:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjPiKWaqQrNd; Mon, 25 Sep 2017 16:11:56 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5CB1345EB; Mon, 25 Sep 2017 16:11:56 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8PNBrFc070283 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Sep 2017 18:11:54 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ted Hardie Cc: IETF , doh@ietf.org References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> From: Adam Roach Message-ID: Date: Mon, 25 Sep 2017 18:11:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 23:11:57 -0000 On 9/25/17 6:03 PM, Ted Hardie wrote: > Thanks for summarizing the discussion and its outcomes.  Looking at > the revised charter, I noticed that it currently says "The use of > HTTPS and its existing PKI provides integrity and confidentiality, and > it also allows the transport to interoperate with common HTTPS > infrastructure and policy."  The choice not to specify a particular > version means that there may be more than one transport.  You may wish > to rephrase this or elide it to reflect the decision taken on that point. Thanks. I've tweaked it to read: "...and it also allows interoperation with common HTTPS infrastructure and policy." /a From nobody Mon Sep 25 16:16:41 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368761345E5; Mon, 25 Sep 2017 16:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FugaduXimVR; Mon, 25 Sep 2017 16:16:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71B591344FF; Mon, 25 Sep 2017 16:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2F4E4BE24; Tue, 26 Sep 2017 00:16:29 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbgHIESOjYcT; Tue, 26 Sep 2017 00:16:27 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4C570BDCC; Tue, 26 Sep 2017 00:16:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506381387; bh=Zt+83i2vsGiwrnUixXew2TkeBBBleQrInjWQ86h+Bzg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Ju6j0+0JoNXarTbBJrH9OxvKOBf8q5vhC7dg9zeggZJAwnFukXlrn6N5H3mO2oINW iXAilk1qFRrHoYEK7Jv8yfRLVZj3LjA331AsYi++4ZIjuFAgGYEUKLetCgzcwN6v8+ ItK4iYSgs4/SEdRKe140ykmD9WVEp4YzgBub9Bvw= To: Adam Roach Cc: Ted Hardie , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> Date: Tue, 26 Sep 2017 00:16:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qWcEgPpHh3713OLr4I1O1M6NBQLEgw7Mu" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 23:16:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qWcEgPpHh3713OLr4I1O1M6NBQLEgw7Mu Content-Type: multipart/mixed; boundary="QWN8DtGhOQpcm7EJGSXQV0b3JU9HLqWUq"; protected-headers="v1" From: Stephen Farrell To: Adam Roach Cc: Ted Hardie , doh@ietf.org, IETF Message-ID: <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> In-Reply-To: --QWN8DtGhOQpcm7EJGSXQV0b3JU9HLqWUq Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable A nit, a question and a comment: On 26/09/17 00:03, Ted Hardie wrote: > Adam, >=20 > Thanks for summarizing the discussion and its outcomes. Looking at the= > revised charter, I noticed that it currently says "The use of HTTPS and= its > existing PKI provides integrity and confidentiality, and it also allows= the > transport to interoperate with common HTTPS infrastructure and policy."= Nit: Not sure if it's worth nothing, but the integrity service here is different from DNSSEC, and clients need to be cognizant of that. Probably obvious though. > The choice not to specify a particular version means that there may be = more > than one transport. You may wish to rephrase this or elide it to refle= ct > the decision taken on that point. This para: " While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The Working Group will not engage in such preventative design. " =2E.. strikes me as weird, given that it didn't say what is the "primary" use-case. I think that needs fixing or may cause confusion later. The question is: did I miss where you said what was the primary use-case? The comment: I find this version no better than the last in terms of saying that the WG needs to consider the scope within which DNS answers are used. And that was my major issue with the last iteration, so overall, this version doesn't seem that much better to me. My suggestion is to add text along these lines: "The WG will analyse the security and privacy issues that could arise from accessing DNS in this manner. For example it'd clearly be bad if JavaScript from random web sites could poison the OS's DNS cache (though hopefully no implementation would allow that). The manner in which that analysis is documented will be decided by the WG." Cheers, S. >=20 > regards, >=20 > Ted >=20 >=20 >=20 > On Mon, Sep 25, 2017 at 3:56 PM, Adam Roach wrote: >=20 >> Thanks to everyone who commented on the proposed charter for >> DNS-over-HTTPS. I have noted four main categories of discussion: >> >> >> 1. Whether to rule specific versions of HTTP in or out of scope of = the >> charter. While the consensus here was rough, there were more propo= nents of >> leaving the version out than baking it in. I further observe that l= eaving >> version out of the charter does not preclude the WG from reaching c= onsensus >> that requires or precludes certain versions from being used. >> >> 2. Discovery of DNS-over-HTTPS servers. Again, consensus was rough,= >> but I find slightly more people in favor of allowing discovery than= those >> opposed to its inclusion. I will be adding language to the charter = proposal >> that allows such work if those parties interested in specifying suc= h >> mechanisms show up in the working group. If no such critical mass s= hows up, >> the WG will be allowed to close without performing such specificati= on. >> >> 3. Scope of work: whether DNS-over-HTTPS servers are accessed norma= l >> stub resolver libraries or via JavaScript. The proposed charter now= >> contains text clarifying that the JavaScript use case is not the pr= imary >> motivation, but that the WG will not take steps to preclude it. >> >> 4. Regarding the question of whether to perform the work at all (or= >> whether to perform the work now): the analysis for starting a worki= ng group >> generally hinges on whether a viable group of willing and capable >> participants exists to complete such work, without regard to those = who wish >> the work not to take place. While exceptions to this generality may= >> certainly exist, I find no reason the proposed working group is spe= cial in >> this dimension. >> >> The revised version of the proposed charter can now be found at: >> >> https://datatracker.ietf.org/doc/charter-ietf-doh/ >> >> /a >> >> _______________________________________________ >> Doh mailing list >> Doh@ietf.org >> https://www.ietf.org/mailman/listinfo/doh >> >> >=20 --QWN8DtGhOQpcm7EJGSXQV0b3JU9HLqWUq-- --qWcEgPpHh3713OLr4I1O1M6NBQLEgw7Mu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZyY5KAAoJEC88hzaAX42i/BgH/2yBa28j6fwdt0VneBDMVtVP 2VosnQMvheXIwIKZS+WLQDD5Bx1ct65/w7sZoPITpDYuJJA/uNJeEgR5/CJHqxFk r8hrY4w8l53NXV8vsPikuj8ZMXYXM5/TmtV9apUKZ29nwsEwm9N4qQEnv6ZIbbeV SEmc183Jxff92gVmvnrIZ88giOd7YEq9Ov4Yr5grBE04GhnHopV2QGN1vJB1kuD4 xzc7DynAx5x9+5tmkwc/Eyeq72YpgnzjMA5ZegKD6CShm0VdpiY6f3XksxXUaPvL B+H4R3GgriSU6obA3beucTJJYTiOgzqivJFQLI8SLH82OYFyM3axUSIswTakbVg= =kaGZ -----END PGP SIGNATURE----- --qWcEgPpHh3713OLr4I1O1M6NBQLEgw7Mu-- From nobody Mon Sep 25 16:38:41 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554B91345FB; Mon, 25 Sep 2017 16:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_VcE1QtttMo; Mon, 25 Sep 2017 16:38:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15255132355; Mon, 25 Sep 2017 16:38:38 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8PNcVTF074661 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Sep 2017 18:38:32 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Stephen Farrell Cc: Ted Hardie , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> From: Adam Roach Message-ID: <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> Date: Mon, 25 Sep 2017 18:38:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 23:38:39 -0000 On 9/25/17 6:16 PM, Stephen Farrell wrote: > A nit, a question and a comment: > > On 26/09/17 00:03, Ted Hardie wrote: >> Adam, >> >> Thanks for summarizing the discussion and its outcomes. Looking at the >> revised charter, I noticed that it currently says "The use of HTTPS and its >> existing PKI provides integrity and confidentiality, and it also allows the >> transport to interoperate with common HTTPS infrastructure and policy." > Nit: Not sure if it's worth nothing, but the integrity service here > is different from DNSSEC, and clients need to be cognizant of that. > Probably obvious though. It's not different; it's in addition to. The mechanism being described would pass DNSSEC information through unscathed. > >> The choice not to specify a particular version means that there may be more >> than one transport. You may wish to rephrase this or elide it to reflect >> the decision taken on that point. > This para: > > " > While access to DNS-over-HTTPS servers from JavaScript running > in a typical web browser is not the primary use case for this > work, precluding the ability to do so would require additional > preventative design. The Working Group will not engage in such > preventative design. > " > > ... strikes me as weird, given that it didn't say what is the > "primary" use-case. I think that needs fixing or may cause > confusion later. The question is: did I miss where you said what > was the primary use-case? It's pretty similar to DPRIVE (or, really, DNS in general). I see that DPRIVE does have some text that seems to serve the purpose, so I'll copy it over with minor tweaks like so: > The primary focus of this Working Group is to develop a mechanism that > provides confidentiality and connectivity between DNS Clients and > Iterative > Resolvers.  While access to DNS-over-HTTPS servers from JavaScript > running in > a typical web browser is not the primary use case for this work, > precluding > the ability to do so would require additional preventative design. The > Working > Group will not engage in such preventative design. > The comment: I find this version no better than the last in > terms of saying that the WG needs to consider the scope within > which DNS answers are used. And that was my major issue with > the last iteration, so overall, this version doesn't seem that > much better to me. My suggestion is to add text along these > lines: > > "The WG will analyse the security and privacy issues that could > arise from accessing DNS in this manner. For example it'd clearly > be bad if JavaScript from random web sites could poison the OS's > DNS cache (though hopefully no implementation would allow that). > The manner in which that analysis is documented will be decided > by the WG." What I'm seeing here is that the IETF isn't going to propose any changes to the web security model. In most cases, I think this goes without saying; but since you and Ted have both raised the issue, I suppose it bears mention in the charter. I've tweaked your phrasing a bit: > The Working Group will analyze the security and privacy issues that could > arise from accessing DNS over HTTPS. In particular, the Working Group will > ensure that access to DNS information from a JavaScript context will > not have > adverse impact on the host operating system's DNS cache. The manner in > which > such analysis is performed will be decided by the working group. /a From nobody Mon Sep 25 16:49:43 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AC7134607; Mon, 25 Sep 2017 16:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxb-JPZlawC4; Mon, 25 Sep 2017 16:49:34 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9155213460C; Mon, 25 Sep 2017 16:49:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24E34BE2E; Tue, 26 Sep 2017 00:49:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfRtiFE-6UQ0; Tue, 26 Sep 2017 00:49:30 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 768BEBE24; Tue, 26 Sep 2017 00:49:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506383370; bh=DU9Z6Bdu++1Oj6e+0YFLtdLvZ7me/OWBdQBE9YV2pJw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=M1f75y5e79uOFD7+/S57eGzAXI3HYS95OjIsBfEt29bHcUKZgRDfinc2bhMhZxaLZ zY1utgpKeuysT3GhzNepulLb72WyXV0txPzhCFNhXCiuE6ZOVvGAWU29LoS+k4lEl3 9BSvyF1srsX+99X6dth3LK6cGOR4OfwigHKJsiCQ= To: Adam Roach Cc: Ted Hardie , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> Date: Tue, 26 Sep 2017 00:49:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RlQdSXgmLoWMNsXCsuMp64JEV1CVPDh5A" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Mon, 25 Sep 2017 23:49:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RlQdSXgmLoWMNsXCsuMp64JEV1CVPDh5A Content-Type: multipart/mixed; boundary="xfIik5SMLDLS59t8U7ebsJNhQnc25W3kE"; protected-headers="v1" From: Stephen Farrell To: Adam Roach Cc: Ted Hardie , doh@ietf.org, IETF Message-ID: <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> In-Reply-To: <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> --xfIik5SMLDLS59t8U7ebsJNhQnc25W3kE Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Hiya, On 26/09/17 00:38, Adam Roach wrote: > On 9/25/17 6:16 PM, Stephen Farrell wrote: >> A nit, a question and a comment: >> >> On 26/09/17 00:03, Ted Hardie wrote: >>> Adam, >>> >>> Thanks for summarizing the discussion and its outcomes.=C2=A0 Looking= at the >>> revised charter, I noticed that it currently says "The use of HTTPS >>> and its >>> existing PKI provides integrity and confidentiality, and it also >>> allows the >>> transport to interoperate with common HTTPS infrastructure and policy= =2E" >> Nit: Not sure if it's worth nothing, but the integrity service here >> is different from DNSSEC, and clients need to be cognizant of that. >> Probably obvious though. >=20 > It's not different; it's in addition to. The mechanism being described > would pass DNSSEC information through unscathed. Again, it's a nit, but I've not clue what "not different" in the above means. (Since DNSSEC is different:-) >=20 >> >>> The choice not to specify a particular version means that there may >>> be more >>> than one transport.=C2=A0 You may wish to rephrase this or elide it t= o >>> reflect >>> the decision taken on that point. >> This para: >> >> " >> While access to DNS-over-HTTPS servers from JavaScript running >> in a typical web browser is not the primary use case for this >> work, precluding the ability to do so would require additional >> preventative design. The Working Group will not engage in such >> preventative design. >> " >> >> ... strikes me as weird, given that it didn't say what is the >> "primary" use-case. I think that needs fixing or may cause >> confusion later. The question is: did I miss where you said what >> was the primary use-case? >=20 > It's pretty similar to DPRIVE (or, really, DNS in general). I see that > DPRIVE does have some text that seems to serve the purpose, so I'll cop= y > it over with minor tweaks like so: >=20 >> The primary focus of this Working Group is to develop a mechanism that= >> provides confidentiality and connectivity between DNS Clients and >> Iterative >> Resolvers.=C3=82=C2=A0 While access to DNS-over-HTTPS servers from Jav= aScript >> running in >> a typical web browser is not the primary use case for this work, >> precluding >> the ability to do so would require additional preventative design. The= >> Working >> Group will not engage in such preventative design. >=20 >=20 I'm fine with that. I'll be interested to see if others are also. >=20 >=20 >> The comment: I find this version no better than the last in >> terms of saying that the WG needs to consider the scope within >> which DNS answers are used. And that was my major issue with >> the last iteration, so overall, this version doesn't seem that >> much better to me. My suggestion is to add text along these >> lines: >> >> "The WG will analyse the security and privacy issues that could >> arise from accessing DNS in this manner. For example it'd clearly >> be bad if JavaScript from random web sites could poison the OS's >> DNS cache (though hopefully no implementation would allow that). >> The manner in which that analysis is documented will be decided >> by the WG." >=20 > What I'm seeing here is that the IETF isn't going to propose any change= s > to the web security model. In most cases, I think this goes without > saying; but since you and Ted have both raised the issue, I suppose it > bears mention in the charter. I've tweaked your phrasing a bit: >=20 >> The Working Group will analyze the security and privacy issues that co= uld >> arise from accessing DNS over HTTPS. In particular, the Working Group >> will >> ensure that access to DNS information from a JavaScript context will >> not have >> adverse impact on the host operating system's DNS cache. The manner in= >> which >> such analysis is performed will be decided by the working group. >=20 I'd be just about ok with that. My problems with your rephrasing are: - I'm not sure the WG can "ensure" a lack of adverse impact, so why make it a requirement, if it's not possible? - Pollution of the OS's cache may not be the only bad thing that can happen, so that needs to be an example. - I'm fine that a WG decide how to document stuff, but saying they can decide the manner in which such analysis is performed seems to me like you could drive a giant cart and horses- galore through that loophole, and that phrasing seems to nearly invite that, and I've seen WGs do just that kind of thing. I'd like that you or some other AD could ask to be pointed at the analysis results and for those to at minimum need a WG-list thread, so saying "do the work, document it however you like" seems like a better plan to me. Cheers, S. > /a >=20 >=20 --xfIik5SMLDLS59t8U7ebsJNhQnc25W3kE-- --RlQdSXgmLoWMNsXCsuMp64JEV1CVPDh5A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZyZYJAAoJEC88hzaAX42iW1UIALx2wUSC7fkd4Iln5clCbSWB CgDlJ8hqbYied6QKfEhiTz2AbTnWJQzq0TjNKK68M/rxWil1C/vf9T8wJVuouJVa ds5zYhyQaIQIHKegS6RpXDJjBPEQ1ZsOpN8q4MlGXdQA+r63F9dekCFgh2DVWBoK D0H2vi3RKJJ1ezX80QQGz3vN4twCY1vDDl0HuUOmOnrRAqHHw3LmwlGvZWo2Hbd4 VENjPg83WQlxSHwIE3TjgkM6TL9njbci2DN3jixDAh0gQv+ELUjN8r2p/jpeUpOj nOjhH1lU0xpAIxqnckHTMorVMoHSpv+pimR9HlsADJoVQ/8VP+8Ys0MKWlOHsDs= =9TQY -----END PGP SIGNATURE----- --RlQdSXgmLoWMNsXCsuMp64JEV1CVPDh5A-- From nobody Mon Sep 25 17:04:45 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5732813460B; Mon, 25 Sep 2017 17:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 9hNeRrqnWw7D; Mon, 25 Sep 2017 17:04:41 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8551321A4; Mon, 25 Sep 2017 17:04:41 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id p126so9525049oih.9; Mon, 25 Sep 2017 17:04:41 -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=YB3Mxff3Xe+mwMDRNK9zF7+etaTBlJgTNocN/YkZa/Y=; b=BXUEGNDkmCFcOFQYEnXth6zYMQE0aBRZ8S9GsHK8eOqtUMwzwzTqux/4scJZSA2pT+ Ou0waBu5FNQjPMcXV4vOXWIgDK11T7zQGSwnsQCqYLBz3L9efP2hnYNh8SFhRtlRBLDN IuDN6m4jwKZdNbgzGIFaSxlsscAFW0XaIj3g0Njn1L5rsOUaqTZ1s9okYs0abU7r0ASN 8/j79CgAdEG3WmrtY1tU+x2g5p3deHE255CF2mcwWEAksld1kzV5vv7Np8ZpAPeRUBDH zDIUgUI3r1wcZ9U6mFfffXcET6TxtbmRXpfDe7hQcOJzWJxDuiV4/73SwCrfKGHV7u5E XfBA== 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=YB3Mxff3Xe+mwMDRNK9zF7+etaTBlJgTNocN/YkZa/Y=; b=DA5LH1h9SQd4yKCvUYLJCoLEvQzVATmL6LRg2rDPnw1xCW41UKwqN2FeZAL5DcvDas aQIE0NjzX6woL+mr4pylyOPq77m9cQNm/6W/49zr07yqqzXUQRpljnGHTbp1znrpchHw sLwXQK8o2ZCqyg+9JWHLGglzSxGANu3O5W7T8eqqX9ECwIf8abfI1jZ7eCZUHrjXSVYi Tx+Ca0+Pxla/SFFrp8o6blqISo0o8782/X2bZYjKoGkgjdDjTRSITW9d/6DFnE/8Odn8 iTBW3XWjg7tDANP0T7SjeRxlu0vttQWHE10/JBcNu++Zrxj0mqzuYo7F8+9SLB5cQ5wp qGGg== X-Gm-Message-State: AHPjjUhpqQGw0dTZCg1vNDGFkyfkcTj3qbhpyOy0xcpHyHhWf4GtK8ZO TyNFxlEcCUEv+nINhg58nho1K1/mywRhd+5Wa/g= X-Google-Smtp-Source: AOwi7QBPMWR8SmZYsvxsbw50zGoMB9/gZIc37I9QYs4duL5y3IQCCYAVgn/fL/VVABkRZ1O8AvxYQ95EQ4iSGKUJrTQ= X-Received: by 10.202.170.204 with SMTP id t195mr10954098oie.277.1506384280932; Mon, 25 Sep 2017 17:04:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Mon, 25 Sep 2017 17:04:39 -0700 (PDT) In-Reply-To: <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> From: Martin Thomson Date: Tue, 26 Sep 2017 10:04:39 +1000 Message-ID: To: Stephen Farrell Cc: Adam Roach , Ted Hardie , doh@ietf.org, IETF Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 26 Sep 2017 00:04:43 -0000 On Tue, Sep 26, 2017 at 9:49 AM, Stephen Farrell wrote: > On 26/09/17 00:38, Adam Roach wrote: >>> The Working Group will analyze the security and privacy issues that could >>> arise from accessing DNS over HTTPS. In particular, the Working Group >>> will >>> ensure that access to DNS information from a JavaScript context will >>> not have >>> adverse impact on the host operating system's DNS cache. The manner in >>> which >>> such analysis is performed will be decided by the working group. >> > > I'd be just about ok with that. My problems with your rephrasing > are: > > - I'm not sure the WG can "ensure" a lack of adverse impact, so > why make it a requirement, if it's not possible? > > - Pollution of the OS's cache may not be the only bad thing that > can happen, so that needs to be an example. > > - I'm fine that a WG decide how to document stuff, but saying > they can decide the manner in which such analysis is performed > seems to me like you could drive a giant cart and horses- > galore through that loophole, and that phrasing seems to > nearly invite that, and I've seen WGs do just that kind of > thing. I'd like that you or some other AD could ask to be > pointed at the analysis results and for those to at minimum > need a WG-list thread, so saying "do the work, document it > however you like" seems like a better plan to me. How about just: The Working Group will analyze the security and privacy issues that could arise from accessing DNS over HTTPS. In particular, the Working Group will consider the interaction of DNS and HTTP caching. I don't think that we need the JS piece in there. There are special concerns there, but I think that we're all enough aware of those concerns that we can reach a conclusion of sorts in the working group. From nobody Mon Sep 25 17:06:17 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD37134614; Mon, 25 Sep 2017 17:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uy1aXKQp8hut; Mon, 25 Sep 2017 17:06:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A845F13232C; Mon, 25 Sep 2017 17:06:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7FF71BE2E; Tue, 26 Sep 2017 01:06:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVTCwCfJNlAQ; Tue, 26 Sep 2017 01:06:03 +0100 (IST) Received: from [10.244.2.100] (unknown [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 34D81BE24; Tue, 26 Sep 2017 01:06:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1506384363; bh=8hVS5fkC9SuuEfXYKQD8uaN48E8YYXLqMqwMUHW5/zg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FJ49W9jxruZjK4W3UwDsdBmJVC9jylU/BKszCsFRpUSjTA8J6wEITiAvY1zC14/dc tzfbMTIOpPrtcaiUdp7NAdIWIfk2C7ibhXYUziFyOgK8HgvYdkQ0pIshEZ+QmYlbx6 3i7M4b1tmg/s+DQlz9JWXl+b1B7ByqNgoaU1X8EY= To: Martin Thomson Cc: Adam Roach , Ted Hardie , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <1982a9a7-85ee-21d2-e0cf-a8efbfee8e15@cs.tcd.ie> Date: Tue, 26 Sep 2017 01:06:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OWDRXEUuBu9gLq6wQGQoqtDmDexBtr27A" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 26 Sep 2017 00:06:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OWDRXEUuBu9gLq6wQGQoqtDmDexBtr27A Content-Type: multipart/mixed; boundary="HHPIS0StVDKlB3JE8WfxtOjmkQ8qMQXdO"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson Cc: Adam Roach , Ted Hardie , doh@ietf.org, IETF Message-ID: <1982a9a7-85ee-21d2-e0cf-a8efbfee8e15@cs.tcd.ie> Subject: Re: [Doh] WG Review: DNS Over HTTPS (doh) References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> In-Reply-To: --HHPIS0StVDKlB3JE8WfxtOjmkQ8qMQXdO Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 26/09/17 01:04, Martin Thomson wrote: > The Working Group will analyze the security and privacy issues that > could arise from accessing DNS over HTTPS. In particular, the Working > Group will consider the interaction of DNS and HTTP caching. Yep, that's better than my earlier suggestion. S. --HHPIS0StVDKlB3JE8WfxtOjmkQ8qMQXdO-- --OWDRXEUuBu9gLq6wQGQoqtDmDexBtr27A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZyZnqAAoJEC88hzaAX42ibh4H/igxYX/Na81ZtzwQ7GsVqodY nSIqqqvTROYZL92ESmAVpHlk0CD6ZTna8dY/gmK5bFkKR9/aCWPm47FZgr2wsdE7 6OaOJzYwpMtzLH/VWC+rkWJ431DAGgZlSik7aH4V2upRiCQSCEi7Lbl42G3hqXgd spfVVKPRwxW5baNUSGdllzlrUX+5lJMzN8fzLGhrHiGFUNs1h1A+lZ/GkWbI8LA0 6neHoR6MHCwFysJPVvGB9EIbgemz1n4fFNp59jd+3BNc52Co5c5cm2vqLnjm8iwU 65AjDM+ekfZUWnYhdQu+qUlYtJXMu819cDMnVf8IzWipqeTV79pd3XxaStdtKOg= =RQ42 -----END PGP SIGNATURE----- --OWDRXEUuBu9gLq6wQGQoqtDmDexBtr27A-- From nobody Mon Sep 25 17:50:21 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D45C132D4E; Mon, 25 Sep 2017 17:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PkAIZxUKxwV3; Mon, 25 Sep 2017 17:50:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118DD13462F; Mon, 25 Sep 2017 17:50:13 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8Q0o5Gt086784 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 25 Sep 2017 19:50:06 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Stephen Farrell , Martin Thomson Cc: Ted Hardie , doh@ietf.org, IETF References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> <1982a9a7-85ee-21d2-e0cf-a8efbfee8e15@cs.tcd.ie> From: Adam Roach Message-ID: Date: Mon, 25 Sep 2017 19:50:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1982a9a7-85ee-21d2-e0cf-a8efbfee8e15@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 26 Sep 2017 00:50:14 -0000 On 9/25/17 7:06 PM, Stephen Farrell wrote: > > On 26/09/17 01:04, Martin Thomson wrote: >> The Working Group will analyze the security and privacy issues that >> could arise from accessing DNS over HTTPS. In particular, the Working >> Group will consider the interaction of DNS and HTTP caching. > Yep, that's better than my earlier suggestion. > > Sold. /a From nobody Mon Sep 25 17:52:24 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7885613461A; Mon, 25 Sep 2017 17:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, 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 W3McrhtOqdDr; Mon, 25 Sep 2017 17:52:20 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 8F048132D4E; Mon, 25 Sep 2017 17:52:20 -0700 (PDT) Received: from mail-wr0-f181.google.com (mail-wr0-f181.google.com [209.85.128.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id E433F3A0A2; Mon, 25 Sep 2017 20:52:19 -0400 (EDT) Received: by mail-wr0-f181.google.com with SMTP id g29so10734336wrg.11; Mon, 25 Sep 2017 17:52:19 -0700 (PDT) X-Gm-Message-State: AHPjjUg0zx70keHawEgm2GajOkurW/cHvXqzId5C1S7ENgUszfHmn3Y7 nbxszcZVyka/7Mf+ylNxSCBu9ISuvaKJgd+P8ZY= X-Google-Smtp-Source: AOwi7QDR1rbE5HKHJw/EQoeWkD41Glbqy4Sk3EREjrpynhg30XeWciMD4aYemDwT3zeiqRGqpo+Sjz3+8gRdOV1ur6s= X-Received: by 10.25.18.71 with SMTP id h68mr2640435lfi.217.1506387138854; Mon, 25 Sep 2017 17:52:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.92.200 with HTTP; Mon, 25 Sep 2017 17:52:17 -0700 (PDT) In-Reply-To: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <03b11478-6b75-8e52-e6d9-612885804aad@nostrum.com> <2861b0eb-2486-9ba2-0b48-48293d758f03@cs.tcd.ie> <06c81edd-9f11-616f-e549-06fb180564a4@nostrum.com> <09eeb83b-ca78-bcbc-386e-c87eb82064b7@cs.tcd.ie> <1982a9a7-85ee-21d2-e0cf-a8efbfee8e15@cs.tcd.ie> From: Patrick McManus Date: Mon, 25 Sep 2017 20:52:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Stephen Farrell , Martin Thomson , Ted Hardie , doh@ietf.org, IETF Content-Type: multipart/alternative; boundary="001a113fdf984e44c0055a0d16d5" Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 26 Sep 2017 00:52:22 -0000 --001a113fdf984e44c0055a0d16d5 Content-Type: text/plain; charset="UTF-8" fine by me On Mon, Sep 25, 2017 at 8:50 PM, Adam Roach wrote: > On 9/25/17 7:06 PM, Stephen Farrell wrote: > >> >> On 26/09/17 01:04, Martin Thomson wrote: >> >>> The Working Group will analyze the security and privacy issues that >>> could arise from accessing DNS over HTTPS. In particular, the Working >>> Group will consider the interaction of DNS and HTTP caching. >>> >> Yep, that's better than my earlier suggestion. >> >> >> > Sold. > > /a > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --001a113fdf984e44c0055a0d16d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
fine by me

On Mon, Sep 25, 2017 at 8:50 PM, Adam Roach <adam@nos= trum.com> wrote:
On 9/25/17 7:06 PM, Stephen Farrell wrote:

On 26/09/17 01:04, Martin Thomson wrote:
The Working Group will analyze the security and privacy issues that
could arise from accessing DNS over HTTPS. In particular, the Working
Group will consider the interaction of DNS and HTTP caching.
Yep, that's better than my earlier suggestion.



 Sold.

/a


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

--001a113fdf984e44c0055a0d16d5-- From nobody Mon Sep 25 23:19:20 2017 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 8A0281321DC; Mon, 25 Sep 2017 23:19:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150640675354.13837.4615669192086496516.idtracker@ietfa.amsl.com> Date: Mon, 25 Sep 2017 23:19:13 -0700 Archived-At: Subject: [Doh] Spencer Dawkins' No Objection on charter-ietf-doh-00-10: (with COMMENT) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 06:19:13 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-doh-00-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I would be a Yes, but I don't want to be the first one) Thanks to everyone for the spirited review to date. I think the changes are headed the right direction. I trust that will continue. I have one nit. In this text, "The specification of how to discover DOH servers via mechanisms currently used to discover other DNS servers (e.g., DHCP and Router Advertisements) may be considered by the working group if the chairs determine that a sufficiently large mass of working group participants exist who are willing to edit and comment on documents regarding such mechanisms." is "large" the best word to describe what you're expecting the chairs to be assessing? :-) From nobody Mon Sep 25 23:26:07 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D2132D44; Mon, 25 Sep 2017 23:26:00 -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 1gsKpweT68du; Mon, 25 Sep 2017 23:25:59 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::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 F0DB2132396; Mon, 25 Sep 2017 23:25:58 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id l74so10461170oih.1; Mon, 25 Sep 2017 23:25:58 -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=tSLERxvHNbTJ5aiZcPUKAGJggYkvBSnUT2O9TO5LT9w=; b=fza3iZkQpsWAvoJaOYsOS/Scw0vhF/OIFJf+ggpu2+xgZPlaBBqBBHPYMMNZQ/EqIT VxBgnSGReVvT1RjzKtwCw1WSbhovmjMy/iHCAMStSn33Spqzqol+4VtLaYdvNRwohrNE IA18/97Lm8sYyeL1TSOFB5OzkaG7c7xY3bMIVbmFNSEkxvp+rCj8Rj29RQwTfZYu/Mrv sHKdU9kcg6Iit3TTS8vj4XipJQzTL9/24r4VfojM9/wr95OPYDnbMVHt5asX+6C9p6vu /x4ZpYierma5Ezft2iPq8aGHVi7JTbEsZYkw28+x/IGtRJesZA02x8MTN1ykVdOsugB4 hr6A== 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=tSLERxvHNbTJ5aiZcPUKAGJggYkvBSnUT2O9TO5LT9w=; b=BfD1ABCRkAPTeZvwtU4p5QfNW3uMitshnrOOlsXHe5NlWdbkcvdnFGimpd4Y0Bl99n /2TrM+uOWMG1Leg/M6tHpoR0HBFu8Ac/n3KbjepYlmGWn386ymJQQW+c9n1harTlqyHr 3T4krbv/lybcjHjj3GafZ+6b6c2H3rN2QSZl27nPkakWNQLtfReqn9neBNitTy2PKE14 5YelMi8R2i4udzATcEqgvGKDFz2MduD+cGr81xUpVsb3aBX9ilph9Q0qrXI3zECFo9Op OHzEau7+JXNClFWR1vq8Z4U9Z52tH/Xp8nGXXiZzFoRKLAEtWRGCzUbPn6EuLdmEYCb8 y1Vg== X-Gm-Message-State: AHPjjUg3yuCXtJPE4k+J6DbzjTqDjgY/VXPi4vlKbkfTJ49brDvgE7sC Ntl/od+oIhgy8lABqJNVvRpuviCEcf38FF2yazg= X-Google-Smtp-Source: AOwi7QC/a09ArhkQq8PkC/F12OV708jcNKAPML2EZF8Qo/2zOxOADmKotVatngplXSkE2t3M1AVgTmFg4PDzaPr8cKA= X-Received: by 10.202.96.69 with SMTP id u66mr9090064oib.257.1506407158401; Mon, 25 Sep 2017 23:25:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.0.38 with HTTP; Mon, 25 Sep 2017 23:25:57 -0700 (PDT) In-Reply-To: <150640675354.13837.4615669192086496516.idtracker@ietfa.amsl.com> References: <150640675354.13837.4615669192086496516.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 26 Sep 2017 16:25:57 +1000 Message-ID: To: Spencer Dawkins Cc: The IESG , doh@ietf.org, doh-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Doh] Spencer Dawkins' No Objection on charter-ietf-doh-00-10: (with COMMENT) 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, 26 Sep 2017 06:26:00 -0000 On Tue, Sep 26, 2017 at 4:19 PM, Spencer Dawkins wrote: > "The specification of how to discover DOH servers via mechanisms currently used > to discover other DNS servers (e.g., DHCP and Router Advertisements) may be > considered by the working group if the chairs determine that a sufficiently > large mass of working group participants exist who are willing to edit and > comment on documents regarding such mechanisms." I would observe that you can't use the same mechanisms, but you might use similar ones. And truncation might address Spencers "large" observation. "The working groups may define mechanisms for discovery of DOH servers similar to those existing mechanisms discovering other DNS servers if the chairs determine that there is both sufficient interest and working group consensus." From nobody Tue Sep 26 07:43:53 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED383126B71 for ; Tue, 26 Sep 2017 07:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=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 wYW48ZmdRvSy for ; Tue, 26 Sep 2017 07:43:43 -0700 (PDT) Received: from smtp109.iad3a.emailsrvr.com (smtp109.iad3a.emailsrvr.com [173.203.187.109]) (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 5471E13307B for ; Tue, 26 Sep 2017 07:43:43 -0700 (PDT) Received: from smtp22.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp22.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6150F6941; Tue, 26 Sep 2017 10:43:39 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp22.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8E8F71999; Tue, 26 Sep 2017 10:43:38 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.108.215] ([UNAVAILABLE]. [128.107.241.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Tue, 26 Sep 2017 10:43:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Tue, 26 Sep 2017 09:43:36 -0500 Cc: doh@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> To: Paul Hoffman X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Doh] WG Review: DNS Over HTTPS (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: Tue, 26 Sep 2017 14:43:46 -0000 If we need this to worry about what form of HTTP we are sending it over, = we are doing it something very wrong - ether this or HTTP. And if this = WG needs to worry about how the HTTP is transported over UPD, or TCP or = v4 or v6, then we have the wrong charter.=20 > On Sep 15, 2017, at 1:24 PM, Paul Hoffman = wrote: >=20 > On 15 Sep 2017, at 9:44, Ted Hardie wrote: >=20 > =3D>> This working group will standardize encodings for DNS queries = and responses >>> that are suitable for use in HTTPS. This will enable the domain name = system >>> to function over certain paths where existing DNS methods (UDP, TLS, = and >>> DTLS) >>> experience problems. The working group will re-use HTTPS methods, = error >>> codes, and other semantics to the greatest extent possible. The use = of >>> HTTPS >>> provides integrity and confidentiality, and it also allows the = transport to >>> interoperate with common HTTPS infrastructure and policy. >>>=20 >>>=20 >> I appreciate the charter's use of "HTTPS" as a signal that these are >> intended to be TLS-protected HTTP sessions. I note, however, that = there is >> considerable ambiguity still present. HTTPS can mean HTTP 1.1 over = TLS, >> HTTP/2 over TLS, and it may mean HTTP over QUIC at some point soon = (in some >> deployments it already means that). The document named as input = specifies >> HTTP/2 over TLS. While the working group may, of course, change = that to >> support HTTP 1.1 and/or QUIC, it might be useful for the charter to >> indicate which of these is potentially in scope. >=20 > Yes, please. The charter should say "HTTP/2 over TLS". There is no = reason for current browsers adding this feature to add it using an = obsolete protocol. If someone wants to create a diff from the eventual = protocol for HTTP 1.1, they can do that without forcing the document to = add a comparison of the two transports to what is supposed to be a = short, concise document. >=20 >> If the community is sure >> now that HTTP over QUIC is in scope, for example, having that noted = in the >> charter by adding the QUIC working group to list of working groups to >> consult would be useful. >=20 > The deadline for this WG is well ahead of when HTTP-over-QUIC will be = finalized. Instead, when HTTP-over-QUIC is finalized, an update to this = document should be pretty easy to produce. >=20 >> I will confess a bias here: while I think it is useful to match the >> capability set of HTTP over QUIC to that of HTTP over other = transports as >> much as possible, I think making that a key part of this work is not = a good >> initial direction. For one thing, there are some aspects of the QUIC >> transport that are still in discussion, and I think it will slow this = work >> a bit to track those. More importantly, though, I think this would = be the >> wrong way to do DNS over QUIC (draft-huitema-quic-dnsoquic-00 shows a >> different approach). Having QUIC be an early focus here may solidify = an >> approach that is simple, but not nearly as complete as we could = deliver >> with a DNS over QUIC. >>=20 >> (This is in part because of the choice to use the udp wireformat as = the >> baseline HTTP response here, rather than specifying DNS responses = over a >> transport construct like a QUIC stream. The working group could, of >> course, change that, but it would seriously shift the direction of = its >> input document to do so). >=20 > Fully agree. >=20 >>> Specification of how the DNS data may be used for new use cases, and >>> the discovery of the DOH servers, are out of scope for the working = group. >>>=20 >>>=20 >> While it is useful to know that discovery is out of scope here, I = think >> having a quick community discussion now of where it might be in scope = is >> useful. There are some potentially interesting questions buried in = that, >> especially in how we expect interworking with existing systems to go. >> Note that even if the service discovery method provides an HTTPS URI = for >> the name server, the questions above related to HTTP version or = transport >> may bite you. For server discovery based on address and port, the >> situation is much the same unless the port is clearly marked as TCP = or >> UDP. And if the server discovery includes no port at all, then a = happy >> eyeballs type method may be needed. >>=20 >> This may all fall into a combo of DHCP and DNSOP work, but giving = somewhat >> clean lines for it now seems like it will make the later work go = faster. >=20 > If you want to propose a new WG for that, please do so; there are a = lot of people interested in that topic. It definitely goes across = multiple areas of interest, such as "discovery" and "addressing" and = even "trust". Personally, I don't think it applies to a transport = document. >=20 >>> Milestones: >>>=20 >>> Apr 2018 - Submit specification for performing DNS queries over = HTTPS to >>> the IESG for publication as PS >>>=20 >>>=20 >> I admire the optimism in this. >=20 > It was not optimistic with the charter that was originally sent to the = IESG; see . As = more issues are added to the charter, it makes sense to have to extend = the milestone deliverable. >=20 > --Paul Hoffman >=20 From nobody Tue Sep 26 08:11:06 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4996B1201F8; Tue, 26 Sep 2017 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxmSThRQtK0D; Tue, 26 Sep 2017 08:11:04 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25BCB132D22; Tue, 26 Sep 2017 08:11:04 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8QFAu4x037953 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 26 Sep 2017 10:10:58 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Martin Thomson , Spencer Dawkins Cc: doh@ietf.org, The IESG , doh-chairs@ietf.org References: <150640675354.13837.4615669192086496516.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <00f16d6a-758a-7201-c0ef-0cb3f7ef13d7@nostrum.com> Date: Tue, 26 Sep 2017 10:10:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Spencer Dawkins' No Objection on charter-ietf-doh-00-10: (with COMMENT) 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, 26 Sep 2017 15:11:05 -0000 On 9/26/17 1:25 AM, Martin Thomson wrote: > On Tue, Sep 26, 2017 at 4:19 PM, Spencer Dawkins > wrote: >> "The specification of how to discover DOH servers via mechanisms currently used >> to discover other DNS servers (e.g., DHCP and Router Advertisements) may be >> considered by the working group if the chairs determine that a sufficiently >> large mass of working group participants exist who are willing to edit and >> comment on documents regarding such mechanisms." > I would observe that you can't use the same mechanisms, but you might > use similar ones. And truncation might address Spencers "large" > observation. > > "The working groups may define mechanisms for discovery of DOH servers > similar to those existing mechanisms discovering other DNS servers if > the chairs determine that there is both sufficient interest and > working group consensus." > Thanks again, Martin, for helping to make the charter more concise. I've adopted your text. /a From nobody Wed Sep 27 20:06:24 2017 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 6DE3E132D4E; Wed, 27 Sep 2017 20:06:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150656797942.13674.8149145165497227094.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 20:06:19 -0700 Archived-At: Subject: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 03:06:19 -0000 Ben Campbell has entered the following ballot position for charter-ietf-doh-00-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm balloting "yes", but I have a point of confusion on the following text: "The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS Clients and Iterative Resolvers. While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The working group will not engage in such preventative design." I remember someone (Terry, maybe?) stating earlier that the justification for keeping this separate from DPRIVE was that confidentiality was _not_ the primary use case, and connection from JS in browsers _was_. I see where people decided otherwise in the (95 entries so far) discussion thread--but does that change the relationship with DPRIVE? Especially since the first sentence comes directly from the DPRIVE charter? From nobody Wed Sep 27 20:11:08 2017 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 38626135251; Wed, 27 Sep 2017 20:11:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150656826318.13687.17985643866040126735.idtracker@ietfa.amsl.com> Date: Wed, 27 Sep 2017 20:11:03 -0700 Archived-At: Subject: [Doh] Eric Rescorla's No Objection on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 03:11:03 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-doh-00-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think this new text about JS is going in the right direction, but perhaps it straddles the line too much. Say that -- contra the text here -- we discovered some respect in which it was more convenient to design the protocol in a way that made JS break. Would the charter require us not to do that? I think the answer is "no", but I just want to verify that. From nobody Wed Sep 27 20:20:21 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E77513528A; Wed, 27 Sep 2017 20:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omJq10B-dBkO; Wed, 27 Sep 2017 20:20:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9726135271; Wed, 27 Sep 2017 20:20:13 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8S3KB3h013002 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Sep 2017 22:20:12 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Ben Campbell , The IESG Cc: doh@ietf.org, doh-chairs@ietf.org References: <150656797942.13674.8149145165497227094.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 27 Sep 2017 22:20:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150656797942.13674.8149145165497227094.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 03:20:15 -0000 On 9/27/17 22:06, Ben Campbell wrote: > I'm balloting "yes", but I have a point of confusion on the following text: > > "The primary focus of this working group is to develop a mechanism that > provides confidentiality and connectivity between DNS Clients and Iterative > Resolvers. While access to DNS-over-HTTPS servers from JavaScript running in > a typical web browser is not the primary use case for this work, precluding > the ability to do so would require additional preventative design. The working > group will not engage in such preventative design." > > I remember someone (Terry, maybe?) stating earlier that the justification for > keeping this separate from DPRIVE was that confidentiality was_not_ the > primary use case, and connection from JS in browsers_was_. I seem to recall that the issue with doing it in DPRIVE was that DPRIVE made it clear that they were not interested. I thought Terry said as much during the last formal telechat, although the narrative minutes don't seem to capture it in a way that matches my memory. The conversation about the charter so far -- like the input document -- are based primarily on "getting queries through networks where they might otherwise be blocked, snooped, or tamped with" as the primary use case, and the javascript-in-a-browser use case as secondary. There was one proponent on ietf@ietf.org who was specifically interested in the latter case, but the language above that precludes blocking that ability should serve those purposes fine. > I see where people > decided otherwise in the (95 entries so far) discussion thread--but does that > change the relationship with DPRIVE? Especially since the first sentence comes > directly from the DPRIVE charter? I took the line from DPRIVE because it was already vetted. :) You can find context for that specific addition here: /a From nobody Wed Sep 27 20:22:53 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E313528D; Wed, 27 Sep 2017 20:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmmMsF-Qvo5H; Wed, 27 Sep 2017 20:22:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D3B1344E7; Wed, 27 Sep 2017 20:22:47 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8S3Mjbm013481 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Sep 2017 22:22:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Eric Rescorla , The IESG Cc: doh@ietf.org, doh-chairs@ietf.org References: <150656826318.13687.17985643866040126735.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 27 Sep 2017 22:22:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150656826318.13687.17985643866040126735.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Eric Rescorla's No Objection on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 03:22:48 -0000 On 9/27/17 22:11, Eric Rescorla wrote: > I think this new text about JS is going in the right direction, but perhaps it > straddles the line too much. > > Say that -- contra the text here -- we discovered some respect in which it was > more convenient to design the protocol in a way that made JS break. Would the > charter require us not to do that? I think the answer is "no", but I just want > to verify that. The charter would allow that. I suspect that there's a good chance that WG consensus wouldn't fall in line with a proposal to do so, but I think that the WG is the right group of people to make such a decision. /a From nobody Wed Sep 27 20:31:19 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53F133011; Wed, 27 Sep 2017 20:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tzw1mWIeYun; Wed, 27 Sep 2017 20:31:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E9F132D67; Wed, 27 Sep 2017 20:31:11 -0700 (PDT) Received: from [10.0.1.82] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8S3VAtH015040 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 27 Sep 2017 22:31:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.82] From: Ben Campbell Message-Id: <8BF3ECB4-946D-4588-8746-509E3516E750@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CB073685-B36B-4910-A750-CF79F5CDA8CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 27 Sep 2017 22:31:09 -0500 In-Reply-To: Cc: The IESG , doh@ietf.org, doh-chairs@ietf.org To: Adam Roach References: <150656797942.13674.8149145165497227094.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Doh] Ben Campbell's Yes on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 03:31:13 -0000 --Apple-Mail=_CB073685-B36B-4910-A750-CF79F5CDA8CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 27, 2017, at 10:20 PM, Adam Roach wrote: >=20 > On 9/27/17 22:06, Ben Campbell wrote: >> I'm balloting "yes", but I have a point of confusion on the following = text: >>=20 >> "The primary focus of this working group is to develop a mechanism = that >> provides confidentiality and connectivity between DNS Clients and = Iterative >> Resolvers. While access to DNS-over-HTTPS servers from JavaScript = running in >> a typical web browser is not the primary use case for this work, = precluding >> the ability to do so would require additional preventative design. = The working >> group will not engage in such preventative design." >>=20 >> I remember someone (Terry, maybe?) stating earlier that the = justification for >> keeping this separate from DPRIVE was that confidentiality was_not_ = the >> primary use case, and connection from JS in browsers_was_. >=20 > I seem to recall that the issue with doing it in DPRIVE was that = DPRIVE made it clear that they were not interested. I thought Terry said = as much during the last formal telechat, although the narrative minutes = don't seem to capture it in a way that matches my memory. I should let Terry speak for himself, but I thought at some point he = mentioned that as the reasoning DPRIVE was not interested. I may = misremember. Don=E2=80=99t get me wrong, I=E2=80=99m happy enough with this going = forward. This was a =E2=80=9Cyes=E2=80=9D ballot. I just wanted to make = sure we hadn't changed the basic premise which generated the =E2=80=9Cnot = in DPRIVE=E2=80=9D decision. >=20 > The conversation about the charter so far -- like the input document = -- are based primarily on "getting queries through networks where they = might otherwise be blocked, snooped, or tamped with" as the primary use = case, and the javascript-in-a-browser use case as secondary. There was = one proponent on ietf@ietf.org who was specifically interested in the = latter case, but the language above that precludes blocking that ability = should serve those purposes fine. >=20 >> I see where people >> decided otherwise in the (95 entries so far) discussion thread--but = does that >> change the relationship with DPRIVE? Especially since the first = sentence comes >> directly from the DPRIVE charter? >=20 > I took the line from DPRIVE because it was already vetted. :) >=20 > You can find context for that specific addition here: = Yeah, I think that was entry number 86 :-) >=20 > /a >=20 --Apple-Mail=_CB073685-B36B-4910-A750-CF79F5CDA8CE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZzGz9AAoJEIBWSmyV89QNzu4QALtEUmjI46jpz1RuKQx/4ZcV bElKbWyxryofybR5V+9xUG9+v7lt8AXDhTW7LSWdXDF4LaBPGIi7lIjAgQ0jePvD 71se4d8skUeoVA9EYLt7LOgDN29l6W85+eeTgY2vxh0Gsd40b8LA+9W2j7LI2ITn 89+7xybcMCZbJArC/HPH//x9VhIJp66D/+U+OLGjhFpjlLqYLrPUoi9lIY0wyazv 1kyEJJLET2jwHcOAQAIHMVhegi6AGkkOoNtybdAnDt0M7IkoBTmhMnLZFMr1b5Km wUpI+n0H5l6znSSHlI1JoKhQEuseIZKF8A7RSqsNC4NrcC3cLFEIFqegNkeJ6tV1 ApyPgvbrfPe8A2OPxJHYlqJRneKstDhz2CKnh42qgha1c6vItiah1ETk2O4d8nJM BR+04Gohhyb45GUmWGEcPpN1esNnMZazPSS23UFbYk9UlgX8HXQTceBJ+b5iDv+Y 90Tpl8zbhyJ/XD81I2mCIJV1sazjbZS1r7SB4OjIyQAxteOWJAm2Nueb4BnF0BQE X7Ce0lGGTkcIuHKFoU3wXqze/VClr+n1BIW9GIJy1fb/4z9f6Arft1Gpz0lejzTn hGOBB/EmH2HzdUpFu/icTkGzdkwhDYsIkpiL5hPntALCK3k0A61aIH6gTftfkATO dJx9zxgwpIDvfJLaHpqS =MYL/ -----END PGP SIGNATURE----- --Apple-Mail=_CB073685-B36B-4910-A750-CF79F5CDA8CE-- From nobody Thu Sep 28 03:07:00 2017 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 03D9113463D; Thu, 28 Sep 2017 03:06:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: doh-chairs@ietf.org, doh@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.62.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 03:06:53 -0700 Archived-At: Subject: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 10:06:54 -0000 Benoit Claise has entered the following ballot position for charter-ietf-doh-00-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-doh/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In my first ballot, I mentioned "What I've been failing to understand from the charter is the rational for DNS over HTTPS? Can you expand on this." Because I'm not an Web browser and DNS expert, or most likely because the concerns were not clear in my head, I could not clearly express my thoughts. So I watched the IETF mailing list with attention. Mark Nottingham's email summarized the situation It's not a matter of constraining the work; the work isn't proposing to operate even remotely in the way that you describe. I think we're just having a misunderstanding, because people have multiple use cases in mind for this protocol, and properties thereof have been mixed up. AIUI those use cases are, roughly: 1. Configure your browser/OS to use a DOH service for DNS resolution (as above) -- this will affect browser/OS state, because it's being used for DNS; however, it's not being done from JS. 2. Call a DOH service from Javascript (for some reason) -- note this is just like any other HTTP request; it doesn't affect browser/OS state outside of the same origin model. Yes, you can still build a browser-in-a-browser and mess with things inside that context, but that's already true today. 3. Future handwavy things like making DNS updates over HTTP -- very ill-defined and not important for this discussion Expressing #1 and #2 in the charter would have helped me. #2 is kind of present now. What about the addition the notion of "browser and/or OS" in the next sentence? The primary focus of this working group is to develop a mechanism that provides confidentiality and connectivity between DNS Clients and Iterative Resolvers. From nobody Thu Sep 28 12:52:40 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC3E1348C9; Thu, 28 Sep 2017 12:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWD-EcaMql17; Thu, 28 Sep 2017 12:52:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9661348D5; Thu, 28 Sep 2017 12:52:36 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v8SJqUSj088611 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 28 Sep 2017 14:52:31 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Benoit Claise , The IESG Cc: doh@ietf.org, doh-chairs@ietf.org References: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <4cfa383f-deb3-6a13-6c63-218071454399@nostrum.com> Date: Thu, 28 Sep 2017 14:52:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 19:52:38 -0000 On 9/28/17 5:06 AM, Benoit Claise wrote: > In my first ballot, I mentioned "What I've been failing to understand from the > charter is the rational for DNS over HTTPS? Can you expand on this." Because > I'm not an Web browser and DNS expert, or most likely because the concerns were > not clear in my head, I could not clearly express my thoughts. > > So I watched the IETF mailing list with attention. > Mark Nottingham's email summarized the situation > > It's not a matter of constraining the work; the work isn't proposing to > operate even remotely in the way that you describe. I think we're just > having a misunderstanding, because people have multiple use cases in mind > for this protocol, and properties thereof have been mixed up. > > AIUI those use cases are, roughly: > > 1. Configure your browser/OS to use a DOH service for DNS resolution (as > above) -- this will affect browser/OS state, because it's being used for > DNS; however, it's not being done from JS. > > 2. Call a DOH service from Javascript (for some reason) -- note this is > just like any other HTTP request; it doesn't affect browser/OS state > outside of the same origin model. Yes, you can still build a > browser-in-a-browser and mess with things inside that context, but that's > already true today. > > 3. Future handwavy things like making DNS updates over HTTP -- very > ill-defined and not important for this discussion > > Expressing #1 and #2 in the charter would have helped me. #2 is kind of present > now. What about the addition the notion of "browser and/or OS" in the next > sentence? > > The primary focus of this working group is to develop a mechanism that > provides confidentiality and connectivity between DNS Clients and Iterative > Resolvers. I think "browser" is likely to confuse the issue, since people are likely to conflate that with JavaScript. Do you think it would be clear enough to say the following? "The 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 Iterative Resolvers." /a From nobody Thu Sep 28 14:09:42 2017 Return-Path: X-Original-To: doh@ietfa.amsl.com Delivered-To: doh@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1601349A5; Thu, 28 Sep 2017 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCD3SeB3-U3W; Thu, 28 Sep 2017 14:09:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE99613433C; Thu, 28 Sep 2017 14:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2485; q=dns/txt; s=iport; t=1506632979; x=1507842579; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0GeoyOMZ4QTiOUEuGay++8eNYU0QZtF6pUeXQrmX0sY=; b=XK1WWOQ5IqsHKm6H9RIX+oPJOdG3eeWzKCwzzXKmmFW/hFHeYZTnY/sk hpzFLTeWRKodgblZj7OsuPIgbTr1gylte0f1/QnqW64LtYw9G/VdHxzAB QHioptCvVq1LxJLdnqvzxZZ4+auoBAWNQNKAtqKecolzeXFBvHW5OfHxv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDKZM1Z/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhEBuhB+LE5BhljmCBAqFOwKEaBQBAgEBAQEBAQFrKIUZAQUjDwE?= =?us-ascii?q?FMwMLEAkCGAICJgICVwYBDAgBAYotiSidZoIni0MBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEggQ6CHYNTgWorgn2EUQESAYMygmAFh0SZZI8YhUiLW4crjXSHWYE5NiGBAws?= =?us-ascii?q?yIQgdFUmHHz6HBoI0AQEB?= X-IronPort-AV: E=Sophos;i="5.42,451,1500940800"; d="scan'208";a="657897412" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 21:09:16 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v8SL9GAk019751; Thu, 28 Sep 2017 21:09:16 GMT To: Adam Roach , The IESG Cc: doh@ietf.org, doh-chairs@ietf.org References: <150659321397.13780.18221165528947192319.idtracker@ietfa.amsl.com> <4cfa383f-deb3-6a13-6c63-218071454399@nostrum.com> From: Benoit Claise Message-ID: Date: Thu, 28 Sep 2017 23:09:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <4cfa383f-deb3-6a13-6c63-218071454399@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Doh] Benoit Claise's No Objection on charter-ietf-doh-00-12: (with COMMENT) 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, 28 Sep 2017 21:09:41 -0000 That would help. Thanks Adam B. > On 9/28/17 5:06 AM, Benoit Claise wrote: >> In my first ballot, I mentioned "What I've been failing to understand >> from the >> charter is the rational for DNS over HTTPS? Can you expand on this." >> Because >> I'm not an Web browser and DNS expert, or most likely because the >> concerns were >> not clear in my head, I could not clearly express my thoughts. >> >> So I watched the IETF mailing list with attention. >> Mark Nottingham's email summarized the situation >> >>      It's not a matter of constraining the work; the work isn't >> proposing to >>      operate even remotely in the way that you describe. I think >> we're just >>      having a misunderstanding, because people have multiple use >> cases in mind >>      for this protocol, and properties thereof have been mixed up. >> >>      AIUI those use cases are, roughly: >> >>      1. Configure your browser/OS to use a DOH service for DNS >> resolution (as >>      above) -- this will affect browser/OS state, because it's being >> used for >>      DNS; however, it's not being done from JS. >> >>      2. Call a DOH service from Javascript (for some reason) -- note >> this is >>      just like any other HTTP request; it doesn't affect browser/OS >> state >>      outside of the same origin model. Yes, you can still build a >>      browser-in-a-browser and mess with things inside that context, >> but that's >>      already true today. >> >>      3. Future handwavy things like making DNS updates over HTTP -- very >>      ill-defined and not important for this discussion >> >> Expressing #1 and #2 in the charter would have helped me. #2 is kind >> of present >> now. What about the addition the notion of "browser and/or OS" in the >> next >> sentence? >> >> The primary focus of this working group is to develop a mechanism that >> provides confidentiality and connectivity between DNS Clients and >> Iterative >> Resolvers. > > > I think "browser" is likely to confuse the issue, since people are > likely to conflate that with JavaScript. Do you think it would be > clear enough to say the following? > > "The 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 Iterative Resolvers." > > /a > > . > From nobody Thu Sep 28 14:26:31 2017 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 D74E91321A0; Thu, 28 Sep 2017 14:26:29 -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, doh-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150663398983.27803.6255953947790311593.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 14:26:29 -0700 Archived-At: Subject: [Doh] doh - New Meeting Session Request for IETF 100 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, 28 Sep 2017 21:26:30 -0000 A new meeting session request has just been submitted by Adam Roach, a ART Area Director. --------------------------------------------------------- Working Group Name: DNS Over HTTPS Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: quic httpbis dnsop dprive intarea dhc 6man dispatch People who must be present: Paul E. Hoffman Adam Roach Patrick R. McManus Warren Kumari Patrick McManus Benjamin M. Schwartz David C Lawrence Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Sep 28 14:30:02 2017 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 ED12C1321A0; Thu, 28 Sep 2017 14:29:59 -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, doh-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150663419992.27783.4089913296701011641.idtracker@ietfa.amsl.com> Date: Thu, 28 Sep 2017 14:29:59 -0700 Archived-At: Subject: [Doh] doh - Update to a Meeting Session Request for IETF 100 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, 28 Sep 2017 21:30:00 -0000 An update to a meeting session request has just been submitted by Adam Roach, a ART Area Director. --------------------------------------------------------- Working Group Name: DNS Over HTTPS Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: quic httpbis dnsop dprive intarea dhc 6man dispatch Second Priority: acme People who must be present: Paul E. Hoffman Adam Roach Patrick R. McManus Warren Kumari Patrick McManus Benjamin M. Schwartz David C Lawrence Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 29 09:21:01 2017 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 36740133328; Fri, 29 Sep 2017 09:20:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , doh@ietf.org, doh-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150670204822.14246.16915680001107712054.idtracker@ietfa.amsl.com> Date: Fri, 29 Sep 2017 09:20:48 -0700 Archived-At: Subject: [Doh] WG Action: Formed DNS Over HTTPS (doh) X-BeenThere: doh@ietf.org X-Mailman-Version: 2.1.22 List-Id: DNS Over HTTPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2017 16:20:48 -0000 A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chairs. DNS Over HTTPS (doh) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: David Lawrence Benjamin Schwartz Assigned Area Director: Adam Roach Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Technical advisors: Warren Kumari Mailing list: Address: doh@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/doh Archive: https://mailarchive.ietf.org/arch/browse/doh/ Group page: https://datatracker.ietf.org/group/doh/ Charter: https://datatracker.ietf.org/doc/charter-ietf-doh/ This working group will standardize encodings for DNS queries and responses that are suitable for use in HTTPS. This will enable the domain name system to function over certain paths where existing DNS methods (UDP, TLS [RFC 7857], and DTLS [RFC 8094]) experience problems. The working group will re-use HTTPS methods, error codes, and other semantics to the greatest extent possible. The use of HTTPS and its existing PKI provides integrity and confidentiality, and it also allows interoperation with common HTTPS infrastructure and policy. The 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. While access to DNS-over-HTTPS servers from JavaScript running in a typical web browser is not the primary use case for this work, precluding the ability to do so would require additional preventative design. The working group will not engage in such preventative design. The working group will analyze the security and privacy issues that could arise from accessing DNS over HTTPS. In particular, the working group will consider the interaction of DNS and HTTP caching. The working group will coordinate with the DNSOP and INTAREA working groups for input on DNS-over-HTTPS's impact on DNS operations and DNS semantics, respectvely. In particular, DNSOP will be consulted for guidance on the operational impacts that result from traditional host behaviors (i.e., stub-resolver to recursive-resolver interaction) being replaced with the specified mechanism. Specification of how DNS-formatted data may be used for use cases beyond normal DNS queries is out of scope for the working group. The working group may define mechanisms for discovery of DOH servers similar to existing mechanisms for discovering other DNS servers if the chairs determine that there is both sufficient interest and working group consensus. The working group will use draft-hoffman-dispatch-dns-over-https as input. Milestones: Apr 2018 - Submit specification for performing DNS queries over HTTPS to the IESG for publication as PS