> 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 PCI has mandated upgrading TLS because of vulnerabilities, they are likely to do it again and in fact have provided strong hints to the market where they should be beyond the minimum requirement itself. I don't see that the timing really matters because it isn't based on the age of the standard, it is based on the standard becoming outdated. We're trying to get ahead of foreseeable problem some will have. Further, PCI does not require TLS encryption at all in a private data center, at least not technically. However, in practice they strongly recommend segmenting the Cardholder Data Environment, which I suspect most financials have done, and many have used TLS as part of their strategy for segmentation (encrypted PCI traffic flowing through devices does not bring these devices into scope for audit). So according to current practice, auditors are going to require certain levels of TLS in order for our segmenting strategies to work. > 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. 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. > 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. We can implore PCI all we want, but if events overtake us, such as the introduction of new security risks, we have to be prepared for eventualities like TLS 1.3 being the mandate and must be prepared perform IDS/IPS routines at scale such an environment. > 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? I don't know how this listserv operates in practice but it is this type of sophistry that hard boils my eggs to put it politely. Perhaps this is just the regular cost of participation but that would be unfortunate. If you look at the industry reports like the Verizon PCI Breach and Compliance Reports, private keys simply aren't being stolen. Maybe there is an outlier or two but there certainly isn't a documented trend I can find. If you have contravening information to provide I am all ears. - Andrew From: Tony Arcieri [mailto:basc...@gmail.com] Sent: Tuesday, September 27, 2016 4:17 PM To: BITS Security <bitssecur...@fsroundtable.org> Cc: Peter Bowen <pzbo...@gmail.com>; tls@ietf.org Subject: Re: [TLS] Industry Concerns about TLS 1.3 On Mon, Sep 26, 2016 at 12:01 PM, BITS Security <bitssecur...@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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
