Folks,
3850bis and 3851bis are tentatively scheduled for discussion on this
week's IESG telechat (Thursday, January 8). Those that read the IETF
Last Call email or subscribe to the saag or cfrg mailing lists
already know that I have concerns about the cryptographic key sizes
specified in these documents (especially the mandate to support 512
bit RSA in 3850bis). While the IETF Last Call was largely silent on
this issue, the saag and cfrg feedback indicate that the mandatory to
implements should not include cryptography weaker that 1024 bit RSA,
but that the interoperability concerns should be clearly specified.
I have had some private discussions with one of the authors (Sean),
and we have collaborated on some language that would reflect that
discussion. However, I understand that this was a sensitive and
somewhat controversial topic on the working group list. I would like
the working group to review the proposed RFC Editor Notes for 3850bis
and 3851bis, and confirm that these changes are acceptable given the
feedback received from the wider Internet community. That is, please
consider whether the proposed new text addresses the working group's
concerns given that the minimum strength of the mandatory to
implements need to be raised.
Early feedback would be appreciated!
Thanks,
Tim Polk
--------------------
RFC Editor Note for draft-ietf-smime-3850bis
(1) In Section 4.2., Certificate and CRL Signing Algorithms and Key
Sizes, please make the following substitution:
OLD:
The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
0 < key size < 512 : MAY (see Section 6)
512 <= key size <= 4096 : MUST (see Section 6)
4096 < key size : MAY (see Section 6)
The following are the DSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
512 <= key size <= 1023 : MAY (see Section 6)
1024 = key size : SHOULD- (see Section 6)
NEW:
The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
key size <= 1023 : MAY (see Section 6)
1024 <= key size <= 4096 : MUST (see Section 6)
4096 < key size : MAY (see Section 6)
The following are the DSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
key size <= 1023 : MAY (see Section 6)
1024 = key size : SHOULD- (see Section 6)
(2) In Section 6 Security Considerations, please make the following
substitution:
OLD:
The 4096-bit RSA key size requirement for certificate and CRL
verification is larger than the 2048-bit RSA key sizes for message
signature generation/verification or message encryption/decryption in
[SMIME-MSG] because many Root CAs included in certificate stores have
already issued Root certificates with 4096-bit key. The standard
that defines comparable key sizes for DSA is not yet available. In
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes
between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only
allowed DSA key sizes of 1024 bits. A revision to support larger key
sizes is being developed, and once it is available, implementors
ought to support DSA key sizes comparable to the RSA key sizes
recommended in this specification.
Today, 512-bit RSA and DSA keys are considered by many experts to be
cryptographically insecure.
NEW:
The 4096-bit RSA key size requirement for certificate and CRL
verification is larger than the 2048-bit RSA key sizes for message
signature generation/verification or message encryption/decryption in
[SMIME-MSG] because many Root CAs included in certificate stores have
already issued Root certificates with 4096-bit key. The standard
that defines comparable key sizes for DSA is not yet available. In
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes
between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only
allowed DSA key sizes of 1024 bits. A revision to support larger key
sizes is being developed, and once it is available, implementors
ought to support DSA key sizes comparable to the RSA key sizes
recommended in this specification. Further, 4096-bit keys are
normally only used by Root certificates and not by subordinate CA
certificates; thereby, lengthening the Root CA certificate’s validity
period.
RSA and DSA keys of less than 1024 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to sign certificates
or CRLs. Such keys were previously considered secure, so processing
previously received signed and encrypted mail may require processing
certificates or CRLs signed with weak keys. Implementations that
wish to support previous versions of S/MIME or process old messages
need to consider the security risks that result from accepting
certificates and CRLs with smaller key sizes (e.g., spoofed
certificates) versus the costs of denial of service. If an
implementation supports verification of certificates or CRLs
generated with RSA and DSA keys of less than 1024 bits, it MUST warn
the user. Implementers should consider providing a stronger warning
for weak signatures on certificates and CRLs associated with newly
received messages than the one provided for certificates and CRLs
associated with previously stored messages. Server implementations
(e.g., secure mail list servers) where user warnings are not
appropriate SHOULD reject messages with weak cryptography.
--- end of RFC Editor Note for draft-ietf-smime-3850bis ---
RFC Editor Note for draft-ietf-smime-3851bis
(1) In Section 4.2 Signature Generation, please make the following
substitution:
From:
The following are the requirements for an S/MIME agent generated RSA
signatures:
512 <= key size < 1024 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent generated DSA
signatures:
512 <= key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
To:
The following are the requirements for an S/MIME agent generated RSA
signatures:
key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : SHOULD (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for an S/MIME agent generated DSA
signatures:
key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
(2) In Section 4.3 Signature Verification, please make the following
substitution:
OLD:
The following are the requirements for S/MIME receiving agents during
signature verification of RSA signatures:
512 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for S/MIME receiving agents during
signature verification of DSA signatures:
512 <= key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
NEW:
The following are the requirements for S/MIME receiving agents during
signature verification of RSA signatures:
key size <= 1023 : MAY (see Security Considerations)
1024 <= key size <= 2048 : MUST (see Security Considerations)
2048 < key size : MAY (see Security Considerations)
The following are the requirements for S/MIME receiving agents during
signature verification of DSA signatures:
key size <= 1023 : MAY (see Security Considerations)
1024 = key size : SHOULD- (see Security Considerations)
(3) In Section 6 Security Considerations, please make the following
substitution:
OLD:
Today, 512-bit RSA and DSA keys are considered by many experts to be
cryptographically insecure.
Using weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the
specification of AES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is
no cryptography. When feasible, sending and receiving agents SHOULD
inform senders and recipients of the relative cryptographic strength
of messages.
NEW:
Using weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the
specification of AES and the ability to announce stronger
cryptographic capabilities to parties with whom you communicate,
allow senders to create messages that use strong encryption. Using
weak cryptography is never recommended unless the only alternative is
no cryptography.
RSA and DSA keys of less than 1024 bits are now considered by many
experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to protect messages.
Such keys were previously considered secure, so processing previously
received signed and encrypted mail will often result in the use of
weak keys. Implementations that wish to support previous versions of
S/MIME or process old messages need to consider the security risks
that result from smaller key sizes (e.g., spoofed messages) versus
the costs of denial of service. If an implementation supports
verification of digital signatures generated with RSA and DSA keys of
less than 1024 bits, it MUST warn the user. Implementers should
consider providing different warnings for newly received messages and
previously stored messages. Server implementations (e.g., secure
mail list servers) where user warnings are not appropriate SHOULD
reject messages with weak signatures.
--- end of RFC Editor Note for draft-ietf-smime-3851bis ---