Re: [Doh] [DNSOP] 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 1D81F130DEF for <>; Tue, 6 Nov 2018 10:58:50 -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 IHMEgCCkOx7F for <>; Tue, 6 Nov 2018 10:58:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F88012F1A5 for <>; Tue, 6 Nov 2018 10:58:46 -0800 (PST)
Received: by with SMTP id t189-v6so11135001itf.1 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=FDBhR2oAIZpqJCjMOW+pZ28Y9JSmuSpBSJtJGLP0ZQc=; b=qORuKIUL3J9CEuF1BYI5IjwH9/6uT1PMPOQpkBOID3WCaRcfzyM/9bNQfqu25LL1lU nG83w99Dcc6PRFriF2MjYKgd+hpOzbWoDRy+bKemjeDWH/T1QrzqlxE1HsKEYrJ8uH7Q xiYk9vxL4oiH6VY6V1FmxcCDNhHP3Yghuhc8CDTuwJehUdXo534NCP7otDPtd7Nteivr tZEwlWBfDeyvYt81yelK4lMAyX4YkviApK+2+7+3ujqwS5st3Iic3HUN8OSN02c2qjjm +fQtg740IAqcINqg5U6iBcIf/fgbsOB1VTzXbWckw4ZAWIEylInsSqLiNN81JK8RAlCD +K9g==
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=FDBhR2oAIZpqJCjMOW+pZ28Y9JSmuSpBSJtJGLP0ZQc=; b=T8r4ExCRPD9PwFVpn/RV1nBwW3/Yjo8rQCZALmrhHYmznGlSV67+Uk02qS9PYbnKZy D1zToA96sZuQki4EiHx4Bbdf3EqtKFKYC2GeNgdiL5jUy+iVzao41BjGuoC5NUfFXaOD a8ZGf7210jnF6ehJWt8ZZtInMrwKp7dFG2NDpMSyi9njfY6dkxoh5pYfUHYc63ygvvTW Fyh5XjkYoN1lJQwh6uS81ue+QWcO9zFli6ltmetOkHil12P0WA4jJc+y8GRzYptOeBN6 xGgltE3h69KckqAiHMBMMWjXRbPzrFcYXBx8k1WgzSeYmk7dqScCVk8+qUUub0PyvrWm 5fvA==
X-Gm-Message-State: AGRZ1gLVhlgWpWUA8qqvjPTHlsvEs7U/sWrTMq8SwtdYVWwGhHMnJp0E IMnfPHEabv6Lopf3NBqVfVV2bZM8mnYRar6z+d13Sa32AMSjyw==
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, 6 Nov 2018 13:58:33 -0500
Message-ID: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000054359e057a0397a0"
Archived-At: <>
X-Mailman-Approved-At: Tue, 06 Nov 2018 10:59:57 -0800
Subject: Re: [Doh] [DNSOP] On today's resolverless DNS meeting
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 18:58:50 -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