IETF Logo Mail Archive

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

Tony Arcieri <bascule@gmail.com> Mon, 23 October 2017 21:43 UTC

Return-Path: <bascule@gmail.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 3DFC8139605 for <tls@ietfa.amsl.com>; Mon, 23 Oct 2017 14:43:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 a5oyuS5ic0mu for <tls@ietfa.amsl.com>; Mon, 23 Oct 2017 14:43:17 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B3CE138351 for <tls@ietf.org>; Mon, 23 Oct 2017 14:43:17 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id k123so23897958qke.3 for <tls@ietf.org>; Mon, 23 Oct 2017 14:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.55.23.99 with SMTP id i96mr19654102qkh.278.1508794996393; Mon, 23 Oct 2017 14:43:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.56.11 with HTTP; Mon, 23 Oct 2017 14:42:55 -0700 (PDT)
In-Reply-To: <CAFJuDmMZMRqvhyLFMoUo_5KPaVu3d4o2ZEQ_PiAOxWe7CtGgYQ@mail.gmail.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com> <fd12a8a8c29e4c7f9e9192e1a1d972d6@venafi.com> <D2CAAA44-339E-4B41-BCE0-865C76B50E2F@akamai.com> <d76828f02fc34287a961eba21901247b@venafi.com> <56687FEC-508F-4457-83CC-7C379387240D@akamai.com> <c1c0d010293c449481f8751c3b85d6ae@venafi.com> <4167392E-07FB-46D5-9FBC-4773881BFD2C@akamai.com> <3d5a0c1aab3e4ceb85ff631f8365618f@venafi.com> <E84889BB-08B3-4A3A-AE3A-687874B16440@akamai.com> <CAPBBiVQvtQbD4j3ofpCmG63MEyRWF15VL90NOTjeNqUOiyo6xg@mail.gmail.com> <9013424B-4F6D-4185-9BFD-EC454FF80F22@akamai.com> <CY4PR14MB1368CBA562220D9A3604F0FFD7430@CY4PR14MB1368.namprd14.prod.outlook.com> <2741e833-c0d1-33ca-0ad3-b71122220bc5@cs.tcd.ie> <CY4PR14MB136835A3306DEEFCA89D3C2DD7430@CY4PR14MB1368.namprd14.prod.outlook.com> <31F5A73E-F37E-40D8-AA7D-8BB861692FED@akamai.com> <13592ABB-BA71-4DF9-BEE4-1E0C3ED50598@gmail.com> <2EE9CB23-AEDA-4155-BF24-EBC70CD302EF@fugue.com> <CY4PR14MB136816569A2AE2A9760C6E08D7410@CY4PR14MB1368.namprd14.prod.outlook.com> <557F43AC-A236-47BB-8C51-EDD37D09D5CB@fugue.com> <CY4PR14MB13684F18AD75F4AE767CE35CD7460@CY4PR14MB1368.namprd14.prod.outlook.com> <57CFBA2A-E878-47B0-8284-35369D4DA2DF@fugue.com> <CY4PR14MB13680B6D5726D940C4C51B4BD7460@CY4PR14MB1368.namprd14.prod.outlook.com> <0D75E20C-135D-45BC-ABE4-5C737B7491C9@akamai.com> <CY4PR14MB1368378B42A6C46B27F5EF01D7460@CY4PR14MB1368.namprd14.prod.outlook.com> <2AC16F9E-C745-43AD-82C1-D3953D51816C@fugue.com> <CY4PR14MB1368895DD0D72286635E4E83D7460@CY4PR14MB1368.namprd14.prod.outlook.com> <E37A3920-D7E3-4C94-89D0-6D3ECDEBCFF6@fugue.com> <CAFJuDmMZMRqvhyLFMoUo_5KPaVu3d4o2ZEQ_PiAOxWe7CtGgYQ@mail.gmail.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Mon, 23 Oct 2017 14:42:55 -0700
Message-ID: <CAHOTMVJZpWfdCSrzYXhb5-gyzpjuNzoEMjM9DywqRu6Q8op_vw@mail.gmail.com>
To: Adam Caudill <adam@adamcaudill.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a1146e248cc8e22055c3db56b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dxZ1N6tONCtGyDYgH1l6zZVMusE>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-BeenThere: tls@ietf.org
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." <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: Mon, 23 Oct 2017 21:43:19 -0000

On Mon, Oct 23, 2017 at 12:11 PM, Adam Caudill <adam@adamcaudill.com> 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.

v2.23.0 | Report a Bug | By Email