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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE2103A0528; Thu, 30 Jul 2020 07:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=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 BOEZf8XjIqII; Thu, 30 Jul 2020 07:57:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::b41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECFDF3A0796; Thu, 30 Jul 2020 07:56:57 -0700 (PDT)
Received: by with SMTP id c18so7163843ybr.1; Thu, 30 Jul 2020 07:56:57 -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; bh=N/gheHoS4imCYLehim/GTLr//GfMVTVlh86eFfYgzlc=; b=etjGwKP7aWyZLP0N4s1YeMpmMigpStIGXFZmo5IHDHvvpwdkqAxcAOwPmV2wB33WmD zckl2hg83s3jpjQSVIpg1IxEBmjrlG9APJapE/34nA4BEeZaP+c9wZ1fJ0dbrGnZLIib MtLnDSUeoOVVBJ1S4aJ0jgHRfTps97zI0cMEe/WJcK1M7lTqmuLihOeofyyJPtnvH9L7 sUpByccg++PPEZ/rIACnfyZ10JLtpQo2n6ikO75kiPzqRLeQzY+l4RzPvamN4ySP0fCz F5x3bhkOof00IDaLgHuovGity9UVjaXTIyfCHKU8ZLbPDdv30sx3IefAesDu8lX1O+06 V3gA==
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=N/gheHoS4imCYLehim/GTLr//GfMVTVlh86eFfYgzlc=; b=lfNdwPimne4MxNECMyYJDuixKDGKK8jMOZvjUMrtY0PiIA6+Xpxteje9HFYi/K7Q5d 7WcWrHLqFFs99BdJP7DkQuxSTqubeKa0iWUR1ycmQRTfydhvVfeLIjl6k9ZAAKVFfKV6 WmnqtACB8a1UASRUYGhjbDAcArcx9N7cOoQEc5Zzx5K/OhXvpmxfZsbsUIn6r+2/AD1H S+onTgAYZwwUc1KLWvrPn076sKMOtdMI2qDHTI1ZAS1T4PRXtIn7xWln9Pj3P9/Dfyc7 Jv40FaIzkmlk9lXrXQkStST9PMKyBcM2vRHvhsB74xthgLveO8nj+atlfMCj66CRZssX 9vRg==
X-Gm-Message-State: AOAM532gBTXYgkYPx1YdKUe4SO2UeVAf1ChnrXCK3d00puZIKZ6Ur6cy SrlIlQrCI4Bk2vSNvKw28W94SRF82F5e9xdXGGc=
X-Google-Smtp-Source: ABdhPJzXyAe+P4D6aN5Vzza4yRv0+GT4y9XcK1GfKjcpjTJXcAZhI44ReKR0srl+uM0voivfv3yBbwqnl8JiRGfP6PY=
X-Received: by 2002:a25:be45:: with SMTP id d5mr5212018ybm.444.1596121016910; Thu, 30 Jul 2020 07:56:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Töma Gavrichenkov <>
Date: Thu, 30 Jul 2020 17:56:44 +0300
Message-ID: <>
To: "Salz, Rich" <>
Cc: Watson Ladd <>, "Eric Wang (ejwang)" <>, Jen Linkova <>, OPSEC <>, OpSec Chairs <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000003b466405aba9e2cc"
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 14:57:36 -0000


On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <> wrote:

> We have a product, site shield, that customers can use to limit the IP
> addresses of who can reach their origin server.  Everyone else is blocked.
> Some use that to make sure that *only* Akamai servers will talk to them,
> and that everything else goes through us.  Is that a proxy? How is it
> different from terminating TLS in the DMZ and sending it inside? How does
> the client know?

I don't know, and this *is* the problem.

I may be connecting to the service from a network I don't trust with my
information, and I have (almost) no tool to tell me whether it is served
from a different network via a secure connection *or* it is served from an
edge node deployed *in the same network I don't trust*, that node being
connected to the service through an unauthenticated channel.

Like in [1], where this unauthenticated channel is being marketed as
"end-to-end encryption".  This approach basically defies all the end-to-end
encryption efforts.

When it comes to static content, with all the JS security implemented, this
is mostly fine.  Dynamic content is a very different story.