Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp

Töma Gavrichenkov <> Thu, 30 July 2020 13:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 519153A1110; Thu, 30 Jul 2020 06:14:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n0XqV5uWAPL2; Thu, 30 Jul 2020 06:14:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CC723A0AD3; Thu, 30 Jul 2020 06:14:23 -0700 (PDT)
Received: by with SMTP id e14so547141ybf.4; Thu, 30 Jul 2020 06:14:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=28jY7w84lj7SN26GrM75tOBbV0QwHRjxyiBxNfnAu98=; b=bAOObChKKt1px5WvUa/PzpThnamUyL+K5p9qd/mMa69MB3173COQw6oQHsIO+sYuUG 1IF9f/IKvJWKr8nKja+1ZppQWWIEifypscIjhKkpv3kY0tCwB5A2vHoN41CfOIrqT3HH UMCScN3PVV8HiYuUlUkhQb4L0tHH1Wa669y8+ihqSUUV5zM7mtXC6zQVi+rTQ+d86AXC YrX2/uVSMRV0O3AK2c3H3DlYzfFEBVm4j8gLzvfM4YQw7g+KTCTsf8BDfaF9KLAKfLz/ A5uaO1n0UcObVj1MYSL1W0EI71CO9pD9RGKveVn1capA0ZE4V3UbFAka3Og2XEN/f+pt 7Olg==
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=28jY7w84lj7SN26GrM75tOBbV0QwHRjxyiBxNfnAu98=; b=gIixfMPRvZX9xTfjCVShDoqQC2wkaVHF9my3h/GP16PtZq2Z7LBwCXRysEh7woVuqc kCymuKyUNm0bdhkLeGCgp2RP3BVlHSk0JHaV89TpqADtxsmiTR+DL2o7Vl790eTjoPhM voemdAhX/qe1GJy2X+dkpmmrx6DItt75lyI/XZdGss46eSJdnVrt1y+BjmBcpICCBtmM LgZ4PRqB5a5A+ssrW2y6/LCvnbYURN0dfhLFafD4fmFOGXHhZ5a1U1EVmlouoI1RqpaV T62Vhle9jM3sYkmK77vX4IBBn2iBVpA1iwUsvupPuKtivS0XFciTkbs4EmYjG0HNB6zd lJ0g==
X-Gm-Message-State: AOAM530q1l0AXk0x26CfWnck84/Jevx/jnzTgw6fFrrCUhAoH30+Qi+X L5+AhER1Vwa8MG/2GF3yHA80txBOjVabDW7diFA=
X-Google-Smtp-Source: ABdhPJwwf7qmfeUXJR/zqGG373EVykhsz/kEokfGgRIoaRbzHWGaMhg03+ZoH4HMy4x8F72fdu0ZvmDq/zjqsspc5oc=
X-Received: by 2002:a25:5557:: with SMTP id j84mr32942423ybb.461.1596114861854; Thu, 30 Jul 2020 06:14:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Töma Gavrichenkov <>
Date: Thu, 30 Jul 2020 16:13:09 +0300
Message-ID: <>
To: "Salz, Rich" <>
Cc: Watson Ladd <>, "Eric Wang (ejwang)" <>, Jen Linkova <>, OPSEC <>, OpSec Chairs <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Jul 2020 13:14:49 -0000


On Thu, Jul 30, 2020 at 3:33 PM Salz, Rich <> wrote:
>> It is (in all but a couple of implementations I think)
> a *proxy* that the origin has contracted with.  Could
> you please elaborate on your point?
> It has a TLS cert that identifies itself as the origin.

It depends!

In the majority of cases (i.e. delivering preseeded static content),
no. It identifies as, which it
basically *is*.
The manner in which the content (hopefully uploaded by the origin via
an end-to-end encrypted connection) propagates to edge nodes is then
up to the implementation, and it is contained within the area of
responsibility of the CDN operator.

However, there's a minority of cases where a CDN is also used to
deliver *dynamically generated* content which could not be cached,
e.g. because it is only available to authenticated users.  In this
case, the CDN in fact impersonates the origin, processes all the
authentication data, and the only way to implement that is proxying
across different areas of responsibility.  How's that different from
what middleboxes are doing is not clear to me.

Proxy is a proxy.  There are various kind of proxies probably also
doing something which is deemed useful to their owners and users,
which doesn't relax the statement that such proxying is not endorsed
by the IETF.  The intent and purpose behind proxying are IMO in scope
of model-t and are, accordingly, out of scope here.

> How is it different from an origin that uses load-balancing to send you somewhere?  Is a CDN or intermediary, or is it the origin?

Is a Facebook-owned middlebox, or is it the endpoint
server?  (And this is *one* of the reasons I won't trust Facebook for
anything sensitive!)

Again, I think this is more of a topic for model-t.

The main difference though is that the data crosses the boundary
between the areas of responsibility in a way which is not transparent
to me.  It is a common approach to allow insecure connections over the
Internet from the edge nodes to the origin, and I have no way of
knowing if this is the case for the resource I'm currently using.
There are also more subtle differences but I think I've long crossed
the boundary of the off-topic area here myself!