[cabfpub] SHA-1 exception request

Dean Coclin Dean_Coclin at symantec.com
Sat Oct 8 12:44:17 UTC 2016


Responses submitted on behalf of First Data below:

On 03/10/16 15:26, Dean Coclin wrote:
> FD Response: We tested a private root and determined that this would 
> not work for all affected clients. Modern POS systems would not have 
> the pulled root and would need to manually add the private root.

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.

[FD Response] The payments ecosystem is very complex with many players. 

Where First Data provides POS systems, we are fully compliant with SHA-256.  As stated in 3.f of the original request:

“First Data has successfully updated all other internal systems, websites, networks and POS devices to SHA-256.  Where FD has control we are compliant.”
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. 

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. 


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.




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.

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.   

> The
> level of effort involved would be similar to if not greater than just 
> upgrading or replacing Non SHA-2 compliant devices.

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.



> Given the size and diversity of the POS device population there are no 
> pulled roots that would remediate a significant portion of the
> 300,000 clients at risk.

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.

[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.  

Given the complexity of device ownership it would be impossible to survey all devices and the list of roots that they trust.


> FD Response: FD initially communicated a June 30th deadline which 
> would have provide a four month buffer before final expiry of existing 
> certificates.

...under the wholly unrealistic scenario that everyone met the first deadline.

[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. 


> Several large merchants and banks working on remediation plans through 
> efforts such as contacting clients, upgrading POS software and/or 
> deploying new compliant POS hardware requested that we extend the 
> deadline to August 1st, which we did.

So the remaining 25% are all customers of banks not in that set?

[First Data] The 25% are comprised of primarily small and medium sized  merchants with the complexity described in previous responses. 

> FD Response:  There are valid circumstances that would prevent 
> communications from reaching the end user.

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.

[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. 

> Most of these clients are small merchants with limited IT industry 
> knowledge.  Many of them have bought/sold their businesses, inheriting 
> the POS device.  Some have changed banking relationships.
> Others don’t have an active relationship with their POS vendor, or for 
> many other reasons, may not even know who administers their POS 
> system.

And yet you still accept, validate and process card transactions from these anonymous and uncontactable people?

[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.

In addition to these communication efforts, we are planning shorts burst upgrades to our network to further raise awareness and drive compliance.  

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?

[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.  

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.

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. 

> Symantec: Links to the crt.sh entries were provided at the top of each 
> certificate's disclosure in the second email. Each of the candidate 
> toBeSigned certificates match the logged certificates they replace 
> with the exception of the serial number and validity period.
> Matching was preserved to the extent of using T61String encoding, SGC 
> EKU, and BR compliance policy OIDs from our arc rather than the 
> CABF's.

Good.

> FD Response:  FD proposes an alternative that can highlight the need 
> to address this issue without causing a sustained impact that would be 
> more disruptive to merchant businesses.
> 
> Beginning in the first week of October, FD is planning to conduct what 
> we are calling “Short Burst” upgrades. We will regularly and 
> continually upgrade to SHA-2 for short intervals on varying dates and 
> times of day.  Non-compliant clients will be unable to process during 
> these burst upgrade periods which should induce corrective measures.

Now that is a good idea. We are now six days into October; how's it going?

[First Data]  Based upon demands from our Distribution Systems, we will be starting this exercise on Tuesday October 18th.



-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Thursday, October 06, 2016 11:30 AM
To: Dean Coclin <Dean_Coclin at symantec.com>; CABFPub <public at cabforum.org>
Cc: Halliday, Morgan <Morgan.Halliday at firstdata.com>; Sidoriak, Evan S <Evan.Sidoriak at firstdata.com>
Subject: Re: [cabfpub] SHA-1 exception request

On 03/10/16 15:26, Dean Coclin wrote:
> FD Response: We tested a private root and determined that this would 
> not work for all affected clients. Modern POS systems would not have 
> the pulled root and would need to manually add the private root.

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.

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.

> The
> level of effort involved would be similar to if not greater than just 
> upgrading or replacing Non SHA-2 compliant devices.

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.

> Given the size and diversity of the POS device population there are no 
> pulled roots that would remediate a significant portion of the
> 300,000 clients at risk.

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.

> FD Response: FD initially communicated a June 30th deadline which 
> would have provide a four month buffer before final expiry of existing 
> certificates.

...under the wholly unrealistic scenario that everyone met the first deadline.

> Several large merchants and banks working on remediation plans through 
> efforts such as contacting clients, upgrading POS software and/or 
> deploying new compliant POS hardware requested that we extend the 
> deadline to August 1st, which we did.

So the remaining 25% are all customers of banks not in that set?

> FD Response:  There are valid circumstances that would prevent 
> communications from reaching the end user.

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.

> Most of these clients are small merchants with limited IT industry 
> knowledge.  Many of them have bought/sold their businesses, inheriting 
> the POS device.  Some have changed banking relationships.
> Others don’t have an active relationship with their POS vendor, or for 
> many other reasons, may not even know who administers their POS 
> system.

And yet you still accept, validate and process card transactions from these anonymous and uncontactable people?

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?

> Symantec: Links to the crt.sh entries were provided at the top of each 
> certificate's disclosure in the second email. Each of the candidate 
> toBeSigned certificates match the logged certificates they replace 
> with the exception of the serial number and validity period.
> Matching was preserved to the extent of using T61String encoding, SGC 
> EKU, and BR compliance policy OIDs from our arc rather than the 
> CABF's.

Good.

> FD Response:  FD proposes an alternative that can highlight the need 
> to address this issue without causing a sustained impact that would be 
> more disruptive to merchant businesses.
> 
> Beginning in the first week of October, FD is planning to conduct what 
> we are calling “Short Burst” upgrades. We will regularly and 
> continually upgrade to SHA-2 for short intervals on varying dates and 
> times of day.  Non-compliant clients will be unable to process during 
> these burst upgrade periods which should induce corrective measures.

Now that is a good idea. We are now six days into October; how's it going?

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5723 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161008/20a797db/attachment-0001.p7s>


More information about the Public mailing list