Re: [TLS] Industry Concerns about TLS 1.3

Tony Arcieri <bascule@gmail.com> Tue, 27 September 2016 20:17 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 8B0C812B4BA for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 13:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 J53qnQLn9clO for <tls@ietfa.amsl.com>; Tue, 27 Sep 2016 13:17:37 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 6796012B2A0 for <tls@ietf.org>; Tue, 27 Sep 2016 13:17:37 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id n13so20870680uaa.3 for <tls@ietf.org>; Tue, 27 Sep 2016 13:17:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/EWOPo+bX7brBxCDp5rp7ZqXxeGe8lgEHFs3SoMT/Os=; b=iNxCqk1kzUz0gWV+ZjndhYYMJjBuuO7jHDxl5SPVbRYNYlMgkWWXRHbK1TRAZ0voFC WI81huFgPvensjwo6MWpa4t44zP+hCrRYJz9S0N0TU+yGEmEDOQs05i0LPSzPsdqv4P9 Uve1kFgj4CWggSsLABHzlRKssYYUn7GiXBkhj5FLzWk3ibAJMxbn3ZnLL4My6QrpIsB6 8Gp/hYtOAZaePlVQAndLtKyZWc7MIB1mLpXCz0hBY9lBR6PDZDtwN4wyWtXqk13zSKLQ D4DRONpK7TWJfzLuaBOp5wEmjOfuUwEaGPiZ3c/3FQdiX2OBlX9YllpmS8gFa2pZ3cRE B1Ug==
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=/EWOPo+bX7brBxCDp5rp7ZqXxeGe8lgEHFs3SoMT/Os=; b=ZxB0FzfCaoIX2YHOLIB/rW7lOiK7T6BmN7FgQV4aU82W7Lqoiv1shQCAzLgvTURzJq dG7JZRL/gpyR1GbthPucbMuj8/HCKDmLlkgQ2fuwKVpG6YCqbxChTi6QzINEu9nlA+O7 yRBtURwGS24tOorvdGXOADQHqMViXK+Y3P6ajiU7ACzX8Lx+omb1z3baE6mGmg2OuQE5 x0adgfrVEE1dg0GYSLvf/9K5I5jF0fy9dS/7kfwXSibi3E7m3oZhTLHUiChZLUyg8Zw4 En/HIERwz7ZZSWCZITSrSi3jkBINnu+JHI03+NgdPZj/3+sMwSQLvfJsrN9uBdYwBFz3 IQFw==
X-Gm-Message-State: AA6/9Rm/rRycrnFpiz5eurFmZVDPSE4lQqjXseKAsAC5yf0+XchhyvhngWKvvmEpWHgprO2VpYdP8UA5ztoKpA==
X-Received: by 10.176.84.158 with SMTP id p30mr3492471uaa.33.1475007456567; Tue, 27 Sep 2016 13:17:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.153.195 with HTTP; Tue, 27 Sep 2016 13:17:15 -0700 (PDT)
In-Reply-To: <DM5PR11MB1419620B8BA15C7780F60669F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com>
References: <DM5PR11MB1419B782D2BEF0E0A35E420DF4C90@DM5PR11MB1419.namprd11.prod.outlook.com> <CO1PR07MB283F2C414B6478E993675DEC3C90@CO1PR07MB283.namprd07.prod.outlook.com> <394611bf-208f-03d3-620c-79aaf169645b@cs.tcd.ie> <4FC37E442D05A748896589E468752CAA0DBC66AE@PWN401EA120.ent.corp.bcbsm.com> <CAH8yC8kgYzYXwJ01NkK7WYxD-diponWEQOd+MNHssm+bLHE54w@mail.gmail.com> <4FC37E442D05A748896589E468752CAA0DBC699B@PWN401EA120.ent.corp.bcbsm.com> <CACsn0c=5vjzQmr=ah6sH1JzTj3peaKad7aCPertcqD4B2DLKiA@mail.gmail.com> <DM5PR11MB141941D8E156245A1CF6C911F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <126ee1b6-fc88-bf4e-c366-60d59a9b3350@gmail.com> <DM5PR11MB1419F8F0D0C80835C1DB49F2F4C80@DM5PR11MB1419.namprd11.prod.outlook.com> <CAK6vND_S-YRfY5mpvt_v_srNhdvYJkM8pVV84bywr9zMaYoE6A@mail.gmail.com> <DM5PR11MB1419620B8BA15C7780F60669F4CD0@DM5PR11MB1419.namprd11.prod.outlook.com>
From: Tony Arcieri <bascule@gmail.com>
Date: Tue, 27 Sep 2016 13:17:15 -0700
Message-ID: <CAHOTMVLv7F3-ZuKM+35eL-tOtr8ee-1gqwYy+9zQu2GKrsXkjQ@mail.gmail.com>
To: BITS Security <BITSSecurity@fsroundtable.org>
Content-Type: multipart/alternative; boundary=94eb2c1b0fca7d68de053d82efcb
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GIfeuZNzZ4QTrvl3VYOfQZdimik>
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: Tue, 27 Sep 2016 20:17:39 -0000

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <
BITSSecurity@fsroundtable.org>; wrote:

> The PCI DSS is already requiring TLS 1.2 for financial institutions that
> participate in the Payment Card Industry.  .BANK (exclusive top level
> banking domain) is also planning to require TLS 1.2.   We're anticipating
> that a regulatory body like these will require TLS 1.3 at some point in the
> future.  Financial institutions then have to comply if they want to
> continue to do business with the companies represented by the regulatory
> body (like large credit card companies in the case of PCI).


Hello again,

I work firsthand enforcing these requirements at a payments company. Again,
I do not speak on behalf of my employer.

It wasn't until last year that PCI decided to deprecate TLS 1.0, at the
time a 16 year old standard. I think your sense of emergency is highly
over-exaggerated.

I find it highly unlikely that any group such as the PCI Council will begin
mandating TLS 1.3 any time soon. I would go as far as to call your concerns
"imaginary".

If you are worried about such an eventuality, the IETF is the wrong place
to complain. It is far, far too late in the TLS 1.3 process to be voicing
these concerns. Where were you 2+ years ago when it was the appropriate
time in the TLS development cycle to voice such concerns? I think the view
of more "forward thinking" payments companies is TLS 1.3 has taken too long
already, and they would like to start deploying it in its current form and
would prefer unnecessary holdups/distractions which have already occurred
throughout the process.

That said, there is still plenty of time to ensure that groups like the PCI
Council do not put in place requirements which would affect the centralized
traffic-decrypting MitM-capability on your payments stack. Perhaps you
should be voicing your concerns there? If you are worried about a TLS 1.3
mandate preventing your MitM capability, the onus is on you to convince the
relevant payments standards bodies that mandating TLS 1.3 is a bad idea for
the payments industry. I think those organizations are better poised to
judge whether such an approach reflects on necessary requirements versus
pervasive antipatterns among complacent companies unprepared for the future
and ripe for a data breach.

In the meantime, you have disclosed a veritable treasure map to a
traffic-decrypting single point of failure which ostensibly exists at all
of the companies you represent which attackers could leverage to recover
all payment credentials. That sounds like a huge security threat.

Would you mind disclosing which companies you represent, so I can ensure
for the safety of my own money that I do not use them?

-- 
Tony Arcieri