1

I am quite familiar with the ROC but am not a QSA.

PCI definition of strong cryptography make references to choosing your own standard and follow that, for example; if I followed NIST i.e. TLS as specified by Special Publication 800-57 Part 1 section 5.6.2 and I don't choose RSA and only use Diffie-Hellman key exchanges then keys smaller than 2048 bits do not meet the PCI DSS requirements?

That is an interpretation narrowly focused on weak public key bits, what about all of the other aspects of a TLS connection that may be considered problematic? Just look at the SSL Labs reports for an example of how long this list may be.

Also what about using mTLS, is not using mTLS for TLS connections where both endpoints are within your control considered problematic? I would assume it is.

And then there's the nuance related to client certificates; how should client certificate issuers be determined, which trust anchor should be used (device trust stores are for determining trust anchors of the server certificate chain), do clients need to adhere to the server's indication/list of acceptable client certificate subjects (some issuer subject's have no CN e.g. Amazon ACM so shouldn't issuer matching be based on Issuer SKI == Cert AKI??), shouldn't the client be skeptical of the server endpoint authenticity also and validate the security posture/expectations of the server handshake?

These are only 4 client certificate thoughts off the top of my head, there are plenty more I'm sure of it.

My question to be concise is; is there any authoritative source, specifically a framework/standard that meets the PCI requirement of something that can be followed for your implementation, of all the TLS security considerations and the secure configurations for both client and server endpoints?

I've searched NIST and found some useful scattered references, OWASP has limited also scattered hints, SAFECode and CIS are sparse in this area, ISF is completely useless (and costs way too much for it's value). I'm not sure where else to look.

1

My question to be concise is; is there any authoritative source, specifically a framework/standard that meets the PCI requirement of something that can be followed for your implementation, of all the TLS security considerations and the secure configurations for both client and server endpoints?

The concise answer to your concise question, is no. Only the standard and the glossary are Normative.

Remember, PCI DSS is a baseline security standard. not a good-practice manual, and that's partially because what was good practice in 2016 would not remain so through the lifetime of the standard. That's one reason it is great at saying what you can't use (SSL) but very reticent to say what you can or should use.

The glossary definition of Strong Cryptography has two basic requirements.

  • Key size: > 112 bits of effective key strength
  • Algorithm: industry-tested and accepted (i.e. don't write your own)

The standard has the three requirements that are listed in 4.1.

  • Trusted keys and certificates
  • Secure versions or configs
  • Encryption strength is appropriate (see glossary)

If an implementation meets those requirements, it passes PCI DSS. It is up to the entity to document how they do this and for the assessor to validate that approach. The standard doesn't say "choose your own standard and follow that". It says (paraphrasing) that documents from standards bodies can help you work out what's currently regarded by the industry as "strong cryptography and security protocols".

And honestly, from your question, you probably understand more about TLS than the average QSA -- so make good security decisions, document your choices and how they meet the requirement, and that should satisfy your assessor.

You may also find the following PCI SSC FAQs useful:

1491: Does PCI DSS define which versions of TLS must be used? https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Does-PCI-DSS-define-which-versions-of-TLS-must-be-used

1461: What are the security considerations for TLS 1.3? https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-are-the-security-considerations-for-TLS-1-3

And honestly, @gowenfawr's answer:

No, there isn't.

Was as correct as this.

1
  • Thank you for your answer, agree at a glance both yours and @gowenfawr's answer are basically saying the same message but at least you've described exactly why which makes this something i'm happy to accept thank you!
    – Stof
    Nov 1 '21 at 23:02
3

My question to be concise is; is there any authoritative source, specifically a framework/standard that meets the PCI requirement of something that can be followed for your implementation, of all the TLS security considerations and the secure configurations for both client and server endpoints?

No, there isn't.

The PCI SSC provides very limited guidance, such as the large effort around Migrating from SSL and Early TLS. But even then they only touched on the TLS version and had this vague language to cover everything else:

In addition to providing support for later versions of TLS, ensure your TLS implementation is configured securely. Ensure you’re supporting secure TLS cipher suites and key sizes, and disable support for other cipher suites that are not necessary for interoperability. For example, disable support for weak “Export-Grade” cryptography,

They did also clarify ciphers that many had been retiring anyway:

Additionally, use of weak cipher suites or unapproved algorithms – e.g., RC4, MD5, and others – is NOT allowed.

Aside from that, who decides what's "configured securely"? ASVs and QSAs. They're the ones who initially said, for example, RC4 is bad so stop using it. And at least for QSAs, half the time they're running down a printout of SSL Labs and deciding what you need to address from that.

1
  • Part of your answer refers to my own reference of SSL Labs, and it includes only a guide for migration away from SSL not how to compliantly configure modern TLS considering TLSv1 in 2018 deprecated by PCI Council themselves and TLSv1.1 no longer works in major browsers. I'll await a more direct (if one comes) answer and accept that. thank you for the commentary but this is not an acceptable 'answer'
    – Stof
    Oct 31 '21 at 0:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.