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

Joe Abley <> Tue, 06 November 2018 14:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05543130DFE for <>; Tue, 6 Nov 2018 06:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o4HOoeNdcPo4 for <>; Tue, 6 Nov 2018 06:39:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E4E4012426A for <>; Tue, 6 Nov 2018 06:39:33 -0800 (PST)
Received: by with SMTP id v1-v6so5423710ljd.0 for <>; Tue, 06 Nov 2018 06:39:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=O7SauoN52L3YghV5k20xzAuF26vf3MkONeyCWUclxC8=; b=efEkpijKUvG+mVWOMnTpAlwaZ8di3rBQcxyuE4xNDkMxfwif9jB82h/weH+3q6BcgD 4Ekj45I9UDx+Q0uRWWM1RnYGRGSqzrpK89hfcm+rTreyaQuhaWqv19SlTSJyMpSRoMC1 1lKtjD+PT8X0n84x7TQAnB8pfrvGVWVFL/x7s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=O7SauoN52L3YghV5k20xzAuF26vf3MkONeyCWUclxC8=; b=EdDlDk1Rp+7hnDkso4KHHmxsnJI/FPvYh71shM1+8cT04FzcmoyXyDOCos7gLh4L4o VpME7Ux0ufviO3qg2GJpDZHpW/j/NUTIAPE03VjS4CaUUFTJkFf83KZUan0tuGluQ4Jh lCBiX+RX1x0DbXQ8h9Kfiha56cTigeUQrXwiQejWI5TN50VddsQHWrZ+bVm5qA9O2q7D cuasFkBNxiDGuwWUftqz+KTfeHBbppVwaiKqLZnHRiTFLKxfQkMDyZeYjW1N2HRyISs5 JcZVlpFbakyMXieZJO/Xp/k8EZKRLhVrJSa+iGI5Zs5euaV1ADTAxEI5+Jk9x9gq8MAC Rz0g==
X-Google-Smtp-Source: AJdET5dCOiBEWrh/SULE+HwHSruTDxswqosMU+VDjvOwhBrssK5KqEuFyCzp5hV/4SQVfy65SvuGDKVwnJxf2kE6vGI=
X-Received: by 2002:a2e:6d0a:: with SMTP id i10-v6mr18916522ljc.14.1541515171950; Tue, 06 Nov 2018 06:39:31 -0800 (PST)
Received: from unknown named unknown by with HTTPREST; Tue, 6 Nov 2018 06:39:30 -0800
From: Joe Abley <>
Mime-Version: 1.0 (1.0)
References: <20181106102731.GA5280@naina>
In-Reply-To: <20181106102731.GA5280@naina>
Date: Tue, 6 Nov 2018 06:39:30 -0800
Message-ID: <>
To: Mukund Sivaraman <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
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 14:39:36 -0000

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

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