PKI Consortium blog
Posts by tag IETF
Preparing for Quantum Computing
April 21, 2020 by
Diana Gruhn
(Entrust)
ECC
IETF
NIST
Quantum
RSA
Quantum computing is advancing, and while experts are not sure when there will be a quantum computer powerful enough to break the RSA and ECC cryptographic algorithms that are currently in use, many are operating under the assumption that this can happen within a 10-15 year timeframe.
CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly
December 6, 2018 by
Bruce Morton
(Entrust),
Chris Bailey
(Entrust),
Jay Schiavo
(Entrust)
Apple
Attack
CASC
Chrome
DV
Encryption
EV
Firefox
Google
Identity
IETF
Malware
Microsoft
Phishing
SSL/TLS
TLS 1.0
TLS 1.2
TLS 1.3
As the legendary coach of the NY Yankees Yogi Berra allegedly said, “It’s difficult to make predictions, especially about the future.” But we’re going to try.
Here are the CA Security Council (CASC) 2019 Predictions: The Good, the Bad, and the Ugly.
The Good
Prediction: By the end of 2019, over 90% of the world’s http traffic will be secured over SSL/TLS
TLS 1.3 Includes Improvements to Security and Performance
April 10, 2018 by Tim Shirley Forward Secrecy IETF SSL/TLS TLS 1.2 TLS 1.3 VulnerabilityLast month saw the final adoption, after 4 years of work, of TLS version 1.3 by the Internet Engineering Task Force (IETF). This latest iteration of the protocol for secure communications on the internet boasts several noteworthy improvements to both security and performance:
Security
All cipher suites that do not provide forward secrecy have been eliminated from TLS 1.3. This is a very important security property, because without forward secrecy, if a server’s private key is compromised today, any previously-recorded conversations with that server dating back as long as the key was in use could be decrypted. While it is possible (and highly recommended) to configure a server with TLS 1.2 to prefer (or only support) cipher suites that provide forward secrecy, under TLS 1.3 these are the only option. Other cryptographic modernizations in TLS 1.3 include the elimination of DSA, custom DHE groups, and compression.
Certificate Transparency Deadline Moved to April 2018
May 3, 2017 by Bruce Morton (Entrust) Chrome Google IETF Policy SSL/TLSGoogle just announced they will not be enforcing certificate transparency (CT) logging for all new TLS certificates until April 2018. In a previous blog post, we advised that Google provided a new policy, which required new TLS certificates to be published to the CT logs in order for the domain to be trusted by Chrome.
The reason for the delay was not clear, but Google needs to consider the following:
- Overall CT policy discussions with the major stakeholders are underway, but we are still far away from a conclusion.
- Other browsers appear to be supporting CT, but have yet to determine their policies or advance their browser code.
- The CT deployment document, RFC 6962-bis, tracked by IETF standards has not been released.
- The proposed document for CT Domain Label Redaction that addresses privacy has started, but has not been adopted or completed by the IETF.
- Sufficient, scalable, and reliable CT logs have not been deployed by the ecosystem to address the increase in requirements.
Certification authorities (CAs) as well as TLS certificate subscribers will welcome the extra time to help ensure that deployment of CT logging is efficient and seamless.
Google Certificate Transparency (CT) to Expand to All Certificates Types
November 8, 2016 by Jeremy Rowley Announcement CA/Browser Forum Chrome DV EV Google IETF OV Policy SSL/TLSThe policy change goes into effect October 2017
A recent Google announcement stated that all publicly trusted SSL/TLS certificates issued in October 2017 or later will be expected to comply with Chrome’s Certificate Transparency (CT) policy or be untrusted by the browser.
SSL 2.0 and DROWN
April 4, 2016 by Bruce Morton (Entrust) Attack IETF OpenSSL SSL 3.0 SSL/TLS VulnerabilityA team of researchers has announced a vulnerability with SSL 2.0 called Decrypting RSA with Obsolete and Weakened eNcryption; otherwise known as DROWN.
SSL 2.0 is a version of the SSL/TLS security protocols. It was released in February 1995, but due to security flaws was superseded by SSL 3.0 in 1996.
DROWN is a cross-protocol attack where the bugs in SSL 2.0 can be used to attack the security of connections that use TLS. The vulnerability applies to servers:
2016 – Looking Back, Moving Forward
December 14, 2015 by Bruce Morton (Entrust) Attack CA/Browser Forum CAA Chrome Code Signing DH Encryption Firefox Google Hash Function IETF Microsoft MITM OpenSSL Policy RC4 Revocation RSA SSL/TLS TLS 1.2 TLS 1.3 VulnerabilityLooking Back at 2015
A number of new tactics proved 2015 was no exception to an active year defending against ever increasing security issues. Vendors found new and creative ways to provide vulnerabilities including the now popular man-in-the-middle (MitM) attacks. MitM as well as a host of other new vulnerabilities caused browsers to rethink their security requirements. This article gives a flashback of the exploits and industry changes from 2015 and looks ahead at the latest security requirements and how it impacts IT security teams.
New Directions for Elliptic Curve Cryptography in Internet Protocols
June 24, 2015 by Rick Andrews ECC ECDSA IETF NIST RSA SSL/TLSLast week I attended and presented at the National Institute of Standards and Technology (NIST) Workshop on Elliptic Curve Cryptography Standards. In NIST’s words, “The workshop is to provide a venue to engage the crypto community, including academia, industry, and government users to discuss possible approaches to promote the adoption of secure, interoperable and efficient elliptic curve mechanisms.”
We began by discussing the reasons for holding this workshop. Speakers acknowledged that although there are no known issues with the current set of NIST curves, in some circles they are widely distrusted. In addition, they are almost 15 years old, not particularly resistant to side-channel attacks, and don’t perform as well as newer curves. For these reasons, many people feel that NIST should standardize on one or more new curves.
HTTP/2 Is Speedy and Secure
April 20, 2015 by Wayne Thayer Announcement Chrome Firefox Forward Secrecy Google HSTS IETF Microsoft Mozilla SSL/TLS VulnerabilitySince we last wrote about SSL/TLS performance, there has been a lot of activity in the IETF HTTP Working Group, resulting in the February announcement that the next version of HTTP has been approved. This is big news because it means that major SSL/TLS performance improvements are on the way.
Background
When your browser connects to a website today, it most likely uses the HTTP/1.1 protocol that was defined in 1999 in RFC 2616. Over the past 15 years, HTTP/1.1 has served us well and many tweaks have been discovered to make the most of it. However, in that time the web has transformed into a platform for interactive content and applications. Today, browsers load much more data from many more sources to build the typical web page.
My Website’s SSL Certificate is Fine; Why Do Browsers Downgrade the Security Indicators For My Site?
April 1, 2015 by Rick Andrews Attack Chrome Encryption EV IETF RC4 SSL/TLSAll the major browsers provide “security user interface”, meaning visual elements to inform the user of the security of their connection to the web page they’re visiting. Up until now, those interface elements were tied to the use of SSL/TLS certificates served by the web site. For example, if you went to http://www.example.com, no special elements would be displayed, but if you visited https://www.example.com, you would see a lock icon indicating the presence of a trusted SSL/TLS certificate. You would also see in the address bar the name of the company responsible for the web site, if the web site used an EV certificate. Most browsers change user interface indicators for mixed content (when a secure page loaded scripts, images or other content from a non-secure site).
