Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Peter Saint-Andre <> Mon, 23 October 2017 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C83A1394FB for <>; Mon, 23 Oct 2017 09:14:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=gbL9rYKJ; dkim=pass (2048-bit key) header.b=rxVhR0Oy
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQg1vZBoZ1dh for <>; Mon, 23 Oct 2017 09:14:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA555137ED6 for <>; Mon, 23 Oct 2017 09:14:49 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2B12B20C8A; Mon, 23 Oct 2017 12:14:49 -0400 (EDT)
Received: from frontend2 ([]) by compute2.internal (MEProxy); Mon, 23 Oct 2017 12:14:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=MOA28yOiGFjODXW9bE7baGPWo+mN9/A57m8TAS6YaI8=; b=gbL9rYKJ jQkT9c68GYiO8WLohZjBfkmV/cS8dIFsQCJe6Ocyu+B1/qO4j9nVhAavNln48fJ7 hYtB51s6Cd5lV+hq2dWz9W8ouwvmVTEWQ353EWQms0YMZWgXIrnLlviAYrtz+GoH sp4abK1BPrHbydYbJv1ZHZXlAdIF4k/xdg+ZnIob7g7gYIkoSJTagtUfOAB3j+QH B8otptbI/EGrdBmjTP93JamYuuEuYk6J6++xqO+rpSOB3g6QWEcrhwcQuxVmS30F 5K3Zh1ehtl6FQ79Jw/nKjq3XQu7zAnh9o/skDWy14wcZWX8ogN4aKEfcMXTP/vRz cDShtacMaENypg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MOA28yOiGFjODXW9bE7baGPWo+mN9 /A57m8TAS6YaI8=; b=rxVhR0OywuavEXqW827YzZ6y58jzqfksDieb1v/pBH3dw wcPtVoqI7yYQFunkuxr7gfiqTKGj8qZfxGIs2nVz9sxdBZMHFI5NwevTHdz3KvLx Y2y3FlDsWTreXOguWFzXiN8Wioh3P3bOOrI259WVA3x4HmWrOSe5L+lZmnWPQYZN 9DSCIrA7CV4enkieWSV8EAUunePSHn7ejJdh2UPFry3TMCaBI0DeBMVrPURCPcQi 3jov0LyE9bq3/ZFcKKiBEUBQW6mdS8N9pFrsffhFhFnTJ51WlANK1ss1e6iBZhDK EqpeHAat7pDF693oFV+/H01eDIwKeK3yiOc83bf0A==
X-ME-Sender: <xms:eRXuWbagipA7j_ySWIMZ3Kag6HSJERkT6gPZ5Y00141T8ZktYosYmw>
Received: from aither.local (unknown []) by (Postfix) with ESMTPA id 4D5D9248D1; Mon, 23 Oct 2017 12:14:48 -0400 (EDT)
To: Steve Fenter <>, Christian Huitema <>
Cc: Paul Turner <>, "" <>
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Peter Saint-Andre <>
Message-ID: <>
Date: Mon, 23 Oct 2017 10:14:46 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6ce0OdBTbS8jaxMIWUUSiAMoLncOBkn2f"
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-Mailman-Version: 2.1.22
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, 23 Oct 2017 16:14:52 -0000

On 10/22/17 5:26 PM, Steve Fenter wrote:
> I know of a number of large enterprises in verticals including financial, health care, retail, and government, across multiple countries, who are using packet payload inspection within their data centers.  Most of these enterprises are reluctant to step forward in a public forum and reveal their internal network structure and their internal security and monitoring practices. This gives the false impression that out of band decryption of TLS is not a big deal. It is in fact mission critical to a significant number of large enterprises.
> I have been saying to anyone who will listen that the IETF needs a private forum for enterprises, to enable them to come forward and discuss their real requirements. Without this input the IETF is trying to architect and engineer solutions without knowing the complete set of requirements, at least on the enterprise side.  This results in sub-optimal design decisions (from an enterprise perspective), which in this case will break mission critical enterprise monitoring and troubleshooting systems.

The IETF doesn't run private forums behind closed doors. You'd need to
do that kind of work elsewhere (these large enterprises could, of
course, start their own industry forum, where they could work in ways
that the IETF doesn't).

> We've already experienced what a rollout of TLS 1.3 will be like, at more than one enterprise, when certain vendors decided to move Diffie Hellman ciphers to the top of their priority list on a code upgrade. This caused severity one outages of critical monitoring systems. 

It sounds as if different internal teams might not have been
communicating well about the rollout of those new cipher suites.
Operational issues in large enterprises are not a problem that requires
protocol work.

>  This means that critical applications depend on these monitoring systems, and if the monitoring system is down the application is completely down. This is not the outcome we want when TLS 1.3 is rolled out, but it is what we are headed for. Enterprise monitoring should be tested as part of the operational TLS 1.3 testing before TLS 1.3 is approved as a standard, and TLS 1.3 should not be approved if enterprise monitoring breaks.

Operational testing is always good, but very strong arguments need to be
made for the latter claim. Among other things, you're adding a new
requirement to the Internet Standards Process, which would necessitate
IETF consensus on changes to RFC 2026!

> The only other option being presented to enterprises is that we continue to run on a TLS spec that is nine years old, and then continue running it until it is 14 to 19 years old. It makes no sense to me to put out a TLS 1.3 standard, but say that enterprises cannot upgrade to it.

There are many options, some of which Kathleen outlined in her blog
post. It's not helpful to say there is just one option when we haven't
fully explored either the problem space or the solution space. And by
"we" I mean especially those who are claiming the need for TLS visibility.