[DNSOP] On today's resolverless DNS meeting

Mukund Sivaraman <muks@mukund.org> Tue, 06 November 2018 10:27 UTC

Return-Path: <muks@mukund.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DFED9130DC4; Tue, 6 Nov 2018 02:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VJ1LQzHp1pLG; Tue, 6 Nov 2018 02:27:39 -0800 (PST)
Received: from mail.banu.com (mail.banu.com []) by ietfa.amsl.com (Postfix) with ESMTP id C631C1277C8; Tue, 6 Nov 2018 02:27:38 -0800 (PST)
Received: from naina (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 7A9C532C0908; Tue, 6 Nov 2018 10:27:35 +0000 (UTC)
Date: Tue, 06 Nov 2018 17:27:31 +0700
From: Mukund Sivaraman <muks@mukund.org>
To: doh@ietf.org, dnsop@ietf.org
Message-ID: <20181106102731.GA5280@naina>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2EuWuCPr3LW4OrI89vNHfRxLcmg>
Subject: [DNSOP] On today's resolverless DNS meeting
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 10:27:41 -0000

Hi all

It seemed that the objective (or an objective) of what is desired is for
a webpage to have an <img src=""> and also push an address record for
the hostname in the src URL.

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?

Why can't the webpage contain the addresses of the hostname in the URL,
in another attribute of that element? Does it have to be separately
signed via DNSSEC and certificates? The webpage can tell the browser to
fetch the img resource from anyplace it wants to - it can very well
specify an IP address instead of the hostname - the webpage controls
it. Why can't it, for *that* element, provide the target address in an
attribute without any additional signatures, given that the webpage's
content itself is authenticated via TLS?