Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal

Ryan Sleevi <> Tue, 10 July 2018 17:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2C13131017; Tue, 10 Jul 2018 10:51:59 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Pf7cJMXCejwn; Tue, 10 Jul 2018 10:51:57 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E305B130F04; Tue, 10 Jul 2018 10:51:56 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 785576001608; Tue, 10 Jul 2018 10:51:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type;; bh=RhhEoZ408ThwhoEVDri3uLd8KdA=; b= NcZ6oVC9iC0n/haNfPuiO056XcNWFnwSA1nBGp9uMDaxH3HDe3uK9SXCjXQPw2X+ QnfZ+PeRhmFI/nfLTKGNkw/rDFPz4jYXYnZKIyq4tpXNxYXomhQZ/8LCC9nN5toZ MdBDhm20eyjTavkTusJXb8v4JFPNslHTjiGuVwdaE3I=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 533D16001602; Tue, 10 Jul 2018 10:51:55 -0700 (PDT)
Received: by with SMTP id w16-v6so10403592ita.0; Tue, 10 Jul 2018 10:51:55 -0700 (PDT)
X-Gm-Message-State: AOUpUlF0uDdKGztHj7e0ENyZG4abAUluV1xMFcLjpCeLvicrUV9tZx5P FzC/EZ05ulab+CvgvWbdelOMlgRIVtMA4zyohKk=
X-Google-Smtp-Source: AAOMgpfuksUe3Ga9juzC5CUfobAyFAYv3gmOA6kuj2PLZqAxznoaKVgCcwYiLYtmDX0wdZMyFG3H8QfVpjwvaq4KoGE=
X-Received: by 2002:a24:62d0:: with SMTP id d199-v6mr7502623itc.91.1531245114637; Tue, 10 Jul 2018 10:51:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a02:244:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:51:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Ryan Sleevi <>
Date: Tue, 10 Jul 2018 13:51:54 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Adam Roach <>
Cc: Ted Lemon <>, Joe Abley <>, DoH WG <>,, dnsop WG <>, Paul Wouters <>, Patrick McManus <>, Philip Homburg <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="0000000000001f45cb0570a8c9ed"
Archived-At: <>
X-Mailman-Approved-At: Tue, 10 Jul 2018 11:07:07 -0700
Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "DNS Resolver Identification and Use \(DRIU\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2018 17:52:00 -0000

On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <> wrote:

> On 7/10/18 11:41 AM, Ted Lemon wrote:
> On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <> wrote:
>> > But this is really equivalent in just about every important way to
>> sending the normal <img src=""> along with
>> a pushed DNS record that indicates that "" resolves to
>> "" -- and this latter thing is (to my understanding, at least) in
>> scope of the conversation that Patrick is proposing to have.
>> My question is why you would involve the DNS at all if all the
>> performance-based resolution decisions can be made without it. You're
>> just adding cost and complexity without benefit
> The ip= modifier would be a great way to arrange for something to look
> like it came from a different source than its actual source.   I'm sure
> there's an attack surface in there somewhere.
> Keeping in mind that the certificate provided by whatever machine you
> reached would necessarily have to match the URL's origin, this is very much
> one of the questions that is being asked: is there?
> /a
Yes. Consider Site A (foo.example) and Site B (bar.example). Both point
themselves to CDN 1, which then obtains a certificate for both their names
in subjectAltNames. Site B then decides that CDN 1 is an unreliable
partner, and goes CDN 2, updating DNS appropriately.

This is the same problem in considering the HTTP/2 coalescing without doing
DNS resolution (either because of poor security posture or by combining
ORIGIN + Secondary Certificates). RFC 8336 briefly touches on this ( ) but doesn't really explore
the policy implications of the proposed or recommended mitigations.

If you start with no mitigations, the net effect of both an ip= or a
DNS-ignoring ORIGIN frame is to effectively treat the certificate as a
825-day DNS TTL. By framing the problem as "What's the worst that could
happen if DNS entries had their TTLs ignored and were cached for 825 days",
that might help explore things further. The suggestion of OCSP reduces that
TTL to 7 days (effectively; due to Microsoft's contractual requirements on
publicly trusted CAs), but that's still substantially longer.

That's why involving DNS is at least relevant to that discussion,
especially given that publicly trusted certificates are themselves
predicated on DNS. Further, considering that the CA only has to validate a
DNS once per 825-day period, and can issue unlimited 825-day certificates
during that period, then the effective extension of relying solely on
certificates 1650 days minus a second.