Dear Rob,
I'm sorry, but you seem to be looking at the wrong documents (awfully clueless and misleading documents admittely). Some of what the clueless documents say is formally provable nonsense,
and it is in contradiction to the actual specification.
The applicable PCI specification is PCU 3.2 (April 2016), what is relevant, and the true (and reasonable) technical requirements about SSL/TLS are described in Appendix A.2 of the PCI 3.2 spec.
https://www.pcisecuritystandards.org/document_library
The cryptographic differences between TLSv1.0 and TLSv1.1 are marginal. The alleged (TLSv1.0 CBC) weakness can only be exploited when the attacker has profound control over a communication endpoint, for "recovering plaintext through repeated guessing". The alleged weakness can be reliably mitigated by 1/(n-1) record splitting (the well-known BEAST countermeasure) for those scenarios where the weakness is relevant at all (which is _only_ Web-Browsers and SSL-VPNs in combination with disclosing authentication). When using SSL client cert authentication, the weakness becomes entirely irrelevant (actually irrelevant even for SSLv3). For programmatic clients, which neither execute arbitrary attacker-supplied active content, not provide a CSRF-vulnerability to that attacker-supplied active content, and not perform any app-level well-known insecure TLS protocol "Downgrade Dance"s (the Web Browser design flaw that is a prerequisite to POODLE), the known weakness are irrelevant.
Quoting PCI DSS 3.2, Appendix A.2
-----------
The SUMMARY(!!) says:
SSL and early TLS should not be used as a security control to meet these requirements. To support entities working to migrate away from SSL/early TLS, the following provisions are included:
- New implementations must not use SSL or early TLS as a security control.
- All service providers must provide a secure service offering by June 30, 2016.
- After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
- After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
- Prior to June 30, 2018, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.
- POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.
--------------
The actual technical requirements:
----------------
A2.1 Where POS POI terminals (and the SSL/TLS termination points to which they connect) use SSL and/or early TLS, the entity must either:
* Confirm the devices are not susceptible to any known exploits for those protocols.
Or:
* Have a formal Risk Mitigation and Migration Plan in place.
A2.3 Additional Requirement for Service Providers Only: All service providers must provide a secure service offering by June 30, 2016.
Note: Prior to June 30, 2016, the service provider must either have a secure protocol option included in their service offering, or have a documented Risk Mitigation and Migration Plan (per A2.2) that includes a target date for provision of a secure protocol option no later than June 30, 2016. After this date, all service providers must offer a secure protocol option for their service.
-----------------
Must offer a secure protocol option for their service means that the service providers must support and prefer TLSv1.2 when offered. This does *NOT* mean, that they should (or would have to) disable TLSv1.1 or TLSv1.0.
-Martin