Implementation Guidance for the PKCS #1 RSA Cryptography Specification
draft-irtf-cfrg-rsa-guidance-10

[Ballot comment]
I agree with Alvaro that the IRTF cannot deprecate features of an IETF specification, nor should it really update an IETF-stream RFC. I'd also note that the IETF (via the TLS WG) only recently approved RFC9963 as a proposed standard - this document would have to also update that. As-is, I'd expect the IESG to consider this document a conflict when/if it did an RFC5742 review. I think the best way to handle the issue is for this document to not formally try deprecate anything in IETF-stream RFCs, nor to update any IETF-stream RFCs, but just change the language to say pkcs1v1.5 is e.g. 'NOT RECOMMENDED' by CFRG or some such. Any other approach would seem liable to generate more process work than is worthwhile.

The comments below can be taken or ignored, unlike the above, they're totally non-blocking:

- I wondered if any RSA code implementer had reviewed the text - could be good to see what such a person (who is the prime target audience here) thought.
- Sections 6.4 and 6.5 seem a bit unclear to me - I've not re-read [kocker96] so forget if it explains exactly this method of blinding, if not, then maybe more refs are needed?
- I'd keep the reference to the TLS fuzzer github repo (unless it's known that that will change soon).

[Ballot comment]
The document formally updates RFC 8017, which is an IETF document. It makes sense to me.

Has there already been coordination with the IETF stream manager regarding that relationship?

This comment is to make sure the administrative step has taken place.

[Ballot comment]
The draft looks to be missing the text required by RFC 5743 Section 2.1. These guidelines are especially important for CFRG drafts, since there's frequent confusion about their status as IRTF documents. Once those statements are added, I believe the draft will be ready for publication.

Document summary
This document specifies additions and amendments to RFC 8017, "PKCS #1: RSA Cryptography Specifications". Its primary purpose is to provide concrete guidance to implementers on protecting RSA implementations against a wide range of side-channel attacks. The document also formally deprecates the RSAES-PKCS-v1_5 encryption scheme for all new protocols, citing its inherent fragility. However, for legacy systems where removing PKCS#1 v1.5 is not feasible, it provides a novel and robust alternative depadding algorithm based on implicit rejection. This mechanism is designed to mitigate Bleichenbacher-style padding oracle attacks that arise from vulnerable APIs. The overall goal of the specification is to significantly increase the security and robustness of RSA implementations in practice. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Research Group Summary
The document has undergone extensive review within the CFRG. Prior to the Research Group Last Call (RGLC), the draft was formally reviewed by two members of the Crypto Review Panel: Jon Callas and Scott Fluhrer. Their comments were fully addressed in version -04 of the draft. A 3-week RGLC was initiated for version -04 in August 2025. The document received strong support for publication. During the RGLC, a very detailed review was provided by Maximilian Lorlacks from an implementer's perspective, which led to a productive discussion with the author. The feedback resulted in numerous editorial improvements and clarifications, which were incorporated into version -05 of the draft. Further minor clarifications from Jeffrey Goldberg were addressed in version -06. All comments were fully processed, and no issues were left unresolved. The RGLC concluded successfully in September 2025.

Document Quality
The guidance in this document is supported by a public reference implementation of the proposed implicit rejection mechanism, available in the author's tlslite-ng Python library [1]. This implementation served to generate the comprehensive set of test vectors included in the document's appendix, demonstrating the practicality and correctness of the proposed algorithms. While the Python code serves as an excellent algorithmic blueprint, the document notes that true constant-time properties depend on the specific language, compiler, and hardware environment. Implicit rejection for RSAES-PKCS-v1_5 was made in OpenSSL [2], starting from version 3.2.0, and Mozilla [3], starting from version 3.61. No IPR disclosures related to the described techniques have been made, and the participants are not aware of any IPR that would encumber the implementation of this guidance.

Personnel
Stanislav Smyshlyaev is the Document Shepherd.
Colin Perkins is the IRTF Chair.

[1] https://github.com/tlsfuzzer/tlslite-ng/blob/master/tlslite/utils/python_rsakey.py
[2] https://github.com/openssl/openssl/pull/13817
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1651411

Document summary
This document specifies additions and amendments to RFC 8017, "PKCS #1: RSA Cryptography Specifications". Its primary purpose is to provide concrete guidance to implementers on protecting RSA implementations against a wide range of side-channel attacks. The document also formally deprecates the RSAES-PKCS-v1_5 encryption scheme for all new protocols, citing its inherent fragility. However, for legacy systems where removing PKCS#1 v1.5 is not feasible, it provides a novel and robust alternative depadding algorithm based on implicit rejection. This mechanism is designed to mitigate Bleichenbacher-style padding oracle attacks that arise from vulnerable APIs. The overall goal of the specification is to significantly increase the security and robustness of RSA implementations in practice. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.

Research Group Summary
The document has undergone extensive review within the CFRG. Prior to the Research Group Last Call (RGLC), the draft was formally reviewed by two members of the Crypto Review Panel: Jon Callas and Scott Fluhrer. Their comments were fully addressed in version -04 of the draft. A 3-week RGLC was initiated for version -04 in August 2025. The document received strong support for publication. During the RGLC, a very detailed review was provided by Maximilian Lorlacks from an implementer's perspective, which led to a productive discussion with the author. The feedback resulted in numerous editorial improvements and clarifications, which were incorporated into version -05 of the draft. Further minor clarifications from Jeffrey Goldberg were addressed in version -06. All comments were fully processed, and no issues were left unresolved. The RGLC concluded successfully in September 2025.

Document Quality
The guidance in this document is supported by a public reference implementation of the proposed implicit rejection mechanism, available in the author's tlslite-ng Python library [1]. This implementation served to generate the comprehensive set of test vectors included in the document's appendix, demonstrating the practicality and correctness of the proposed algorithms. While the Python code serves as an excellent algorithmic blueprint, the document notes that true constant-time properties depend on the specific language, compiler, and hardware environment. The corresponding fix for OpenSSL [2] took place in 3.2.0. The corresponding fix for Mozilla [3] took place in 3.61. No IPR disclosures related to the described techniques have been made, and the participants are not aware of any IPR that would encumber the implementation of this guidance.

Personnel
Stanislav Smyshlyaev is the Document Shepherd.
Colin Perkins is the IRTF Chair.

[1] https://github.com/tlsfuzzer/tlslite-ng/blob/master/tlslite/utils/python_rsakey.py
[2] https://github.com/openssl/openssl/pull/13817
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1651411