Re: [TLS] Industry Concerns about TLS 1.3

Ronald del Rosario <> Tue, 27 September 2016 21:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64FC312B334 for <>; Tue, 27 Sep 2016 14:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6H4le67mWOvD for <>; Tue, 27 Sep 2016 14:03:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B1BC12B152 for <>; Tue, 27 Sep 2016 14:03:32 -0700 (PDT)
Received: from ( []) (Using TLS) by with ESMTP id us-mta-103-qAGH5ewqPH-2878vt1K_mA-3; Tue, 27 Sep 2016 17:03:19 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 27 Sep 2016 14:02:54 -0700
Received: from ([fe80::ede6:8312:5207:4046]) by ([fe80::4d18:3a9c:2936:eea8%16]) with mapi id 14.03.0248.002; Tue, 27 Sep 2016 14:03:11 -0700
From: Ronald del Rosario <>
To: Tony Arcieri <>, BITS Security <>
Thread-Topic: [TLS] Industry Concerns about TLS 1.3
Date: Tue, 27 Sep 2016 21:03:10 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1a.1.160916
x-originating-ip: []
MIME-Version: 1.0
X-MC-Unique: qAGH5ewqPH-2878vt1K_mA-3
Content-Type: multipart/alternative; boundary="_000_5E0F80B5A19B44809917CD224B5CB0A6five9com_"
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: Tue, 27 Sep 2016 21:03:36 -0000

+1 to Tony

I am also in charge of enforcing TLS Standards in our CDE.  I also do not speak on behalf of my employer, but:

PCI extended the migration from SSLv3 and TLS 1.0 to a secure version (TLS 1.1 or higher) until June 2018.<>


From: TLS <> on behalf of Tony Arcieri <>
Date: Tuesday, September 27, 2016 at 1:17 PM
To: BITS Security <>
Cc: Jeffrey Walton <>
Subject: Re: [TLS] Industry Concerns about TLS 1.3

On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <<>> 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


CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential information of Five9 and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Five9 and/or its affiliated entities.


The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.