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

Toerless Eckert <> Wed, 20 September 2017 23:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D5724132199; Wed, 20 Sep 2017 16:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qa08N3k9VwZu; Wed, 20 Sep 2017 16:50:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D24EC132198; Wed, 20 Sep 2017 16:50:35 -0700 (PDT)
Received: from ( [IPv6:2001:638:a000:4134::ffff:77]) by (Postfix) with ESMTP id 220BF58C4AF; Thu, 21 Sep 2017 01:50:32 +0200 (CEST)
Received: by (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-Announce <>
Message-ID: <>
References: <> <> <>
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-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 ?


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
> >