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

Roelof duToit <> Mon, 27 July 2020 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D07AE3A0BB6; Mon, 27 Jul 2020 13:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zsm0vWtuV9Dc; Mon, 27 Jul 2020 13:32:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AE743A0BAE; Mon, 27 Jul 2020 13:32:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1595881942; cv=none;; s=zohoarc; b=Kx6nsdIXGp39ohLm0KdXnZo4M6WXhEEoNYFP9r3txzXq37qEsa8/h/BOb0GAC69TvLXIFKwOPT+2AEZ7BA83qOadgpYleMcrfuzZ2XbcMuqMxejmpkOS8K4m2JJiD0kJQ6eTrdznKnntGGtlJTDVAFaTCOSHT3HQPSamqIeJiLU=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=zohoarc; t=1595881942; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=0BSEdOkrLoulAegP1zOnaqO+oja5CjqiTy3ulevd3+U=; b=VwyvgOXx55xKHiT4O347XqXlgI1PrmKIgspE9GJEBuIoyEC8xwVFTbDRJ5+dw48zRD1hXfyeSKlkHJrO2k/85aSAyehumvnfS7GwkuVN/XbVnr2QUICrNHWT8Q8rG6J5D236cP9cXIwZD28m24aIcsar6e2//D9dzxA54Cri1fc=
ARC-Authentication-Results: i=1;; dkim=pass; spf=pass; dmarc=pass header.from=<> header.from=<>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1595881942; s=zoho;;; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; bh=0BSEdOkrLoulAegP1zOnaqO+oja5CjqiTy3ulevd3+U=; b=eKYLZ2W1+9ro8f99SlrwxktUNfdIKCqyhdGvUDnu0gfU3N15pOW1dUvgaEWmzb84 I9u2oIGh9ykAHPMM4iRxw+iSLus90XXg76wfVsv5F5veGKjNivBWpW9eOxK05E/ZQNG m2RuZFANA3YashJ1YINvoKL4VINsLwEy1sRaVf4c=
Received: from roelofs-mbp.lan ( []) by with SMTPS id 1595881937101735.0950950715875; Mon, 27 Jul 2020 13:32:17 -0700 (PDT)
From: Roelof duToit <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_147F458E-1F50-4EB8-B6FA-7DAA36986172"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 27 Jul 2020 16:32:14 -0400
In-Reply-To: <>
Cc: Nick Harper <>, Ben Schwartz <>, "Nancy Cam-Winget (ncamwing)" <>, OpSec Chairs <>, OPSEC <>, "" <>
To: Andrei Popov <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-ZohoMailClient: External
Archived-At: <>
Subject: Re: [TLS] [OPSEC] [EXTERNAL] Re: 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: Mon, 27 Jul 2020 20:32:29 -0000

Thank you Andrei.

> The document does not describe alternatives to MITM proxies.

The [SECURITY_IMPACT] paper mentions alternatives, and we could certainly include a high-level summary of some of those even though our intention was to document the BCP for TLS proxies where the reader is considering a TLS proxy network function.   If we do include an expanded section on alternatives then it should also reference the capabilities and limitations of endpoint-only security solutions (reference: <>)

> Section 4.1.2 “Inbound provisioning” does not discuss security and operational issues around server key sharing with the proxy. No real discussion of short-lived creds and “keyless” scenarios.

Sections 4.1 and 4.12 provide guidelines and leaves the implementation up to the developer.  That is not to say that we cannot be more specific about key sharing and key storage for inbound solutions.   We could certainly mention draft-ietf-tls-subcerts as well.

> Section 4.2 “Maintain security posture and limit modifications” seems to recommend modifications to the ClientHello, rather than having the proxy generate a new ClientHello. Proxies sending ClientHellos they did not generate are a common cause of interop issues.

That section needs more clarification.  We are most certainly not proposing that TLS proxies should forward the original ClientHello and are aware of the risks - especially when RSA key exchange is used.  The intention of section 4.2 is for the TLS proxy to base certain attributes of the generated ClientHello on what was advertised by the client, with the goal of maintaining the security posture.

> Section 4.2 also explicitly allows completely insecure configurations:
>       “TLS proxy stacks MAY provide user configurable options, such as an
>    option to accept self-signed server certificates, an option to let
>    the handshake continue with expired but otherwise valid server
>    certificates, etc.”

That paragraph needs examples.   One such example is where device-to-device communication in the enterprise traverses the TLS proxy and where said devices must be excluded from further inspection based on a combination of policy attributes - it is not always practical to update the devices.