Re: [Doh] WG Review: DNS Over HTTPS (doh)

Adam Roach <adam@nostrum.com> Wed, 20 September 2017 23:39 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: doh@ietfa.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 <adam@nostrum.com>
To: Toerless Eckert <tte@cs.fau.de>, ietf@ietf.org
Cc: doh@ietf.org, IETF-Announce <ietf-announce@ietf.org>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <eaadc24d-6150-2396-64b6-708266de1c69@nostrum.com>
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: <eaadc24d-6150-2396-64b6-708266de1c69@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/nOr-X7REZKR9kOtVRzjk9W3FHO8>
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 <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=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