Re: [TLS] Industry Concerns about TLS 1.3

Kyle Rose <krose@krose.org> Thu, 22 September 2016 19:17 UTC

Return-Path: <krose@krose.org>
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 65D7C12D788 for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 12:17:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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, 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 (1024-bit key) header.d=krose.org
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 SGABWOnp9ng2 for <tls@ietfa.amsl.com>; Thu, 22 Sep 2016 12:17:25 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 0567212D754 for <tls@ietf.org>; Thu, 22 Sep 2016 12:17:25 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id z190so85975674qkc.3 for <tls@ietf.org>; Thu, 22 Sep 2016 12:17:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OW+mK3XPU3Zj0Lsk5B7aa3xvlnckqMk/Qyym1BZG+3M=; b=azjTZ2FWyzHcaQVizxWSevy4xpq/3m6UDBf+2BU4yQdx4NXHAw8drCDP5e9a1VVHgO 1ok2qsnkwn9nG59cWpUnkVbct5mLOTAOaZsi1dhEu+LDIcKxCrEYMRMpzp9grwOfryRN BElDYUPo3OtLBChoq3UD78pHoB0dwNaI5wt3o=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OW+mK3XPU3Zj0Lsk5B7aa3xvlnckqMk/Qyym1BZG+3M=; b=gesagczGWNhlnmPIRD+6WPTe0OUmtIDiOxk1abxWwH7nAC1zITKKgwI/71eo/38Iwq M+7JNKa+gyjcwAKTJRyZeBuTaNQwM5cgusFBOHEoiG3WR+x4KJPSi/RlJVnUeeUPG39q abUOhS/3eX6SIs12kqbUm7WRJrBHNlZsxujFIxiGQd8CxBT9Y6DPv3nRmlamzkWbDpmG pMkHuE9UlJu69bK+O0Apb3mgWmPVDiauRgrFSQ0OPnzalKtxAGC5AmrjtLt0C99V/c4d VvqXUNnJEzb1rlWv+626aU/DrkWd4EPyhKt0CbltgZ35bwBlOATZ1JIlv9WhNW7dcHmj R5MQ==
X-Gm-Message-State: AA6/9Rkz4t7DI5viVFwoGRTISORNYHB0zDx2osNkZfKS9xamE2jDmczbAr/Y00itzO6BCfkS5Z993XW/oKayMw==
X-Received: by 10.55.158.210 with SMTP id h201mr3806067qke.41.1474571844144; Thu, 22 Sep 2016 12:17:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.212.152 with HTTP; Thu, 22 Sep 2016 12:17:23 -0700 (PDT)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Kyle Rose <krose@krose.org>
Date: Thu, 22 Sep 2016 15:17:23 -0400
Message-ID: <CAJU8_nU0TD32D6gBxsCBwt9rRX9DtwV52TP71tnjYpWwrZeVoA@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary=94eb2c065474f78712053d1d82cd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nKVDT8xTlU1o5-q3O3MPG0zZgH4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
X-BeenThere: tls@ietf.org
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." <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: Thu, 22 Sep 2016 19:17:27 -0000

On Thu, Sep 22, 2016 at 1:19 PM, BITS Security <
BITSSecurity@fsroundtable.org>; wrote:

> Like many enterprises, financial institutions depend upon the ability to
> decrypt TLS traffic to implement data loss protection, intrusion detection
> and prevention, malware detection, packet capture and analysis, and DDoS
> mitigation.  Unlike some other businesses, financial institutions also rely
> upon TLS traffic decryption to implement fraud monitoring and surveillance
> of supervised employees.  The products which support these capabilities
> will need to be replaced or substantially redesigned at significant cost
> and loss of scalability to continue to support the functionality financial
> institutions and their regulators require.
>

I do not think this difficulty should be a consideration for TLS. These
capabilities can be enabled by the endpoint.

Kyle