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

Ryan Sleevi <> Thu, 08 August 2019 23:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2ADA112003E for <>; Thu, 8 Aug 2019 16:51:09 -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 ApbueISxL_q6 for <>; Thu, 8 Aug 2019 16:51:07 -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 D2089120025 for <>; Thu, 8 Aug 2019 16:51:06 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hvs8h-0001Wa-9B for; Thu, 08 Aug 2019 23:48:11 +0000
Resent-Date: Thu, 08 Aug 2019 23:48:11 +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 1hvs8e-0001VW-6T for; Thu, 08 Aug 2019 23:48:08 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hvs8c-000206-8u for; Thu, 08 Aug 2019 23:48:08 +0000
Received: by with SMTP id r12so58081342edo.5 for <>; Thu, 08 Aug 2019 16:47:45 -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=ZkAwXwymQ7MBOF4ky+QZi34lUcek8rsXVfWhnwiCd0c=; b=nbULF8PF+xiviru/eTslspa6l44EZWf85CHKe24ROGMavFMWkRreUb9Y/B5vtkn2Aa hm/5LLz/efXex23PGH8sJtJ45vuf3Af483hP1BhK8M3AzO+VnS5Oy+6wIzohBTDwucC1 158VsnE8tASHu6s6b9yI7AZXOdoz6H7xXzNqhSbbryNGCwUhGCts2FWkDlAQFt4ocOzC F4Ox2VbyBGmrSFfdySugWivIZcXkx2t8ZnxCYp4QXi2fK9TJQ7dhORaXs2uXRAxdDYWg 9bQWq1hbSy5XZ6Hm1S7YtKpqNtVJ01WGzFD8GEdU/55SuQIjs9OttnllYpJDirl5Mz+u rGtg==
X-Gm-Message-State: APjAAAVnId+05/lPxzvy077hMElFiemkYVxBIDEBBJ7qgg2fylfcC0IR NcPELgdpPKmV8MqujJWStkWshNKH
X-Google-Smtp-Source: APXvYqzNvGka9hpj6QIVdsUfhArHZvmO7IgxHaQreJt3/TmuZw8SKtzo9c/gDTTmnsj4qW/nP/lhUg==
X-Received: by 2002:a17:906:3108:: with SMTP id 8mr15802334ejx.196.1565308064227; Thu, 08 Aug 2019 16:47:44 -0700 (PDT)
Received: from ( []) by with ESMTPSA id g18sm15662562ejo.3.2019. for <> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 16:47:43 -0700 (PDT)
Received: by with SMTP id x1so46637989wrr.9 for <>; Thu, 08 Aug 2019 16:47:43 -0700 (PDT)
X-Received: by 2002:a5d:5607:: with SMTP id l7mr20997105wrv.228.1565308063092; Thu, 08 Aug 2019 16:47:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Ryan Sleevi <>
Date: Thu, 8 Aug 2019 19:47:32 -0400
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Watson Ladd <>
Cc: Ryan Sleevi <>, " Group" <>
Content-Type: multipart/alternative; boundary="000000000000109910058fa3af92"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Scan-Sig: 1hvs8c-000206-8u 486ac60638af48b32e9fd2a0a51cd8da
Subject: Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04
Archived-At: <>
X-Mailing-List: <> archive/latest/36957
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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

> > 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 don't see how revocation is necessary.

It was meant to draw attention to an existing requirement of Cloud
Providers / CDNs which is not currently being practiced, despite it being
contractually required of them.

> If the certificate frame is
> never sent by the server, or even if it is sent, once the TCP
> connection is restarted and the frame is not sent again, the
> connection is not reused. Why would the mere existence of a valid
> certificate lead to it getting used in a certificate frame?

I think you may have inadvertently shifted the requirements. Originally,
you stated
> 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

I think that relies on certain assumptions about how it may be deployed; it
doesn't seem like we should be making assumptions of use when talking about
security considerations. However, even if we assume those assumptions hold,
then we can assume that a user who transitions from one cloud provider to
another may find their original cloud provider still claiming authority
over the connection - for those subresources, link headers, etc. That still
represents a real and meaningful security risk.

Let's imagine I am news.example. I use and configure CDN 1, to which I push
my latest news stories and content. Later, I decide I'm going to switch to
CDN 2. I initially start by pushing my content to both CDNs - ensuring it's
fresh regardless. I then transition my DNS to point to CDN 2 - still
populating fresh content, so long as my original DNS TTL was set.
Eventually, I stop updating CDN 1 with content, and my latest news and
corrections are only found and distributed by CDN 2.

Now, imagine I go to social-media.example, which happens to use CDN 1.
Someone links to a story - or subresource - from news.example. CDN 1 is
ever so clever, and says "Hey, I'm a valid authority for news.example, let
me use secondary certs so we can reuse this connection [along with the
ORIGIN] frame". The client - which we'll presume is a browser - says great,
and now uses the connection to social-media.example via CDN1 for

The user then attempts to visit https://news.example - but lo and behold,
the browser, thinking it already has a connection, ends up reusing the CDN
1 content - and now we're seeing an old page of not-updated content! Had
the user not relied on secondary certs and ORIGIN, they would have reached
the actual, fresh breaking news.

It might seem like this is conflatable with 6.1 - except 6.1 is relevant in
the context of maliciously issued/unauthorized certificates. In the
scenario I just described, news.example had authorized both CDN 1 and CDN 2
with such certificates, and the mitigations described in Section 6.1 are
not applicable.

You might say this is news.example's fault, for not rejecting CDN 1's
certificate when it transitioned authority. This is BygoneSSL - and why I
mentioned revocation. I don't think we'd suggest that CDN 1 is necessarily
behaving adversarial - after all, news.example previously authorized them.
However, CDN 1 doesn't know that news.example now has a relationship with
CDN 2 (again, c.f. BygoneSSL), and thus doesn't know it should stop
advertising to serve news.example via CDN 1's connection.

Does that resonate more?