Re: [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 0689C12426A for <>; Tue, 6 Nov 2018 06:39:37 -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=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OX80UnA51TXu for <>; Tue, 6 Nov 2018 06:39:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2874124BE5 for <>; Tue, 6 Nov 2018 06:39:33 -0800 (PST)
Received: by with SMTP id f3-v6so11641838ljk.9 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=g3h76NtYwEAFtaiJ+6HawdBmnwP8BpE0tHB2ainYpd5+3b9Gk6aV0wUuVZhUuj0dVV 3Npxb9AWIQJoQwTF0iHuA97PhQo2VnsVY7HcCCgmHivr1tv/iHkaP27gMrQskYrSUIET O938sUGZyyMWKzkdlp2KqdLjzj3RUmjOzij9jvmkwJtQaBZQ5cdNWmHVpGZGTZYa5IQ5 oJAR0OJ+IWqvtCQjtzRMEs44QKaQbUARaWgkJVL+EKSCVMNzwFLEtJW6oy66La4jW+4b W9+wbP5mxkzVHPs9JRowRJsnr8wVgQ4yoeefDNhkX0iAH62XN23MBZqtekKOrUo/i2ee KrXA==
X-Gm-Message-State: AGRZ1gK553W/3FcCcRotxJTHje50u9JHaJQpsUs1bTopDBv/oM5DhD3b x0dkEteqR20fuYBSVfFeFQ9B+WYoiN3zviGch8xtok9o
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, 06 Nov 2018 06:39:30 -0800
Message-ID: <>
To: Mukund Sivaraman <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] 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 14:39:37 -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.