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

Watson Ladd <> Fri, 09 August 2019 00:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8172C12007A for <>; Thu, 8 Aug 2019 17:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-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 iwaE3jV_9Jwo for <>; Thu, 8 Aug 2019 17:36:17 -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 3348112006A for <>; Thu, 8 Aug 2019 17:36:17 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hvsrm-000810-Ds for; Fri, 09 Aug 2019 00:34:46 +0000
Resent-Date: Fri, 09 Aug 2019 00:34:46 +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 1hvsrj-00080D-La for; Fri, 09 Aug 2019 00:34:43 +0000
Received: from ([2607:f8b0:4864:20::82f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hvsrh-0003Lm-OM for; Fri, 09 Aug 2019 00:34:43 +0000
Received: by with SMTP id w17so13576575qto.10 for <>; Thu, 08 Aug 2019 17:34:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=s9mXxf4NruBAY+xk0/cubW/pJVbHD+fZ79UskKu00jY=; b=MwwL4jGynQhKQs5Y878KbmPUO3wA3dNVuu1pbRDOh774IsqAN93p+hVFg5gGhzbT5g 04rLl1FYO5YuocXu9Y/wec7hKtSQHOHXmfK6jRvq7fYvjcJVaHtgTUmnfOgXPK2ev4Vq ih7DezZBMXnqJ/K8bX6PoaOK7oh/HsLtp9TZg=
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:content-transfer-encoding; bh=s9mXxf4NruBAY+xk0/cubW/pJVbHD+fZ79UskKu00jY=; b=F4L+36LHi6aPoy9R7aPVfUC2WCiAGo2692ZJp5bpUbu6twqEMg2hCSIgmKTsfozwmi aa/WhWWryc1EadVx19jToPiDPsvoUJkAb5zzzUvi34ciZo6AkDbBS43mrIVswP4CSgs4 siVp3ZiGxrmQle/EFvl/wtNUmWdst41HB+Rj5JhYHaAo/859ku5v9JvCaNj27jhxu+1F 3Qtp2jThDjfAjCS+dQz0bEqOCsoihRSFcqaFGv7Ts/FwaenSeQqr7fPZARfIfS0cFN/V vWU8ifwpxNVtQSnzAK5wQ7ayYgOtBbteG2XlsJqh8s9ii9jKioTsdH3TM8s+cbWAxtGV 5glw==
X-Gm-Message-State: APjAAAXtQADAsKF6cFcuHZVgN/GzKPHtCWvKr6j6xEiqaWBtcNRIqc9r wLA6nhsQSEkkVSBBqI9sQl+jiunEAiAGPxne531hwHwf5+4=
X-Google-Smtp-Source: APXvYqzwHGXvPaBshX+oVJhyuW75jr+UfuUzZLgbAfsBHAG9lZeDF4SuVBvG/pydO5fLVx8ur6RaFiinsX75U92Ey0A=
X-Received: by 2002:a0c:acab:: with SMTP id m40mr15994494qvc.52.1565310860462; Thu, 08 Aug 2019 17:34:20 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Watson Ladd <>
Date: Thu, 8 Aug 2019 17:34:09 -0700
Message-ID: <>
To: Ryan Sleevi <>
Cc: " Group" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2607:f8b0:4864:20::82f;;
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hvsrh-0003Lm-OM 7e32b6d283d0f3d34ca2983f7820df9e
Subject: Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04
Archived-At: <>
X-Mailing-List: <> archive/latest/36960
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Thu, Aug 8, 2019 at 4:47 PM Ryan Sleevi <>; wrote:
> 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.

Agreed that it's a change from the current properties.

> 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 news.example
> 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?

My only objection to the description is to a single word, would,
implying an inevitability, vs. could, a possibility. The rest of the
security considerations in this very document are worded with could,
and given that we both agree it is an issue, it should be solved not
by education but by some mechanism to deal with the problem, the same
way CDNs provide a purge mechanism to handle issues with HTTP caching.