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

Toerless Eckert <tte@cs.fau.de> Wed, 20 September 2017 23:51 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: doh@ietfa.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 <tte@cs.fau.de>
To: Adam Roach <adam@nostrum.com>
Cc: ietf@ietf.org, doh@ietf.org, IETF-Announce <ietf-announce@ietf.org>
Message-ID: <20170920235150.GB27965@faui40p.informatik.uni-erlangen.de>
References: <150549029332.2975.12341647131707994474.idtracker@ietfa.amsl.com> <20170920151458.GA22670@faui40p.informatik.uni-erlangen.de> <eaadc24d-6150-2396-64b6-708266de1c69@nostrum.com> <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: <https://mailarchive.ietf.org/arch/msg/doh/ao-i9PWJ6OEmrpw9EFQi27CdVAw>
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 <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: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