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

"Eric Wang (ejwang)" <ejwang@cisco.com> Wed, 29 July 2020 22:46 UTC

Return-Path: <ejwang@cisco.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 B904A3A08FF; Wed, 29 Jul 2020 15:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VdiRNDs7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Thk4pvOO
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 r3eDTcZ1cW9w; Wed, 29 Jul 2020 15:46:30 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56833A08F8; Wed, 29 Jul 2020 15:46:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28537; q=dns/txt; s=iport; t=1596062789; x=1597272389; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IQoApdB7p8cEUqv+hFSNKp0WtkAs9KV8QSQxwWDtVJE=; b=VdiRNDs7pIh+Lx6bFhmjL6CiLkSyfz8sSKiLYiiLNhQZGXlaD0GsImEe d8QiGVcWRneamdsGvnTdPcKV49Y/YRDbSF36quSCH7CHndkrInmhPcYXj QNmLCG2rgClu5ljmBEm3pwP8TEhX2HiKUDolxU5V/E4E7T2AO65FsVTQN o=;
IronPort-PHdr: 9a23:sEoERBAjM1YrGn4zawTbUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qw30A3FWIzB4LRFhvbY9af6Vj9I7ZWAtSUEd5pBH18AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7ep3So5ngTFwnxcw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6ywDCpT1DfOEFyA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BWAgCK+yFf/4sNJK1XCR0BAQEBCQESAQUFAYF5BQELAYEiLyMuB29YLywKhCuDRgONKpkGglMDVQsBAQEMAQEYAQwIAgQBAYRMAheCDQIkNwYOAgMBAQsBAQUBAQECAQYEbYVcDIVyAgQBARALBh0BASwLAQ8CAQg/AwICAiULFBECBA4FIoMEAYF+TQMuAQ6kfAKBOYhhdoEygwEBAQWFFhiCDgMGgTgBgm6CUktChj8aggCBEScMEIFPfj6CXAEBAgGBMAMRFy6CaTOCLY80EYMrhl2cOwqCX4hbhj+KZQMen3ScU5BHT4NWAgQCBAUCDgEBBYFpJIFXcBU7KgGCPj4SFwINjh4MF4NOhRSFQnQCNQIGAQcBAQMJfI01gTUBgRABAQ
X-IronPort-AV: E=Sophos;i="5.75,412,1589241600"; d="scan'208,217";a="714723825"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 22:46:28 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TMkSLx012613 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 22:46:28 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 17:46:28 -0500
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 18:46:27 -0400
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 18:46:27 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ndMBSHMoDt14a0Xlr7/swN6Sjq9oGGlpFAbr+q2SAZaj7Qi2ThxhunKtIU/s1JjlnB1G4mnHNQziwvm5oMY5KL8GjynA1d4+C/MLi4moZI7UME5m+V8f/oVbM4shyLou1llTqJyPf1Rs+c50s9uMVcTyaZMM11Enxd+ve7JJALetRIwxDEFWEzeqyHsLo8+Al73dvEKA2yDsmQSj2MFwhZB5sFfwvGm+TkNH1LFN2bIp9XGPlZcROgyiFZBX+kgFZBwk1AJVpUzlKLsN8b1li70y/RizBIzF55/E+1XWO7Vwj3w+3lOdVDMHED7oKaayS8SP3t+KIyI5W1nyIt3sGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQoApdB7p8cEUqv+hFSNKp0WtkAs9KV8QSQxwWDtVJE=; b=mcFg/+/9wxNQ5+P7+Hd3Y3pALTPUVKoQNcD6/GLgCAenrK8a1J+7ZNDeh/Ks6JbsUWwsRurM8weMl8RlarfkFjReN6HCRLb/TxtKFG9rpx84b0rWLqv1B7IKjprueJqDvWagomVJLg6dm2yxzsO3LAlGdo/uwwg4/1WYtcfy+kVY60uAKRi/2enAyWk4kx3ip+n6OJhRers1caGBc0b5/rBftWtMA0bbGLw4xWw2zrMRI5cfSQrhjLB2FXIPqwPX9lTPqDMfltszn0za2zCGsR5pC4jh8ePvWsgAUcjCphZDMJw03hkoVDCEzX/5TaZTGESJnSee33yR6uog78SNcw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQoApdB7p8cEUqv+hFSNKp0WtkAs9KV8QSQxwWDtVJE=; b=Thk4pvOOHqJpgpxLuk+bzjl/q4ey3dtLxIBjhlyXp9ZEU16sdtQviNU59cK5o58bYyzDa4yeqelrr2Z95K/jl6w21tME0OBgHbfpyiQWAeKN9/1q3V0XeDNtN/Rw1GJK7nUUfZIffkTTP/rF+0suNbACJKgTIXm783XUNG6kSlY=
Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BYAPR11MB2758.namprd11.prod.outlook.com (2603:10b6:a02:c9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul 2020 22:46:26 +0000
Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Wed, 29 Jul 2020 22:46:26 +0000
From: "Eric Wang (ejwang)" <ejwang@cisco.com>
To: Nick Harper <nharper=40google.com@dmarc.ietf.org>
CC: Martin Thomson <mt@lowentropy.net>, Ron Bonica <rbonica@juniper.net>, OPSEC <opsec@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
Thread-Index: AQHWZUAxl1+CjQkbHU6//l5iRsxvD6kfKasA
Date: Wed, 29 Jul 2020 22:46:26 +0000
Message-ID: <F40B9423-B0D5-4993-8A3D-D875C62951E4@cisco.com>
References: <DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0@DM6PR05MB6348.namprd05.prod.outlook.com> <d9a9ea94-4c4a-40eb-8841-7a92fa31103e@www.fastmail.com> <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <CACdeXi+7oQgcg=-vFqxLnEFtg__6AehWXyE5ey8CBFiw9Vh8PQ@mail.gmail.com>
In-Reply-To: <CACdeXi+7oQgcg=-vFqxLnEFtg__6AehWXyE5ey8CBFiw9Vh8PQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.104.15)
authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [128.107.241.169]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a7fab501-c214-4850-a674-08d8341139da
x-ms-traffictypediagnostic: BYAPR11MB2758:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB2758957CDF7AC81F4B32B6FCD0700@BYAPR11MB2758.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: K5jnIFoIKzep35vYt7XcFKZmBl/gbWlC3KJG3b6c0W9pqYuRJS3GJIlGjfpZTrpXWDgmYkmD33RY8by/nuzQsymK9ALeYDYlOi31vEfN3zWJjw5FQJ6FDUVKY0Gvk8p+cGgQyeoRk1XRKmBc/q18Prt7A8bsWZhCIuLXjLTIj0RE3Q9k/+RJB4/j8++bck/yu0TH2sPTL20shcniJvqS8D32gvIl8K4qAjhWo//eKA8wghBsEOINszCMAF6kcLfNp3NdVIEllFMRDcZNsXb6qGtYKuLJToCG2E/MuKRf9kRuDu9hI9M184eQCkUVk12TDp2XZCgmYLRbb7P9C70YxrBnl9LqYdfSXmCaPq8oT5wCfDGK875kuIdmBzDsClupSqt1UqRTMFf2S2RWFiNKZQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(8676002)(2906002)(2616005)(83380400001)(6506007)(53546011)(5660300002)(316002)(6512007)(36756003)(4326008)(54906003)(26005)(166002)(33656002)(186003)(76116006)(64756008)(66476007)(86362001)(66446008)(91956017)(66556008)(71200400001)(966005)(6486002)(478600001)(66946007)(8936002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 2o87w+P0FJnDAHRE2KbiNl7ML71zaqM4WVH8kBTFVG5VWeOHsgaSERb3JqCU7PPD+iHtm67uMcPu2gKjZNYa2BExBn0TmhLFrbcLePLNsPXTyHHi9S/T9Is8j8vP6gMiaG6AeMQKGEcNtH7RuYNIFg5E8bk71mDeHKqrQPud1U1e1JjdukFPuLr3bisNDJA5hInKG6w03jVFOqIsJpwkUOpJPo/ZEbeftZZ+uLPFsMDxyzR33iMCtgcd+IQrtJNLPqsbGxOf8P7DD7m4QkB81aBB3rUmCv2GqJ9bOWOtocngXpCqfTwbrjgZhjpEHKrG61rw/FX4f0j5SWg5CAyvbWIFqv9KBMcgVOfVtpvLHxUC1+PTRfPRG0pZxtCNa6m8GUDSKTQv/CbmP74Y5/thH5UiIQaHmNdd6mQRbiPf3YFQhm7JHBs9k/+DmYL3zuhvGf7Es6Lz1G6+r5Etx/8PDwms6I2SxMM5IteCH2/4jpiCPqNT81/fk0B+yiTM3HTYEpi5QqIJZbldRT2RjGMNcze90Ha+BecR9h7VgJGOjGgT0DGY/DsHccmjQMo9HEuPQ70t36YuwBZd/sew7FpurHc4tCWtSwoVECHeS6gvfgXpqzoZXtHFevmj2GDefrksWLXIejamNTyvesL/Zd7fpw==
Content-Type: multipart/alternative; boundary="_000_F40B9423B0D549938A3DD875C62951E4ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7fab501-c214-4850-a674-08d8341139da
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 22:46:26.1534 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dNx5ytY0iyjdltCaQuJk4+URVneP2YTCxG1pTRt0wZCbF3EWgy3nbdPyAQySJ8RhARwhd0h5GeC+s/2meiWXJg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2758
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mN3r9E_TQfCaYbsdxM1Fx_XhOvk>
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: Wed, 29 Jul 2020 22:46:34 -0000

It looks the “selective proxying” topic requires a full document to analyze it.  The co-authors discussed and it would be a good idea to remove it from this draft.  We will made the updates.

The concern is valid that "there's no guarantee that the server will respond to the client the same way it did to the proxy, or even that the identity the server presented to the proxy is the server's real identity”.  We also have to dive into the details about which piece of server responded information is being used for selective proxying, and how often/what to do when that changes.

The "malicious client and cooperating server” problem exists outside of a TLS proxy deployment. There are many ways to circumvent a TLS proxy if one controls both sides.  The document touched it in Section 5.2<https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-00#section-5.2>.

Some TLS proxy implementations violated the RFC in the past, but nothing in our draft suggests that a modern TLS proxy does or should violate the TLS spec.  It was the motivation of this draft to help reduce/prevent non-compliance, as mentioned earlier.


On Jul 28, 2020, at 5:34 PM, Nick Harper <nharper=40google.com@dmarc.ietf.org<mailto:nharper=40google.com@dmarc.ietf.org>> wrote:



On Tue, Jul 28, 2020 at 2:19 PM Eric Wang (ejwang) <ejwang=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Thank you for the detailed comments.

The scope of the document is limited to proxy at the TLS layer.  Explicitly out of the scope is inspection of the proxied record data.   Will clean up derivations from this scope.

It was the intention to cover selective proxying however, because that is a practical requirement for an actual deployment.  The intention was to discuss the TLS layer attributes (e.g. SNI, Server Cert) that could be used as input for the decision.  The document also stated the requirement to gracefully remove the proxy from the session when needed (and possible).  But the criteria for selective proxying decision, being compliance, privacy, risk level,... are out of the scope.  The decision making often falls under the larger “policy” domain and is controlled at system level outside of the proxy.  It also left out discussion on the detailed mechanism which was deemed as implementation specific.

In any case, the proxy has to conduct selective proxying in a safe, non-disruptive manner. This may require more design work as you pointed out.  The document could describe possible mechanisms so that an acceptable practice could be discussed.  We are open to other ways to shape it.

An acceptable practice MUST include not violating the protocol invariants in RFC 8446. It is not possible for a proxy to obey the protocol invariants and selectively proxy based on the contents of the TLS handshake between the proxy and the server a client wishes to connect to.

More inline...

Probably the worst problem is rooted in Section 5.1.  The introduction establishes this as being about proxying, but there are several places that talk about not-proxying sometimes.

Selective non-proxying opens the document up to a whole new set of problems that arise from poor designs for deciding not to proxy.  There is not nearly enough detail here to address this problem properly.  A "good" design for selective TLS proxying does not seem to be the basis of the recommendations.  I'll give a few examples of problems.

From the Section 4.8 again:

the TLS proxy MUST conduct proper TLS protocol checks to avoid false identification of TLS handshakes, while taking special care not to contribute to protocol ossification.

This practice has been directly responsible for more ossification than intermediation, no matter what qualification exists.

If per-destination not-proxying is required, the proxy can connect to a server, determine that the server is on a non-proxy list, and then complete the handshake with the client (with a caveat regarding ECH here).  I can guess why this doesn't happen (it's expensive and see also Section 5.4), but that doesn't excuse the practice.

The following text from Section 5.3 is deeply problematic:

  A decryption policy decision MAY be made based on the server
  certificate or other trustworthy parameters.  To verify possession of
  private keys that are associated with a particular server
  certificate, the proxy SHOULD complete an out-of-band TLS handshake
  with the same TLS server IP address and TCP port as targeted by the
  TLS client.

It is possible that the authors misunderstand how TLS works, but this check won't work.  Not only because TLS 1.3 encrypts information, but because this is only necessary if the proxy forwards a ClientHello from the client to the server.  At that point, it is too late and the damage has been done (see Andrei's review).


Unless I misunderstood it, the document is suggesting the same as you listed.  Basically, the proxy makes a separate connection to the server as a client (“out-of-band” wrt to the originating client-server connection), retrieves the server’s certificate from the proxy-server handshake, and determines whether the server is on a non-proxying list or not.  If on the list, the proxy forwards the originating client CH as is to the server, and steps aways from the originating client-server handshake.

The proxy MUST generate a fresh ClientHello when doing this (something Andrei and I previously mentioned). When the proxy makes its separate connection to the server, the server can behave differently when responding to the proxy compared to when it responds to the client, and could present itself to the proxy as something innocuous that should not be proxied. Assuming at this point that the proxy has held onto the client's ClientHello (waiting for the response from the server to the proxy's ClientHello), the proxy decides either to intercept this connection or allow the client's ClientHello to go through to the server. When the proxy allows the client's ClientHello to go through to the server (without interception), there's no guarantee that the server will respond to the client the same way it did to the proxy, or even that the identity the server presented to the proxy is the server's real identity.

If the proxy copies extensions unknown to it from the client's ClientHello to its own, then it will not be able to parse the response from the server when the server acts on those unknown extensions. This caused a year of delay in finishing TLS 1.3, and is bad for everyone. A malicious client and cooperating server don't even need to use an extensibility point unknown to the proxy to evade a proxy selectively terminating connections based on the TLS handshake between the proxy and server.

This sort of selective proxying is fundamentally broken and should not be recommended as a best practice.

There are additional considerations in this approach (latency etc.). The document intentionally left out the details to implementations, but could also cover them if needed.




There are a bunch of places where pure proxying - as described in the introduction - is not assumed.  This leads to the same problems already cited.  For instance, in Section 4.2:

The proxy MAY remove cipher suites from a client-initiated Client Hello message, add new cipher suites, and re-order them in the proxy-initiated Client Hello message.

Will clean up those texts based on this and other discussions.

Best,
-Eric




_______________________________________________
OPSEC mailing list
OPSEC@ietf.org<mailto:OPSEC@ietf.org>
https://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls