<div dir="ltr"><div>Forwarding on behalf of Patrick Donahue, at Cloudflare.</div><div><br></div>On Sun, Oct 9, 2016 at 8:09 PM, Patrick Donahue <span dir="ltr"><<a href="mailto:pat@cloudflare.com" target="_blank">pat@cloudflare.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">We examined this mechanism and determined that due to the variety of POS devices using our network, the client HELLO will not allow us to universally determine SHA-2 capable clients.  We do have a mix of SHA-1 and SHA-2 nodes in our network which is how we determined the percentage of compliant vs. non-compliant clients.</span></blockquote><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">At Cloudflare we see just about every user agent/underlying TLS implementation that connects to the Internet, and deployed fallback logic[1] to accommodate the subset lacking SHA-2 support. As Gerv suggested, when we detect that an incoming UA cannot validate a SHA-2 signature, we serve a SHA-1 signed certificate issued from a pulled root.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Would be interested to hear the specific challenges that First Data has encountered in their attempt to decide—by examining the ClientHello—which certificate to serve? There are parameters other than the <i>signature_algorithm</i> extension that can be considered when choosing the appropriate certificate. Happy to provide whatever guidance we can to help resolve any edge cases. (</span><span style="font-size:12.8px">Facebook has also[2] done this at scale and I'd be happy to make introductions there to the relevant folks.)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">1 - <a href="https://blog.cloudflare.com/tls-certificate-optimization-technical-details" target="_blank">https://blog.cloudflare.com/<wbr>tls-certificate-optimization-<wbr>technical-details</a></span></div><div><span style="font-size:12.8px">2 - <a href="https://www.facebook.com/notes/alex-stamos/the-sha-1-sunset/10153782990367929/" target="_blank">https://www.facebook.com/<wbr>notes/alex-stamos/the-sha-1-<wbr>sunset/10153782990367929/</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">--</span></div></div></blockquote></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 8, 2016 at 5:44 AM, Dean Coclin via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Responses submitted on behalf of First Data below:<br>
<span class=""><br>
On 03/10/16 15:26, Dean Coclin wrote:<br>
> FD Response: We tested a private root and determined that this would<br>
> not work for all affected clients. Modern POS systems would not have<br>
> the pulled root and would need to manually add the private root.<br>
<br>
Hang on... in the last 12 months, this company has continued to ship products with a root store based on the one browsers are choosing to ship, and so have followed our root removal policy blindly? Rick Andrews was telling me what a dumb idea this was back in the last decade. Please tell me that isn't so.<br>
<br>
</span>[FD Response] The payments ecosystem is very complex with many players.<br>
<br>
Where First Data provides POS systems, we are fully compliant with SHA-256.  As stated in 3.f of the original request:<br>
<br>
“First Data has successfully updated all other internal systems, websites, networks and POS devices to SHA-256.  Where FD has control we are compliant.”<br>
However, the majority of POS devices are created, sold, deployed and maintained by third parties. Merchants are free to obtain POS devices from these providers and use them with FD's infrastructure.<br>
<br>
Regarding the Root removal policy:  Many of the POS devices created by other parties are simply applications running on standard Windows or Linux distributions.  Those devices contain the same root stores that browsers trust.  Many of them are Java applications, which by default use the Java trust store that contains many of the same roots trusted by browsers.<br>
<br>
<br>
The payments industry association groups are having discussions on creating specific roots for PCI use, but this will require effort from many different parties and will take time.<br>
<span class=""><br>
<br>
<br>
<br>
And also, you can adopt what is now fairly mainstream technology, and serve a cert based on the client capabilities as determined by client HELLO - a new SHA256 one to modern terminals, or an older SHA1 one from a pulled root to older terminals. This would have been more than possible if you hadn't waited until 2 weeks before deadline day.<br>
<br>
</span>We examined this mechanism and determined that due to the variety of POS devices using our network, the client HELLO will not allow us to universally determine SHA-2 capable clients.  We do have a mix of SHA-1 and SHA-2 nodes in our network which is how we determined the percentage of compliant vs. non-compliant clients.<br>
<span class=""><br>
> The<br>
> level of effort involved would be similar to if not greater than just<br>
> upgrading or replacing Non SHA-2 compliant devices.<br>
<br>
No, the level of effort involved in reconfiguring your servers is not comparable to the level of effort involved in replacing 300,000 shipped devices.<br>
<br>
<br>
<br>
> Given the size and diversity of the POS device population there are no<br>
> pulled roots that would remediate a significant portion of the<br>
> 300,000 clients at risk.<br>
<br>
We've had this a couple of times now. Who makes these devices, how many different types are there, and what is the full list of roots in each model? Presumably you have that data in order to make this statement.<br>
<br>
</span>[First Data] As stated previously, the ecosystem is very large and complex. There are over 1,200 different POS applications/devices running various versions of operating systems, patch levels, POS software revisions etc.,  which use the First Data infrastructure.  Most of these are managed by third party providers, outside of First Data control.<br>
<br>
Given the complexity of device ownership it would be impossible to survey all devices and the list of roots that they trust.<br>
<span class=""><br>
<br>
> FD Response: FD initially communicated a June 30th deadline which<br>
> would have provide a four month buffer before final expiry of existing<br>
> certificates.<br>
<br>
...under the wholly unrealistic scenario that everyone met the first deadline.<br>
<br>
</span>[First Data] Agreed.  As stated in the response to question #8 “Additional steps in the future would be to conduct readiness tests much farther in advance.” We would definitely consider this a lesson learned and will be moving our internal deadlines up much further in the future.<br>
<span class=""><br>
<br>
> Several large merchants and banks working on remediation plans through<br>
> efforts such as contacting clients, upgrading POS software and/or<br>
> deploying new compliant POS hardware requested that we extend the<br>
> deadline to August 1st, which we did.<br>
<br>
So the remaining 25% are all customers of banks not in that set?<br>
<br>
</span>[First Data] The 25% are comprised of primarily small and medium sized  merchants with the complexity described in previous responses.<br>
<span class=""><br>
> FD Response:  There are valid circumstances that would prevent<br>
> communications from reaching the end user.<br>
<br>
If you are one end of a secure connection and you can't communicate security-related information to the person controlling the other end, even when given 12 months to do it, you are doing it wrong.<br>
<br>
</span>[First Data]  As explained, FD doesn't have a direct business relationship with many of the merchants. The communication and administration of POS devices are handled by the POS vendors who sold the merchants their POS system.<br>
<span class=""><br>
> Most of these clients are small merchants with limited IT industry<br>
> knowledge.  Many of them have bought/sold their businesses, inheriting<br>
> the POS device.  Some have changed banking relationships.<br>
> Others don’t have an active relationship with their POS vendor, or for<br>
> many other reasons, may not even know who administers their POS<br>
> system.<br>
<br>
And yet you still accept, validate and process card transactions from these anonymous and uncontactable people?<br>
<br>
</span>[First Data]  First Data provides an infrastructure that is made available through multiple financial institutions and sales channels that have the direct relationship with the merchants.  We have identified the non-compliant merchants to these institutions and sales channels.<br>
<br>
In addition to these communication efforts, we are planning shorts burst upgrades to our network to further raise awareness and drive compliance.<br>
<span class=""><br>
You don't need IT industry knowledge to receive a package with a credit card terminal in it and plug it in, in place of your existing one. What happens if one model of terminal turns out to have e.g. a broken RNG and trivially-crackable crypto? Or leaks the private key? Would it take over a year to replace all those, for the same reasons?<br>
<br>
</span>[First Data]  The comparison to the sale of a broken or defective terminal is not applicable to this situation.  Where First Data has supplied the POS systems to merchants, those systems are fully compliant.  The issue is not one of our replacing POS systems that we have supplied to merchants, but in providing additional time for those merchants that are using legacy POS systems provided by third parties.  Often these third party systems meet more particularized needs of the merchants or fill some function that is different than a standard terminal. We cannot ship 300k devices to merchants that have not purchased devices from us and who have varying needs.<br>
<br>
Most of these merchants simply need a software update.   If devices cannot be upgraded the POS vendor will need to provide a new device or application.<br>
<br>
The POS provider is required maintain PCI compliance of their device.  If a known vulnerability were to be detected we would of course take appropriate action.<br>
<span class=""><br>
> Symantec: Links to the crt.sh entries were provided at the top of each<br>
> certificate's disclosure in the second email. Each of the candidate<br>
> toBeSigned certificates match the logged certificates they replace<br>
> with the exception of the serial number and validity period.<br>
> Matching was preserved to the extent of using T61String encoding, SGC<br>
> EKU, and BR compliance policy OIDs from our arc rather than the<br>
> CABF's.<br>
<br>
Good.<br>
<br>
> FD Response:  FD proposes an alternative that can highlight the need<br>
> to address this issue without causing a sustained impact that would be<br>
> more disruptive to merchant businesses.<br>
><br>
> Beginning in the first week of October, FD is planning to conduct what<br>
> we are calling “Short Burst” upgrades. We will regularly and<br>
> continually upgrade to SHA-2 for short intervals on varying dates and<br>
> times of day.  Non-compliant clients will be unable to process during<br>
> these burst upgrade periods which should induce corrective measures.<br>
<br>
Now that is a good idea. We are now six days into October; how's it going?<br>
<br>
</span>[First Data]  Based upon demands from our Distribution Systems, we will be starting this exercise on Tuesday October 18th.<br>
<span class="im HOEnZb"><br>
<br>
<br>
-----Original Message-----<br>
From: Gervase Markham [mailto:<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>]<br>
</span><span class="im HOEnZb">Sent: Thursday, October 06, 2016 11:30 AM<br>
To: Dean Coclin <<a href="mailto:Dean_Coclin@symantec.com">Dean_Coclin@symantec.com</a>>; CABFPub <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
Cc: Halliday, Morgan <<a href="mailto:Morgan.Halliday@firstdata.com">Morgan.Halliday@firstdata.com</a><wbr>>; Sidoriak, Evan S <<a href="mailto:Evan.Sidoriak@firstdata.com">Evan.Sidoriak@firstdata.com</a>><br>
Subject: Re: [cabfpub] SHA-1 exception request<br>
<br>
</span><div class="HOEnZb"><div class="h5">On 03/10/16 15:26, Dean Coclin wrote:<br>
> FD Response: We tested a private root and determined that this would<br>
> not work for all affected clients. Modern POS systems would not have<br>
> the pulled root and would need to manually add the private root.<br>
<br>
Hang on... in the last 12 months, this company has continued to ship products with a root store based on the one browsers are choosing to ship, and so have followed our root removal policy blindly? Rick Andrews was telling me what a dumb idea this was back in the last decade. Please tell me that isn't so.<br>
<br>
And also, you can adopt what is now fairly mainstream technology, and serve a cert based on the client capabilities as determined by client HELLO - a new SHA256 one to modern terminals, or an older SHA1 one from a pulled root to older terminals. This would have been more than possible if you hadn't waited until 2 weeks before deadline day.<br>
<br>
> The<br>
> level of effort involved would be similar to if not greater than just<br>
> upgrading or replacing Non SHA-2 compliant devices.<br>
<br>
No, the level of effort involved in reconfiguring your servers is not comparable to the level of effort involved in replacing 300,000 shipped devices.<br>
<br>
> Given the size and diversity of the POS device population there are no<br>
> pulled roots that would remediate a significant portion of the<br>
> 300,000 clients at risk.<br>
<br>
We've had this a couple of times now. Who makes these devices, how many different types are there, and what is the full list of roots in each model? Presumably you have that data in order to make this statement.<br>
<br>
> FD Response: FD initially communicated a June 30th deadline which<br>
> would have provide a four month buffer before final expiry of existing<br>
> certificates.<br>
<br>
...under the wholly unrealistic scenario that everyone met the first deadline.<br>
<br>
> Several large merchants and banks working on remediation plans through<br>
> efforts such as contacting clients, upgrading POS software and/or<br>
> deploying new compliant POS hardware requested that we extend the<br>
> deadline to August 1st, which we did.<br>
<br>
So the remaining 25% are all customers of banks not in that set?<br>
<br>
> FD Response:  There are valid circumstances that would prevent<br>
> communications from reaching the end user.<br>
<br>
If you are one end of a secure connection and you can't communicate security-related information to the person controlling the other end, even when given 12 months to do it, you are doing it wrong.<br>
<br>
> Most of these clients are small merchants with limited IT industry<br>
> knowledge.  Many of them have bought/sold their businesses, inheriting<br>
> the POS device.  Some have changed banking relationships.<br>
> Others don’t have an active relationship with their POS vendor, or for<br>
> many other reasons, may not even know who administers their POS<br>
> system.<br>
<br>
And yet you still accept, validate and process card transactions from these anonymous and uncontactable people?<br>
<br>
You don't need IT industry knowledge to receive a package with a credit card terminal in it and plug it in, in place of your existing one. What happens if one model of terminal turns out to have e.g. a broken RNG and trivially-crackable crypto? Or leaks the private key? Would it take over a year to replace all those, for the same reasons?<br>
<br>
> Symantec: Links to the crt.sh entries were provided at the top of each<br>
> certificate's disclosure in the second email. Each of the candidate<br>
> toBeSigned certificates match the logged certificates they replace<br>
> with the exception of the serial number and validity period.<br>
> Matching was preserved to the extent of using T61String encoding, SGC<br>
> EKU, and BR compliance policy OIDs from our arc rather than the<br>
> CABF's.<br>
<br>
Good.<br>
<br>
> FD Response:  FD proposes an alternative that can highlight the need<br>
> to address this issue without causing a sustained impact that would be<br>
> more disruptive to merchant businesses.<br>
><br>
> Beginning in the first week of October, FD is planning to conduct what<br>
> we are calling “Short Burst” upgrades. We will regularly and<br>
> continually upgrade to SHA-2 for short intervals on varying dates and<br>
> times of day.  Non-compliant clients will be unable to process during<br>
> these burst upgrade periods which should induce corrective measures.<br>
<br>
Now that is a good idea. We are now six days into October; how's it going?<br>
<br>
Gerv<br>
</div></div><br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>