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

Steve Fenter <> Sun, 22 October 2017 23:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B4EC13BF50 for <>; Sun, 22 Oct 2017 16:26:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 sJGiTX0VaynJ for <>; Sun, 22 Oct 2017 16:26:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4D9A13BF4C for <>; Sun, 22 Oct 2017 16:26:38 -0700 (PDT)
Received: by with SMTP id 101so18343358ioj.3 for <>; Sun, 22 Oct 2017 16:26:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=references:in-reply-to:mime-version:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=ZsAnmGqGTIHO5SuWruZf0HONWQZ0nkiswqPMts2OwTM=; b=WeN3xD4epFDAy7pRpjgR4gHgdoHTZF3xqWYLC7otAL+v6RQD5byozRsilpKs0o0BaB KokNUIqCc4+4vQlYULtWMKEAyGojtdFxr72l0kwgjD2qmF/ckpG3pKKzhpCFTFg62wMD EQg4rd441ZmTAAJWC/ftueJ1eq9JjCsPqxHZYOzU3BMNozv0M+mRO3CqI/U5rG2XkkGv yv6vEwoV3EwtOojCMFvAzk1PZjDX2DR8qYckewO2MkaX/0U+KYWlOF9VQnsnn14wpwY1 wm0+m4oADMPH0D9nh3+gln5oj20wcmYzOF859bo8Cb6axSlyq0pE4PGyKH+biDWPqFRN Lh5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:references:in-reply-to:mime-version :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ZsAnmGqGTIHO5SuWruZf0HONWQZ0nkiswqPMts2OwTM=; b=cpHY2fJpqFWzcm2zngz82I3dKMxnKKouzF+JEJ01xmSzwxZ9UaVdthNbHv3Z8Euu7M 9OYRm+7tuoAyygq1ySCIPXbQl+aWYYHxW+dUTtm6x8aj8pj3nWiL+BO1uH0nfKYfYnwS pVCbvfYCXk5Dg9Yxn99Nc0xoK6Bw7kHV3olTMrxUmV28hGZs3z1XPH/aXZUv+XVY9Bht rMTASijTP65zHpSbcnOcWvBj9VkiHoMhRHxkPMzT3S+LjwbVP6+yUvWxArCyu5H0DJj6 tAPzLpQojdQJrTchPgX8JQdEWm83meDrGo3t05GA//fYy4OKthwux6wdhm32xYWy0s4d aQTA==
X-Gm-Message-State: AMCzsaVnodHyJnBA/Ny9LYy5qxli7C4p/HWLXee95/gYMKLISEwrlb2+ /3VDhfARxRxLcO3oe8mkGZvtzQRB
X-Google-Smtp-Source: ABhQp+TVWofAivaxiPvR7udcWKlxZ5bQWD3Z747wGcS+XqbEFNmIEL99ZUbiBFy4ynZiQNUXtPxrwQ==
X-Received: by with SMTP id w185mr16363608iod.259.1508714797929; Sun, 22 Oct 2017 16:26:37 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id k2sm2671706iok.43.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 22 Oct 2017 16:26:37 -0700 (PDT)
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <>
Cc: Darin Pettis <>, Paul Turner <>, "Salz, Rich" <>, "" <>
X-Mailer: iPad Mail (11D201)
From: Steve Fenter <>
Date: Sun, 22 Oct 2017 18:26:38 -0500
To: Christian Huitema <>
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: Sun, 22 Oct 2017 23:26:40 -0000

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.

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

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.

> On Oct 19, 2017, at 5:37 PM, Christian Huitema <>; wrote:
>> On 10/19/2017 3:30 PM, Darin Pettis wrote:
>> The amount of people currently voicing concern is likely small for two
>> reasons.  One is that everything is public and many of the "lurkers"
>> are hesitant to voice their concerns.  The second reason is that so
>> many don't know that visibility will be an issue.  They will either
>> discover this as they migrate to TLS 1.3 or as they start to encrypt
>> within their data center.  There is work to rapidly raise that
>> awareness through roundtables, conferences and other venues.
> Might it be because many of these enterprises and data centers do not in
> fact see encryption as a problem? Maybe they have found ways to manage
> their applications and servers without breaking TLS...
> -- 
> Christian Huitema
> _______________________________________________
> TLS mailing list