Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04

Ryan Sleevi <> Thu, 08 August 2019 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3260C12003E for <>; Thu, 8 Aug 2019 15:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 329n102nAoK0 for <>; Thu, 8 Aug 2019 15:56:24 -0700 (PDT)
Received: from ( [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBC1A12002F for <>; Thu, 8 Aug 2019 15:56:24 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hvrIl-0001kf-Io for; Thu, 08 Aug 2019 22:54:31 +0000
Resent-Date: Thu, 08 Aug 2019 22:54:31 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hvrIi-0001jq-NT for; Thu, 08 Aug 2019 22:54:28 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hvrIg-0000kk-TV for; Thu, 08 Aug 2019 22:54:28 +0000
Received: by with SMTP id i11so29283291edq.0 for <>; Thu, 08 Aug 2019 15:54:06 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MxWSnm2MMRi9+6XPHc3hHNFdgzlziUYnKg+10bObzRM=; b=UH2OsM0AtNsp5bYNoONZV6ypvRH9Fp4HSOhePOhwM6FWvBCMlm3pUThz/QLdfb1QdD Q58BfQ4uvOM0McXapGe6YUdEaN2WNnoko8nM1hA5aru0EpamSglETqhGwh33YhGBIkc2 zrWZqiPOq0vHCjF3jHqiTOsDVON7WWbE1m1CMr1UmlHQa/KDrudCIE7mlXTwx+NCUktL h0urRLhl6IMfaMvkceSsNpVpxMXLd9SRULcDb5aOT0AByNA0MwjMI5ODKCn153pNuyrq uASrNaDzy9Quk2xlbvd+jml0o4nT9POq/DFu0tdrc9we60vXmOT5DOK7YRFZuPYQ3ywt OBwA==
X-Gm-Message-State: APjAAAXKqiFB4Q6zK5Nez2ePjb8SxZlvxnxv5zx+LFTbNxgGupairvdS rpoaZbokO6uIbvw/84DCj/AdGmzD
X-Google-Smtp-Source: APXvYqwuHV3Vz7dsaoDwJmoLfdM6NNyikC+WepHMfdoKA1z40OvxOq4PZTsrzSRoFte79l6cmmzzEg==
X-Received: by 2002:a17:906:304d:: with SMTP id d13mr15143049ejd.99.1565304844944; Thu, 08 Aug 2019 15:54:04 -0700 (PDT)
Received: from ( []) by with ESMTPSA id u24sm15769568ejr.20.2019. for <> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 15:54:04 -0700 (PDT)
Received: by with SMTP id e8so4668642wme.1 for <>; Thu, 08 Aug 2019 15:54:04 -0700 (PDT)
X-Received: by 2002:a05:600c:2292:: with SMTP id 18mr1319558wmf.156.1565304844307; Thu, 08 Aug 2019 15:54:04 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 8 Aug 2019 18:53:53 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Watson Ladd <>
Cc: Ryan Sleevi <>, " Group" <>
Content-Type: multipart/alternative; boundary="00000000000035d475058fa2ef28"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Scan-Sig: 1hvrIg-0000kk-TV 8a3e7031796f7c78acb6647c24fc34be
Subject: Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04
Archived-At: <>
X-Mailing-List: <> archive/latest/36955
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Aug 8, 2019 at 6:26 PM Watson Ladd <> wrote:

> On Thu, Aug 8, 2019 at 8:00 AM Ryan Sleevi <> wrote:
> >
> >
> >
> > On Thu, Aug 8, 2019 at 8:27 AM Watson Ladd <>
> wrote:
> >>
> >> Section 6.4 seems a little strong to me: it's unlikely that $CDN will
> claim control of all origins it could claim authority over on a connection,
> but more likely that it does so for ones in subrequests, link headers etc..
> >
> >
> > From a security considerations point of view, isn't it more useful to
> describe how it potentially could be abused or misused, rather than assume
> how it's likely to be used?
> >
> > That is, is the argument that the Security Considerations should be
> guidelines for servers deploying it, rather than clients implementing it?
> The lack of in-step synchronization with DNS seems incredibly important to
> implementor's security assumptions, and thus important to call out, so I'm
> curious which bit is seen as a little strong?
> For benefit of those who  haven't read the draft, permit me to quote
> from the document:
> > After the owner of the domain has redirected traffic elsewhere by
> >  changing the CNAME, new connections will not arrive for that origin,
> > but connections which are properly directed to this provider for
> > other origins would continue to claim control of this origin (via
> >  ORIGIN frame and Secondary Certificates).  This is proper behavior
> >  based on the third-party provider's configuration, but would likely
>  > not be what is intended by the owner of the origin.
> This is not inevitable, as 'would' seems to indicate, but rather
> possible, as 'could' would indicate, and depends on what the third
> party prover (third party to whom?) has configured, which in some
> cases will depend on the customer (entirely possible it is opt-in? Who
> knows what will happen). This doesn't seem to be clearly relevant to
> HTTP clients as written, vs. 6.1 which discusses the lack of DNS
> hijacking need to exploit a stolen certificate.

Do you know of many cloud providers/CDNs that start rejecting
configurations the moment their customers point their DNS records elsewhere?

I’m unaware of a single one; certainly, unless they did so, this situation
does seem an inevitability. For example, I’m similarly unaware of cloud
providers today that both provision certificates for their customers and
actively revoke certificates when their customers point their DNS
elsewhere, which is currently required of all Subscriber Agreements with
any publicly trusted CA. Last year, research was shared to that effect,
under the name BygoneSSL, showing that it is rarely practiced.

I see the distinction with 6.1 as being the difference between malice and
ignorance, but both share security consequences that implementors - on both
sides - should be aware of. Simply highlighting the malicious case seems to
do a disservice for the far more likely case resulting in ignorance (of DNS
changes by the DNS holder) that would lead a CDN/Cloud Provider to
inappropriately advertise, on the basis that it has not yet revoked its