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

"Salz, Rich" <rsalz@akamai.com> Thu, 30 July 2020 13:39 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058A83A1157; Thu, 30 Jul 2020 06:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVCOCfcvK-p8; Thu, 30 Jul 2020 06:39:16 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDAF3A1158; Thu, 30 Jul 2020 06:39:16 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06UDVl7A028441; Thu, 30 Jul 2020 14:39:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=uTzo5wYQVG5Z8f/bQlBpfdxZsCaq5KE/8ywlT6D41F0=; b=HzEZbOYJ7SSmSXSmeY6tAZb9aJLi7FF75TniTWatR2BVKf00pduCSD8ZGWvqhuriu57h XC4yhYjkxfKK0McCCDC1DLY8xYnZhDYVuVYLcJ570oAIivT7XjpeIaO0tnTscHlCMDX5 eHP4cd1mW8CKb49MIUBdyzpa/E4xaI0+u/hISCCwNqM/EigHNf1cF1dyDJXw4fE14adP m8qrvptrCNs0H/vT6cEyaeEa4lrwMzHFenDu+UMLaR9vZU62jQdYj/4u5UDocfWEjO3a 6dVez6JtGv4LOBfNGgUbcx7uEVD+tTloK42IbiAm2jGcsVL1Z7kfH7MNUhQh1WnZNbzH 4w==
Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 32gc9db2p3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 14:39:13 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06UDJbID020783; Thu, 30 Jul 2020 09:39:12 -0400
Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint7.akamai.com with ESMTP id 32j464pj0y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 09:39:12 -0400
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 08:39:12 -0500
Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Thu, 30 Jul 2020 08:39:12 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= <ximaera@gmail.com>
CC: Watson Ladd <watsonbladd@gmail.com>, "Eric Wang (ejwang)" <ejwang@cisco.com>, Jen Linkova <furry13@gmail.com>, OPSEC <opsec@ietf.org>, OpSec Chairs <opsec-chairs@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAUf7RAABaakYAAA6JtwAAPo6TAP//wx4AgABOLID//8Q2AA==
Date: Thu, 30 Jul 2020 13:39:11 +0000
Message-ID: <2D916A08-8C24-4BED-8F8A-4DD04B9B1B0F@akamai.com>
References: <DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0@DM6PR05MB6348.namprd05.prod.outlook.com> <CAFU7BAS=ymUPTAGB_fOSrHTG0OajV1n5M1-yOBWxvGam-a89AA@mail.gmail.com> <d9d6d8c2-3916-be28-d01f-f040a28ce361@cs.tcd.ie> <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> <CACsn0cmC=MX8p3HA4cZHnmQwoiE8BLiB1Vo__QEjzVBksvQbrw@mail.gmail.com> <E39579F4-B561-4B12-A9BF-8625B05ACA34@akamai.com> <CALZ3u+brCV_qR9Q6EhaCMSsnohwk2FnjVG=NxOnA9CaBYtW2ug@mail.gmail.com> <D4AEF5C1-7AAE-44EE-B52B-ED0FC6A47642@akamai.com> <CALZ3u+ZWdH5sfuu2KssweZLsqsUeYRCq2cae=7REszubBF5pyw@mail.gmail.com>
In-Reply-To: <CALZ3u+ZWdH5sfuu2KssweZLsqsUeYRCq2cae=7REszubBF5pyw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.32.61]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D692740DCBA6B64795D07F7759D795B0@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-30_10:2020-07-30, 2020-07-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 phishscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300097
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-30_10:2020-07-30, 2020-07-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 impostorscore=0 mlxscore=0 adultscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 malwarescore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300099
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i8SyA63aQhZojomTzgIjluafS5E>
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 13:39:20 -0000

>    In the majority of cases (i.e. delivering preseeded static content),
    no. It identifies as some-1337-garbage.static.example.com, which it
    basically *is*.

No.  That might be the DNS name, but it is not the TLS certificate that the server presents. That certificate MUST have a name that matches the original name that the client (browser, often) present. That's fundamental.

>    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.

CDN's also do things like API gateways, BOT detection, etc.  In some cases, the dynamic traffic manipulation is more in either bytes or connections.
Consider this configuration in a fake language
	<match cond="using-weak-cipher()">
		<redirect>/get/better/browser.html</redirect>
	</match>

Where does this fall?

I agree that if example.com hires a CDN or deploys a middlebox to do those things, there is no difference.

>    Proxy is a proxy.

That's too simplistic. 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?

>is ...  a Facebook-owned middlebox, or is it the endpoint
    server?

What is the endpoint server, if facebook sends you there?

>    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. 

And my point is that there is no such boundary. Or perhaps more accurately, it is a barrier that they don't want  you to see. Just like they might not want you to know about the DMZ and interior network, which are often run by different organizations inside the corporation.