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

Tony Arcieri <> Mon, 23 October 2017 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DFC8139605 for <>; Mon, 23 Oct 2017 14:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 a5oyuS5ic0mu for <>; Mon, 23 Oct 2017 14:43:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B3CE138351 for <>; Mon, 23 Oct 2017 14:43:17 -0700 (PDT)
Received: by with SMTP id k123so23897958qke.3 for <>; Mon, 23 Oct 2017 14:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CZ5+LIjZvOcV/+YT3gMtgsjssvHnQO3b1dBvI8lHWyc=; b=PCdsoj7XyeIjOr+Wddrl+cdmIHYuXcUgjxWGMiCL8fZKJ1lGlamUOn9NaIj2U/7l+C +XH1iJZl7NAZOsvxFApkQ9CLobvqyEQZXTd4i95951G741x6Vuz2tWIexjorWoGqkz+W R/WVnPxHb0ryQLydtSSJNEJWF6jUXn6FPufMKxaqLW4CxfF/+XBPZTqD8EIjFl1sU9N+ pOzeYFOhkHRZUeqeDEZcvo1ESya9YBXWoNfrzPS+7riuc6F1OTHFdZ1yKTljgsylI9C3 zWOrnQ4SyZKaBcdzqyGjd7DFudliGG5LEk617lh6N4kmUZFNweiDhcju7FQo5hvc74+h QfYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CZ5+LIjZvOcV/+YT3gMtgsjssvHnQO3b1dBvI8lHWyc=; b=bKjfeZSoD4rxsJP3I/SiyObbeQYC/W0XusOrqswmWGV7jl1jhrjnwo2wFFX3nr8FfO KgS+m73jwOy3PXGA/RIAv2Od1kj9idMle6PFoEJ5riKIb23uBkZTyJRCh59QB06CC3SU a+5RoHZXqqvihD86ap1Jaf9ktcTu/VzIRbCaoyv2ayacG1ZuViUprZfccE3yteEE3wQi gCTJEu5l6KNUrAjUBc0l07YREOWBXK4k4kyNzqzAEicdeE9bGO6lPHeaPUTulHnL9BT5 uGNIBqJzKio/vkP1tcPHGlCCbwG/99ME2OLqqwe/VwH8jxKE4XYXbCOKkTviLE4gN1KN 4jdQ==
X-Gm-Message-State: AMCzsaV5Q99WoeNVGFHSXEs1nOvxKeCd/Tt8I4RUfc05sQmylXDXChxR BZKr2LWgegrwuweblFEgEruNZs5MEYC8xDFumvU=
X-Google-Smtp-Source: ABhQp+QaF7e8wyrYZ9zSUzWdSVn0ZIqAGZy1Ab8/DWZptw7TVxPJmTlXHxGyq6rsSAAxdxJeHiR/6JG7YeMMrmIpXQU=
X-Received: by with SMTP id i96mr19654102qkh.278.1508794996393; Mon, 23 Oct 2017 14:43:16 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 23 Oct 2017 14:42:55 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <000501d348e5$1f273450$5d759cf0$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Tony Arcieri <>
Date: Mon, 23 Oct 2017 14:42:55 -0700
Message-ID: <>
To: Adam Caudill <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a1146e248cc8e22055c3db56b"
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 21:43:19 -0000

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <>; wrote:

> Those advocating for some standardized method of subverting the security
> properties of TLS have been offered numerous options in good faith, and
> continue to reject them all. I’m aware of extremely large enterprises that
> in fact require TLS 1.2 with PFS, as they made the investment in addressing
> this issue early on, and do so effectively. This can be solved without
> changes to the protocol or a standardized “backdoor” - and is being done
> today by at least some enterprises.

Having worked (and presently working) for more than one company of this
nature, in the payments business no less, I would like to restate that it's
incredibly disingenuous to cite the need for self-MitM capability as an
"industry" concern.

I think if it were possible to ask for a hum "from industry", you'd find
the field divided between those who have invested in a real observability
story, and those who think passive network traffic collection is the only
way to debug their systems. I think if you were to even take a straw poll
of the best approaches monitoring/observability among actual industry
practitioners, passive network traffic collection would rank close to the
bottom of the list.

I would go as far as to say that if you are among those requesting this
misfeature, you are doing a terrible job securing your infrastructure, and
should look into modern observability techniques as an alternative to
debugging by concentrating network traffic dumps into a single point of
compromise which represents a huge security liability. Yes, switching to a
new approach to observability is a huge investment that will take time, but
so is upgrading to a new version of TLS.

The "industry" reality is that many companies do not need a self-MitM
misfeature and could be actively harmed by it, and while a self-MitM
capability may be standard operating practice for some, it is not true for
all, and identifying those who want the self-MitM capability as "industry"
is a composition fallacy being leveraged as a rhetorical tactic, i.e. "IETF
is not listening to the concerns of industry".

As a member of "industry" myself, I implore the IETF: please don't make the
rest of us less secure at the request of those who are running insecure
infrastructures and apparently intend on keeping things that way.