Deprecate TLS v1.2 for PCI-DSS v3.2.1 Requirement 2.2.3 #979
Comments
|
“Early TLS” cites TLS 1.0 and 1.1. I see nothing in PCI-DSS suggesting the deprecation of TLS 1.2.
|
|
The Federal Government standards require that TLS1.3 be supported by January 2024 so this proposal does appear somewhat premature both for PCI-DSS and for OWASP. |
PCI-DSS v3.2.1 states "Refer to industry standards and best practices for information on strong cryptography and secure protocols (e.g., NIST SP 800-52 and SP 800-57, OWASP, etc.).". Therefore, in order to maintain our leadership position OWASP must deprecate TLS v1.2 @jmanico. |
Are you referring to NIST SP 800-52 Rev. 2 @markehack? The Australian Cyber Security Centre |
|
You end up with a competing set of standards and directives and
imprecise statements and some present v future proofing conundrums
while we wait for the Quantum resistant ciphers to shake out.
Nist-800-131a initially forbit both RSA handshakes and 3DES and then
later placed them on the deprecated list. Removing both of these and
requiring PFS seems to be a good balance between security and
compatibility.
TLS1.3 removed all CBC ciphers, DHE handshakes and SHA1 HMACs for a mix
of reasons not all of them directly due to any vulnerability. (Risk yes
)
TLS1.3 still does not force re-negotiation based on time or traffic so
care needs to be taken with even AES128 GCM
Requiring support for a newer protocol and cipher set is wise , while
forbidding the usage, especially of a protocol may be a good security
requirment but can and will impact compatibility. In general a balance
between the two and reasonable times to remove the ciphers and
protocols seems a wiser choice than complete removal.
…On Sat, 2021-05-01 at 14:34 -0700, Christian Heinrich wrote:
> The Federal Government standards require that TLS1.3 be supported
> by January 2024 so this proposal does appear somewhat premature
> both for PCI-DSS and for OWASP.
Are you referring to NIST SP 800-52 Rev. 2 @markehack?
The Australian Cyber Security Centre
states "TLS 1.3 removed vulnerable cipher suites found in TLS 1.2,
while introducing stronger cipher suites." and advises to "Begin
transitioning from TLS 1.2 to TLS 1.3" etc.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "
#979 (comment)",
"url": "
#979 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
As the S in OWASP is for Security then our policy in the past has deliberately not been aligned with compatibility such as @jmanico @owasp.org email to the OpenJDK security-dev mailing list Nevertheless, interim Pull Request #983 maintains backwards compatibility for TLS 1.2 rather than wait until 2024 for Pull Request #980 @markehack |
|
@cmlh, please have discussion here in the issue first, and if the change/proposal found agreement, then it's time to make PR. Discussion over pull-requests is just a mess. Discussion in PR should be targeted only for "syntax or language", not for the idea of the change itself. This is also stated in PR template. |
Christian, using things that I said in 2017 as a way to either discredit me or make me look bad is the kind of behavior that got you banned from OWASP in the first place. Consider this a polite warning. |
|
What is a good proposal is to remove all CBC ciphers. Removing SHA1
HMACs to align with TLS1.3 is also fine.
The only downside is performance since AES256-GCM only defined SHA1 and
SHA384 ( not clear why SHA256 was never defined) and most hardware
only accelerates SHA1 or SHA256.
…On Mon, 2021-05-03 at 16:31 -0700, Christian Heinrich wrote:
As the S in OWASP is for Security then our policy in the past has
deliberately not been aligned with compatibility such as @jmanico
@owasp.org email to the OpenJDK security-dev mailing list
Nevertheless, interim Pull Request #983 maintains backwards
compatibility for TLS 1.2 rather than wait until 2024 for Pull
Request #980 @markehack
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
***@***.***": "http://schema.org",
***@***.***": "EmailMessage",
"potentialAction": {
***@***.***": "ViewAction",
"target": "
#979 (comment)",
"url": "
#979 (comment)",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
***@***.***": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
|
|
There really is no cryptographic reason to deprecate TLS 1.2 completely. |
|
To address @elarlang #979 (comment) While I wanted to wait until after the release of PCI-DSS 4.0 as per #317 (comment) which would have at delayed the timeline to 2024 or later I have adhered to CONTRIBUTING.md: I created Issue #979 after the discussion within Issue #317 (comment) after @jmanico stated:
@jmanico then posted comments to Pull Request #980 (comment) against CONTRIBUTING.md before I was able to publish the other planned changes so they could be considered in their entirity. To address both @markehack #979 (comment) and @ tomato42 #979 (comment) Ultimately, I believed that @OWASP wanted to regain its leadership in Web Application Security as stated within #979 (comment) and #979 (comment) as @OWASP is referenced within PCI-DSS and therefore can push changes downstream to PCI-DSS. At the risk of repetition above I wanted to wait until after the release of PCI-DSS 4.0 as per #317 (comment) which would have at delayed the timeline to 2024 or later To address @jmanico #979 (comment) @jmanico is aware that the ban was unprovoked, unjust and has caused considerable professional harm to me as he stated in his own words within https://lists.owasp.org/pipermail/owasp-leaders/2012-July/007468 Neither was my intent to be perceived as discrediting @jmanico, rather my reference to OpenJDK security-dev mailing list was to convey @OWASP wanted to regain its leadership in Web Application Security in pushing changes downstream to PCI-DSS (again repeated above). I have decided to close this Issue #979 and will focus on making changes to CONTRIBUTING.md reflecting the above positive outcome. |
|
To quote @jmanico PR #983 (comment)
#980 (comment) is when this alternative was presented. Can @tghosth and/or @danielcuthbert and/or @vanderaj merge #983 as a minor change and close this [#979] issue and label 2024 too please? |
|
I have not checked the timeline (and it does not matter), maybe this CONTRIBUTING.md did not exists yet when Jim was asking PR from you. Back then Jim was full of enthusiasm and wanted to get old issues to move. "Discussion in issue first, PR later" was not that clearly in place, please take this context in account. Anyway, it is new CONTRIBUTING.md and in development, give it a bit of time first. My comment was with goal to point this change out. Feedback on this issue - technical issue should have focus on discussion over technical parameters and arguments, it's nice to have them here. Mailinglist history, who-when-what-was-said can be important and emotional for you, but from this issue point of view it feels a bit offtopic. It's just my opinion, I don't want to have any discussion over that or to "fight for The Only Truth" here. |
|
Hey @cmlh what do you think of a ASVS Level 2 requirement that continues to endorse TLS 1.2-1.3 and a ASVS Level 3 requirement that states to only support TLS 1.3? I think these requirements would be in conflict if we expect folks to do all requirements but would be fine if we think of the different ASVS tiers as more of risk levels. Could this work? cc @ThunderSon |
|
There is no way that only TLS1.3 will be running on a web server. Impossible. Of course, this is from an implementation point of view, and not a theoretical side (which we really shouldn't care about here). Lol, card processors are still on 3DES and AES-CBC. What if you have an IoT system that doesn't properly support TLS1.3? Or any device that isn't a PC with an up to date browser? Future proof? What if tomorrow AES-GCM is found to be broken? Let's keep the ASVS as realistic as possible. |
|
To address @jmanico #979 (comment) and @ThunderSon #979 (comment) ASVS has to determine if its guiding principal is either the latest security OR compatibility with older technologies.
If the above is true then ASVS guiding principal is compatibility with older technologies so therefore ASVS Level 1-3 should be uniform for TLS v1.2 but at the very least we should give notice to the impending change scheduled for 2024 within the next minor release(s) of ASVS. |
|
Other Sources NSA NIST AWS |
|
Given that 9.1.3 already mandates TLS 1.2 and 1.3, I am not sure I am clear on what is being added on 9.1.5. Also, I'm not sure that server side support is as important as client side support which I think is the biggest problem in deprecating versions of TLS. I agree that we should be whatever possible mandating the best possible security controls but we also have to be realistic because the more controls we include which are impossible from a business perspective, the weaker the standard gets. Perhaps the best option would be a note within 9.1.3 that companies should expect and be ready for deprecations of TLS versions? Also, as a general note (which I am not sure is documented anywhere), we don't like to include links within requirements (the links to the proactive controls are an exception which we are planning to remove in the next major release). |
|
"Perhaps the best option would be a note within 9.1.3 that companies should expect and be ready for deprecations of TLS versions?" I like this approach, I think it gives enough time for those needing to plan and prepare. Yes, TLS 1.2 will become the bare minimum and rightly so, but we are also adult enough to know that many legacy apps wont and can't support it. I'd rather we highlight the issue, get people ready and help that way |
|
@cmlh Once a compromise or decision is reached for a future version of ASVS, please don't re-open this or similar tickets if you didn't get the outcome that you obviously desire. We can't keep re-litigating the same issue over and over again. I trust my co-leads to come up with a path forward that encourages or demands better of our industry. The ASVS was one of the first standards to require the use of stronger authentication mechanisms back when that was controversial, and for more than 8 years we prohibited the use of insecure questions and answers, so we are early leaders and courageous when we need to be, but it needs to be a real likelihood that an impact is always going to happen in many different settings, rather than just a local shared wifi or hub based network. If we force people to take action on a really unlikely outcome, that's an opportunity cost to take an edge case action instead of another that might be far more impactful. This is the issue I have with PCI DSS - it has like 300 things you must do, and we still have breaches. It should be ordered with things you must do, that really do make a difference, and then the remaining 292 items are like "yeah, try this". In practice, browsers and so on will choose the best available cipher suite, and in the absence of downgrade exploits that affect any connection, and not just local ones, means the likelihood of an attacker forcing a victim to use a weaker or exploitable ciphersuite is minimal in most settings. If there is a forced downgrade attack that is realistic, applies to most corporate or shared public networks, then we should be stronger in our recommendations to require the latest TLS. ASVS 5.0 is likely to last longer than 2024, so I'm supportive of noting that TLS 1.2 will be deprecated by many common browsers and platforms prior to 2024 and plans should be in place to migrate to the latest TLS or remove older cipher suites by then. We need to be cognizant that if we say "The latest TLS cipher suites and leading algorithm choices should be the first available server offered choices, and as strongly configured as possible." and "If older TLS cipher suites, such as TLS 1.2, are required due to compatibility reasons with business-critical integrations, these older cipher suites must be offered last to prevent most users from using these weaker or potentially exploitable cipher suites." and "Regular cipher testing should be conducted to ensure that all available algorithms and cipher suites are configured strongly, ordered in the strongest to the weakest alternative, deprecated cipher suites or algorithms are removed, and the remaining choices do not create exploitable, breach confidential communications, or break the integrity of a secure communications channel." |
|
@vanderaj in general I agree, but blank requirement for server-side cipher suite ordering can be detrimental, clients running with pure software crypto stacks will prefer use of Chacha20 ciphers, while ones with hardware acceleration will likely want to use AES (both because of speed and battery usage). So I'd suggest a bit softer language on this requirement. |
|
To address @tghosth #979 (comment)
Pull Request #983 specifies the addition of 9.1.5 mandates the server side control exclude TLS 1.2 after TLS 1.3 support is released by the specific server side web technology.
I am willing to add a check box to a changes/Issue Template that I have discussed with @elarlang to disclose if an ASVS change impacts client side support of deprecating web technologies, such as for TLS 1.2, etc. However, we would also need consensus that ASVS now extends to the client side too?
These are most recent mandates tracked within #979 (comment)
I support inserting a note to document the above as proposed by @tghosth
No problem, I recommended this be explored with the OWASP Testing Guide within #992 (comment) I just need to anchor it somewhere before Issue #992 is transferred. I'll also document this within the amended Issues and Pull Request Template(s) that I am working on. |
|
Some offtopic comments (from opened issue point of view).
Translation: "I have discussed" means here some comments in this issue (#979 (comment), #979 (comment)). The smartest way at the moment in my opinion is to wait first draft of "development process" to CONTRIBUTING.md and then make changes and proposals to them. Anyhow, change-impact checkbox seems over.engineering to me and here I smell some trouble - you put a lot of time/effort to create some proposal/PR and then you are not happy when it's not agreed. On the positive side (from my point of view) - current situation shows to leaders, why clear process description is really "must have". :) |
|
Additional examples to insert into #979 (comment) RFC 8996 SANS NCSC NL Mozillia |
|
To quote @tomato42 #979 (comment)
To quote @markehack #979 (comment)
It wasn't my intention to create an ASVS Requirement[s] for the Server-Side Cipher Suite Order with this Issue #979 but it may be worth discussing in a another [new] Issue? I'll can extract the Server Side Configuration from those already listed within #979 (comment) and #979 (comment) above and any new references I add in the future below such as:
I am also not sure this is the reason for Do you also want another separate Issue for "Hardware Acceleration" or is a Markdown Task List reasonable workaround to capture this? |
|
ASVS 4.0.2:
+1 for TLS 1.3. Legacy concerns are not for developers, but for architects and managers. |
|
Another backwards compatibility issue explored on the OpenJDK Security-Dev Mailing List i.e. "TLS v1.3 extensions in TLS v1.2 handshake" |
|
Additional example to be inserted into #979 (comment) https://help.heroku.com/SXWA00YI/tls-v1-0-v1-1-end-of-life-schedule ADDED 1 October 2021 SANS - TLS 1.3 and SSL - the current state of affairs |
|
I do not want to keep issues lingering for years. We're not going to change this for 5.0 so I'm closing it for now and we can re-open as we get closer to 2024 and beyond. |
|
Just marking a placeholder for the release of PCI-DSS 4.0 |
|
Alright Christian. You’re starting to convince me that this may be prudent. Can we word this requirement so it’s a more timeless requirement like “use the most recent version of TLS” or similar?
|
|
@jmanico wrote:
We can make the decision before the publication of the next major release with consideration of https://www.nccoe.nist.gov/addressing-visibility-challenges-tls-13 and the number of implementations observed by https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report and others. |
I would like to propose that OWASP recommend the migration from TLS v1.2 to TLS v1.3 [or later] to support PCI-DSS v3.2.1 Requirement 2.2.3 reproduced below:
Therefore, V9.1 Client Communications Security will need to be modified.
The alignment with PCI-DSS v3.2.1 is tracked by GitHub Issue #317 (comment)
The text was updated successfully, but these errors were encountered: