[cabfpub] SHA-1 exception request

Mon Oct 10 20:34:42 UTC 2016

Forwarding on behalf of Patrick Donahue, at Cloudflare.

On Sun, Oct 9, 2016 at 8:09 PM, Patrick Donahue <pat at cloudflare.com> wrote:

>
>
>
>> 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.
>
>
> 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.
>
> 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
> *signature_algorithm* extension that can be considered when choosing the
> appropriate certificate. Happy to provide whatever guidance we can to help
> resolve any edge cases. (Facebook has also[2] done this at scale and I'd
> be happy to make introductions there to the relevant folks.)
>
> 1 - https://blog.cloudflare.com/tls-certificate-optimization-
> technical-details
> 2 - https://www.facebook.com/notes/alex-stamos/the-sha-1-
> sunset/10153782990367929/
>
> --
>

On Sat, Oct 8, 2016 at 5:44 AM, Dean Coclin via Public <public at cabforum.org>
wrote:

> 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
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161010/4d22badc/attachment-0003.html>