I believe this is broadly covered by https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-08.html
Defining PQC algorithms in TLS 1.2 would not magically make existing TLS 1.2 software PQC-capable. You would need to update those systems regardless. So, as a practical matter, the backport does not change the immediate operational challenge here. As for what you update those systems to, TLS 1.3 has been around for seven years now. It is a well-established and robust protocol. When you go to update your TLS software to pick up PQC, you should already pick up a TLS 1.3 implementation, so there's very little operational benefit to sticking with TLS 1.2 here. You mention concerns about needing to talk to non-TLS-1.3 clients. Those non-TLS-1.3 clients will also be non-PQC, so backporting PQC to TLS 1.2 also will not help you here. It is *already* the case that: - If your server wants to support TLS 1.3 + PQC, you need to support TLS 1.3 + PQC - If your server wants to support existing TLS 1.3 clients without PQC, you need to support TLS 1.3 without PQC - If your server wants to support existing TLS 1.2 clients without PQC, you will need to support TLS 1.2 without PQC Adding another entry to this matrix (TLS 1.2 + PQC) does not simplify this calculus. Rather, it *adds* cost to you and everyone else in the ecosystem, as everyone now needs to support another mode. To correct what I suspect is your core misunderstanding here: supporting TLS 1.3 does *not mean disabling TLS 1.2*. TLS is a protocol with negotiated parameters. The client and server both support a *range* of versions and other parameters. The protocol implementations *automatically* select the best option in common. So you can (and for the near future, likely should!) deploy TLS 1.3 + PQC, TLS 1.3, and TLS 1.2 all at once. Your TLS server software is likely already makes this the default behavior. Beyond the operational costs of the backport, mechanically PQC cannot really be backported into TLS 1.2 without significant changes. Mechnically, a PQC key exchange does not fit in TLS 1.2 because the TLS 1.2 TLS_ECDHE_* cipher suites use a 1-byte length prefix on the key share. A 1-byte length prefix is only large enough for 255 bytes and PQC payloads far exceed that. So this would require a wire format change, keyed perhaps on a new cipher suite, with all the compatibility problems that it imposes. A backport would also carry some security issues. The ServerKeyExchange signature in TLS 1.2 does not sign the whole transcript, as it does in TLS 1.3, but just a pair of nonces and the key share. This is not sufficient to provide downgrade protection between a classical and post-quantum key exchange. If I recall, this attack was called "CurveSwap"? It's part of a general pattern of TLS 1.2's downgrade protection being weaker than it could have been. During a transition from weaker to stronger cryptography, such as the PQC transition, downgrade protection is an important property. So a backport to TLS 1.2 would mean first inventing a TLS 1.25 to redo most of the improvements we made in TLS 1.3. At that point, this is a different protocol and we already have a mature, robust one: TLS 1.3. On Thu, Jun 5, 2025 at 2:15 PM Arano, Edward <edward.arano= 40bofa....@dmarc.ietf.org> wrote: > Hello Apologies and not sure if this is the right place to ask this > question; but wondering if the IETF will *reconsider* adding PQC > algorithms to TLS 1.2?? > > > > Here is the problem > say all our external endpoints are communicating via > TLS 1.3 ;our clients (which most of the times we will not have control > over) will need TLS 1.3 > if the client doesn’t have tls 1.3 our > communication will need to negotiate /communicate with a lower protocol > 1.2 perhaps? If TLS 1.2 received the new PQC algorithms then it will > create less havoc on many organizations just trying to communicate securely > > > > Has this organization considered that it most likely wont be possible for > all to communicate with TLS 1.3 when this Post Quantum Day occurs? > > > > > > > > Apologies again if my question is wrongly placed but if someone please > help me understand why TLS 1.2 cannot handle the new PQC algorithms > > > > > > Kind Regards > > > > *Edward Arano* > > > > *Cyber Security Architect * > > Confidentiality Warning: This e-mail contains information intended only > for the use of the individual or entity named above. If the reader of this > e-mail is not the intended recipient or the employee or agent responsible > for delivering it to the intended recipient, any dissemination, publication > or copying of this e-mail is strictly prohibited. The sender does not > accept any responsibility for any loss, disruption or damage to your data > or computer system that may occur while using data contained in, or > transmitted with, this e-mail. > > If you have received this e-mail in error, please immediately notify us by > return e-mail. Thank you. > > > > > > > > > ------------------------------ > This message, and any attachment(s), is for the intended recipient(s) > only, may contain information that is privileged, confidential and/or > proprietary and subject to important terms and conditions available at > http://www.bankofamerica.com/electronic-disclaimer. If you are not the > intended recipient, please delete this message. For more information about > how Bank of America protects your privacy, including specific rights that > may apply, please visit the following pages: > https://business.bofa.com/en-us/content/global-privacy-notices.html > (which includes global privacy notices) and > https://www.bankofamerica.com/security-center/privacy-overview/ (which > includes US State specific privacy notices such as the > http://www.bankofamerica.com/ccpa-notice). > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
