Re: [DNSOP] [Doh] On today's resolverless DNS meeting

Ben Schwartz <> Tue, 06 November 2018 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B27E130E02 for <>; Tue, 6 Nov 2018 10:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0E8JsE0Nli9T for <>; Tue, 6 Nov 2018 10:58:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B450D130DFA for <>; Tue, 6 Nov 2018 10:58:46 -0800 (PST)
Received: by with SMTP id r12-v6so16629783ita.3 for <>; Tue, 06 Nov 2018 10:58:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MPuWfdeHdAfh8IajkOUM9IGocwNOqUbKVR0nEPYaIMk=; b=cFzHNtJOsN+pUjBk4QH78QfEWLimCgUWM4YQuFXJNcdBxZajdunyPETZsF2dPSmZWZ NJDbGNFSI2UFfACN/OnT3/bHu02uwiMiBG+ZgTqcZZih/+y68RMdMxxAzrtS8sF1WfDk LvgLKANWR0VpQ4vjuh0dNucgS9K2uqVSTtfow71KeytHUrgvLMuWqfhjjKRUzFMZ4hia hUz+sHqMzc9F7xz6Hwytc7kbhjOkYaY8/yMrTL/zglYNciU8N7/AVhiJh+8k/vV7gKoD K0TlyPiUK6gfexZrKDfrsm3IUCNuMDQwga4Nk6F5bTLkmDO4IHO21/h6qhuPsGwd0rkr WdEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MPuWfdeHdAfh8IajkOUM9IGocwNOqUbKVR0nEPYaIMk=; b=NvnqI19uaIONtlLyovpdatsI/So4/NkQ+ed610uxPqIrnZGCTiGbceROmqRLiGcbK+ 0OvvDxax/JJM8ujU07y9ioElhUj2abNcVMepRSReIMcel0gi9aUOGWJ8cnUtkkGP4z3V JCaAytlri/4nCown301RIXsjQssUXRm7WcWkB95+Xy1yx7KCDJaIvfSfoIZRR5ECu6VI tJdpJQrcrqho6Vtd73AXMWtlx20OzyAzGZWdQUZu21Kok2+p+Mm5O+aKwK5t3vBvIpog J+ME8A8uzPcvKoS1IGRZ5uNJCXrpykDyp8zSjfaghSbTjbr6SWCQicjkG+IMw9AAGwXf 91AQ==
X-Gm-Message-State: AGRZ1gLwaBsvDCqJ8yZUF9hP8CyZQg7SvcvrvI/mrg9K1UI//Lbdyrj0 0pfAl9jnmNShFTP1bS0g4GJUxGlaVPWIezGo6ivERw==
X-Google-Smtp-Source: AJdET5ctDt1YsOSY2CqQ/B6y3oxcDUr0+Gefz2JwNLTKuEJgwR0b2HyuhiCl7kG3qkBeD0jXFpqofLy8vCGqiaT/lJ8=
X-Received: by 2002:a24:5c05:: with SMTP id q5-v6mr3054194itb.70.1541530725322; Tue, 06 Nov 2018 10:58:45 -0800 (PST)
MIME-Version: 1.0
References: <20181106102731.GA5280@naina> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Tue, 06 Nov 2018 13:58:33 -0500
Message-ID: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000005955b2057a0397e3"
Archived-At: <>
X-Mailman-Approved-At: Sat, 10 Nov 2018 17:06:32 -0800
Subject: Re: [DNSOP] [Doh] On today's resolverless DNS meeting
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 18:58:52 -0000

DOH and dnsop to bcc.

On Tue, Nov 6, 2018 at 9:45 AM Justin Henck <henck=> wrote:

> Briefly jumping in to add, which was set up
> after the last meeting for discussion of this specific topic.  Direct link:
> I also just sent the notes to that mailing list.
> Justin Henck
> Product Manager
> 212-565-9811
> PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B
> On Tue, Nov 6, 2018 at 9:39 PM Joe Abley <> wrote:
>> > On Nov 6, 2018, at 17:27, Mukund Sivaraman <> wrote:
>> >
>> > We talked about DNSSEC and certificate signing and such. If the host
>> > serving this webpage to the browser has control over the webpage's
>> > content (e.g., the contents of that src attribute), and the webpage's
>> > contents are already authenticated by TLS, then why does an address
>> > record have to be separately authenticated?
>> I think this is an easy one. It doesn't.
>> The names that it is permissible for a server to push information
>> about (and the names that a client should be allowed to accept) must
>> be constrained such that the names supplied for use in one web
>> application can't influence the operation of another.
I don't see any way to do this in the web security model.  For example, if
two web applications both use subresources from the same origin, then
cookies loaded for that origin from one application will be included in
requests to the other.  Similarly, subresource cache entries populated by
one application will be reused by other applications.  Web security is
scoped to the domain of each request, not the domain of the page.
Additionally, most browsers perform connection coalescing for resources on
the same origin, even if the requests are from different tabs.

I'm very interested in finding a solution here, but I don't think it will
be so simple.  For example, there may be a nontrivial interaction with the
iframe "sandbox" attribute.

Some of these problems become easier if we imagine an https-only world.
However, many browser engineers believe that DNS integrity acts as an
important barrier to utilization of stolen WebPKI private keys.  If you
accept this threat model, using unsigned DNS records from untrusted parties
could enable more stolen-key attacks.

There is a complex intersection of web and DNS problems, and IMHO too
speculative for dnsop (and out of scope for doh's current charter), so I
would encourage interested parties to join the resolverless-dns list.

(For example, it would be bad if some generic and otherwise benign web
>> page could feed the browser high-TTL DNS messages for names under
>> online retailer domains that accept credit cards or component APIs
>> used within genuine web apps.)
>> The obvious analogy to me is the logic that controls what cookies a
>> browser should accept. Maybe exactly the same rules are appropriate. I
>> realise that managing those rules using mechanisms like the public
>> suffix list is not without challenges.
>> If we accept that these constraints are necessary, then the presence
>> or absence of DNSSEC signatures doesn't matter. The DoH objects are
>> within the same security perimeter as the URIs that make use of them
>> and don't benefit from additional integrity protection; the transport
>> security for all the other objects being sent from server to client
>> provides the right coverage.
>> Joe
>> _______________________________________________
>> Doh mailing list
> _______________________________________________
> Doh mailing list