Re: [TLS] Industry Concerns about TLS 1.3

Jeffrey Walton <> Mon, 03 October 2016 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B57FF12958A for <>; Mon, 3 Oct 2016 14:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, 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 X24i6R8fdH9S for <>; Mon, 3 Oct 2016 14:37:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62CC3129572 for <>; Mon, 3 Oct 2016 14:37:47 -0700 (PDT)
Received: by with SMTP id 188so46868669iti.1 for <>; Mon, 03 Oct 2016 14:37:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=jwEKR6SOmo5wV2wansTBKN8ZNzuEcEw2yRdbhjVRmN0=; b=kebEwBauBGzpMTEoCYPjJVguf8q98O7l95OSMqRcZcynjG2/mOp9cy2w8JnIhRpoom baJWslUa7RAAtIUxvXXqm8uG0IO1ghFULHDcqb7MRK7OZoe8ab0FDGZ6H99HRSuqlYG8 YbArGsyhYCHDeEFHSFEbdiiIOMVXLSCRSSZ9uvIxhZaj95fbjwwGh1kAfOquOiMHgVik kSS2Zi7qkzDbd0Wdy7rRxvYBt4UknVno8AFaqXIq7GjnkVI9hvz+58aIqxnvF4i4cvgf YxgxKeVfcGKIZBDvYYWh4xbCbllBnyxCCpWeVd3cZ5eskAoDypYUBqV9p5DU/ZJa8EFm QIEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=jwEKR6SOmo5wV2wansTBKN8ZNzuEcEw2yRdbhjVRmN0=; b=AXcfKcZb7LHMjiVqBqloprNuEIPBB6wDCuS3TVpCRxHv0FafGSaUMmbu6bFzKB1Fn2 7AeGkvmAj2cz+attNtDPYBPJUBMUZ1Y4Np5I3p4TPfkMg4zui2vSVfwMSBetu0oWkSCj 9kYo1qPYw15NihPsCM210HZ4cOp0zhNiqw4lHM1AOFDVEucbwnatJ3Ye+SClPBOBg6Xe oHoLjCwCEmjMHsbb5cyF2LKp1CvkW3iQ46kCuIkLmSY2K5pcTZraOeRf+uI+0UQJEsSQ ppshEwxMeHGkaiEqnJYgwHzkb37DC9wcIbRCQoMczKql/zSOXqR3z0xlz7HEk7qMQTjp ljHg==
X-Gm-Message-State: AA6/9RmYAEFYcQAF0l9Ox/xHBbNqgZf6OEiCqWbB4L0EO/Dz4m7Bpcmc/b+jhW/NnEYmV6GFvB+8qIsRt2jLrg==
X-Received: by with SMTP id e17mr829314ita.41.1475530666787; Mon, 03 Oct 2016 14:37:46 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 3 Oct 2016 14:37:46 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Jeffrey Walton <>
Date: Mon, 03 Oct 2016 17:37:46 -0400
Message-ID: <>
To: BITS Security <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-Mailman-Version: 2.1.17
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, 03 Oct 2016 21:37:49 -0000

> PCI requirement providing Intrusion Detection at the entrance to Cardholder Data Environments as well as at critical points inside the Cardholder Data Environment.  Intrusion Detection requires decryption of TLS.  For some large, complex organizations this can be a large number of physical inspection points, more than can be accommodated by MITM.  I understand this may not be a problem for your current environment but others do not have that luxury.

This may be less than an ideal requirement.

Malware wants to do three things (with some hand waiving): (1) spread,
(2) collect data, and (3) egress data. I think Step (1) and intrusion
detection is a worthy cause, but not at the cost of breaking the
secure channel.

Perhaps it would be better to focus on (2) and (3). (2) can be tricky
based on how deeply the malware is burrowed in. (3) is much easier
since the malware needs to open a socket.

Policies for (3) are really just whitelist/blacklist approaches. I'm
guessing egress points are wide open at the moment, and the PCI
requirement is fostering blacklists and causing the organization to be
reactive. If the egress points are closed at the organizational
boundary, then the organization is proactive and using a whitelist

Would it be possible to have the PCI folks re-examine their position
since it seems to be boxing BITS members into something untenable?