Return-Path: X-Original-To: dnsop@ietfa.amsl.com Delivered-To: dnsop@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A964130E48 for ; Tue, 6 Nov 2018 06:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: 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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-OqMzh5XGfZ for ; Tue, 6 Nov 2018 06:45:09 -0800 (PST) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBFDB130E3F for ; Tue, 6 Nov 2018 06:45:08 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id z11so2693147uaa.10 for ; Tue, 06 Nov 2018 06:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fZ85//HAL1u8tGRSWBYUwISmaevkCKDhlUIFuHg5k+w=; b=aZI0WTuCyXrhMe+52Fg6+iauDJnLaLPu34M7ZyctrGnB218nfxOChq2zRwvVuplatm MnPiHHDBzdS40rVuYER83U6r41iEIf18VMb0ZEFdYeBb7oSpwTQ6pp+gIlAn8BDgBqAO Cd7gxiL14in7qvAPgR7HzujT5/0nTVhv7LFKOOCue2BGj704T10dAnGrelwG3M9t5MRY x9ZxJMkUtWn+DkKWBLyZZmz65yL2cqzFbV5tH6SZTk4/v2wpzpm/Lftq6quqhIOR0ooy xescuAVX0d0Nz3P26Vi59jstnK0ugtUZ90ok9gEzmWUzbfPKk14FStstwxaiIHTSDlxT UAPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fZ85//HAL1u8tGRSWBYUwISmaevkCKDhlUIFuHg5k+w=; b=lGG1xMT4wtIt2nBAHD013CeL+EBz3oU84tGiIOoSQW07mTrBjIZCXLNWW8XuLSg1r6 Xx2HwGl3hgElXdbpgkNwKBt1YGW8JYyOoMHVWMMQ/4h2VmMDsvuz7MalUgAwsUaD3Sqn K//Kjhgd5S1mlfl2NcHKwDNoCvT6eygdJcA5o7LLynDS1Y4SiUqNu3HaunNF3jQQks4t snNWfOHXU3zQiDbx1dWlqqkRO05HvRSKb1zpIUQHyh2+oTF7dr650Z2M20bL7kQOcWFO S4rS1pUsfTjqnFx+Cv/Ycd8Wv9q7sxmVcaEA3msh4cNASUMk0yQPSQ6u0tOAf8uVuH6c wM4w== X-Gm-Message-State: AGRZ1gJufXnAK2zxux2a5lfggT4qJhxMKZboRLu177SrBuUovkJAbvyg pd+KHLu6KxtKXZP14SaY97oKMwWVPYfY85B2csqyBA== X-Google-Smtp-Source: AJdET5fr7cyx5bq+p3+fxcFMZ2tJsuWRaF17YcFuwfnFuwqjKzotUVQ0FLqi+ViJSwaxb7uLCev8rTtoX8mwZ+XP5Sg= X-Received: by 2002:ab0:550b:: with SMTP id t11mr509297uaa.31.1541515507533; Tue, 06 Nov 2018 06:45:07 -0800 (PST) MIME-Version: 1.0 References: <20181106102731.GA5280@naina> In-Reply-To: From: Justin Henck Date: Tue, 6 Nov 2018 21:44:55 +0700 Message-ID: To: jabley@hopcount.ca Cc: Mukund Sivaraman , dnsop@ietf.org, doh@ietf.org, resolverless-dns@ietf.org Content-Type: multipart/alternative; boundary="0000000000003e71bf057a000cad" Archived-At: Subject: Re: [DNSOP] [Doh] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 14:45:12 -0000 --0000000000003e71bf057a000cad Content-Type: text/plain; charset="UTF-8" Briefly jumping in to add resolverless-dns@ietf.org, which was set up after the last meeting for discussion of this specific topic. Direct link: https://www.ietf.org/mailman/listinfo/resolverless-dns I also just sent the notes to that mailing list. Justin Henck Product Manager 212-565-9811 google.com/jigsaw 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. > > (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@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --0000000000003e71bf057a000cad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> On Nov 6, 2018, at 17:27, Mukund Sivaraman <muks@mukund.org> 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= 9;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.


Joe

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh
--0000000000003e71bf057a000cad--