Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt

From: Paul Hoffman <[email-masked]>
Date: Sun, 3 Aug 2008 16:27:36 +0100

At 2:17 PM +0100 7/28/08, Jim Schaad wrote:
>Comments on the draft:
>
>1.  We are not currently making any support statements for DSA w/ the
>SHA-256 hash algorithms.  Should we be doing so?

Yes and no. Yes in the sense that US government users who use DSA 
will want DSA-with-SHA-256. No in the sense that there is no 
appropriate level of standards support that makes sense: SHOULD is 
too strong, given current deployments.

>2.  For key size support, key of L>1024 are not supported for DSA-SHA-1.

Arrgh. Quite right. Sections 4.2 and 4.3 need to be rewritten to 
indicate that anything greater than 1024 is about RSA *only*.

>3.  I would like to add the following text to the table.
>
>Key size > 4096   MAY NOT (See security considerations on large keys)
>
>This would finish the table entry out and also reference the discussion on
>why very large keys are not recommended.  It is possible that MAY NOT is not
>currently valid 2119 language.  In this case I would be happy with ether MAY
>or SHOULD NOT.  I would not be happy with MUST NOT.

"MAY NOT" is not part of 2119. Further, we do not have enough 
evidence to know size key is "too large". Further still, the number 
will be different for receivers of RSA and DSA keys, I believe.

"MAY" makes no sense. "SHOULD NOT" is too strong, I believe, without 
more than just data-less guessing on our part.

At 4:43 PM +0100 7/31/08, Jim Schaad wrote:
>I really feel that we need to have two MUST signature algorithms for safety.
>When ECC signatures where present that was fine.  Without having the ECC
>signature algorithms we really must have one of the DSA algorithms as a must

I disagree. If RSA falls for some reason that cannot be fixed with 
longer key sizes, a "SHOULD" on DSA-SHA256 for fallback reasons 
assumes that the attack on RSA will not apply to DSA, which seems 
like a stretch. Having a "SHOULD" for a fallback seems reasonable.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 Aug 2008 19:44:42 +1000

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Sunday, August 03, 2008 8:28 AM
> To: Jim Schaad; Sean P. Turner; 'Blake Ramsdell'
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
> 

I can deal with a SHOULD+ for this 

> more than just data-less guessing on our part.

I am perfectly willing to use a non standards word here.  For example,
permitted.  I thought I saw enough consensus from the list that keys over
this size will have either real-estate constraints or performance
constraints.  Either would be covered by referring to a security
considerations discussion to this effect.  I don't want to say or imply that
keys longer than 4096 are not to be handled.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Aug 2008 08:06:31 -0700

>I can deal with a SHOULD+ for this

In retrospect, I agree with Jim and I'm happy with SHOULD+ for 
DSA-with-SHA-256 for both sending and receiving. It's not that big of 
a change from 3851.

>keys longer than 4096 are not to be handled.

Proposed wording:

Receiving agents that validate signatures need to be cautious of CPU 
usage when validating signatures larger than those mandated in this 
specification. An attacker can send very large, bogus signatures in 
order to swamp the CPU of the receiving party. Receiving parties that 
verify large signatures are advised to have some sort of resource 
management system to prevent such an attack.

---

From: "Tony Capel" <[email-masked]>
Date: Wed, 6 Aug 2008 15:01:56 -0400

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| Sent: August 6, 2008 11:07 AM
| To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
| Cc: [email-masked]
| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| 
| 
>>cut
| 
| Proposed wording:
| 
| Receiving agents that validate signatures need to be cautious of CPU 
| usage when validating signatures larger than those mandated in this 
| specification. An attacker can send very large, bogus signatures in 
| order to swamp the CPU of the receiving party. Receiving parties that 
| verify large signatures are advised to have some sort of resource 
| management system to prevent such an attack.
|

I agree with the intent here, but this issue applies to both signature and
encryption operations.
So the text needs to address both sections /4.3 Signature Verification/  and
/4.4 Encryption/
(/4.5 Decryption/ should be ok since I presume the agent is using a validated
decryption key)

So maybe the last line of both sections could change to: 

"2048 <  key size         : MAY  (see Security Considerations, and
                                  especially discussion of denial
                                  of service vulnerability when
                                  implementing support for large keys,
                                  e.g. keys larger than 4096.)" 

Similarly maybe it is also appropriate* to add the same text to rfc3850bis-04
section  /4.3 Certificate and CRL Signing Algorithms/

And the security considerations section of rfc3850bis updated similarly to 3851
with regard to cautions about large key sizes.

Tony

*Also a problem for cert validation if the provided intermediate cert has a
large key (which would be used to check the end user certificate signature).
Hopefully implementers will either a) identify the chain of certificates and
begin validation at the trust anchor or b) limit crypto processing in some way.

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 7 Aug 2008 12:29:24 -0400

Tony,

In 3850, I added the (see Security Considerations [SMIME-MSG]) from 4.3 of
3850 to pull in the security consdierations from 3851. We already point to
it normatively so I think this might be better than copying the text in
different places.

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Tony Capel
>Sent: Wednesday, August 06, 2008 3:02 PM
>To: 'Paul Hoffman'; 'Jim Schaad'; 'Sean P. Turner'; 'Blake Ramsdell'
>Cc: [email-masked]
>I agree with the intent here, but this issue applies to both 
>signature and encryption operations.
>(/4.5 Decryption/ should be ok since I presume the agent is 
>using a validated decryption key)
>
>Similarly maybe it is also appropriate* to add the same text 
>to rfc3850bis-04 section  /4.3 Certificate and CRL Signing Algorithms/
>
>And the security considerations section of rfc3850bis updated 
>similarly to 3851 with regard to cautions about large key sizes.
> 
>
>Tony
>
>*Also a problem for cert validation if the provided 
>intermediate cert has a large key (which would be used to 
>check the end user certificate signature).
>Hopefully implementers will either a) identify the chain of 
>certificates and begin validation at the trust anchor or b) 
>limit crypto processing in some way.
>

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 7 Aug 2008 13:42:05 -0400

>Sent: Wednesday, August 06, 2008 11:07 AM
>To: Jim Schaad; 'Sean P. Turner'; 'Blake Ramsdell'
>Cc: [email-masked]
>DSA-with-SHA-256 for both sending and receiving. It's not that 
>big of a change from 3851.
>
>>permitted.  I thought I saw enough consensus from the list that keys 
>>over this size will have either real-estate constraints or 
>performance 
>>considerations discussion to this effect.  I don't want to 
>say or imply 
>>that keys longer than 4096 are not to be handled.
>
>Proposed wording:
>
>Receiving agents that validate signatures need to be cautious 
>of CPU usage when validating signatures larger than those 
>mandated in this specification. An attacker can send very 
>large, bogus signatures in order to swamp the CPU of the 
>receiving party. Receiving parties that verify large 
>signatures are advised to have some sort of resource 

Is this in addition to or to replace the para that starts "Larger keys are
not" in 3851bis Sec 5?

spt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Aug 2008 15:51:02 -0700

>Is this in addition to or to replace the para that starts "Larger keys are

Replace.

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 8 Aug 2008 16:09:28 -0400

>Sent: Thursday, August 07, 2008 6:51 PM
>To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell'
>Cc: [email-masked]
>>Is this in addition to or to replace the para that starts 
>"Larger keys 
>>are not" in 3851bis Sec 5?
>
>Replace.

I'm happy with replace, as long as we move the certificate path validation
stuff to [CERT].  Russ, Steve, and Tony all suggested something about making
sure the keys are validated prior to use.

spt

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 8 Aug 2008 17:51:11 -0400

My problems with the proposed text are:

1) I would prefer the security consideration apply to encryption as well as
signature checking.  Although less likely, it could be a sending agent who uses
an intended receiver's unvalidated encryption certificate to get the "big" key.
I would not want the text to imply that this is ONLY a receiver signature issue.
We should probably not make assumptions about how the certificates are
distributed and we need to address dual keypair use (the signing certificate
could be ok, but the encryption cert could be bad - a "time-bomb"?).  I agree
that implementers have more options to address the encryption case (not
beginning encryption until cert validation is done) but many implementers allow
encryption certificates to be manually marked as "trusted" - and it is not clear
that everyone only starts the encryption operations after successful cert
validation.  So my preference is to be generic: "be careful about using big keys
from unvalidated end user certs to validate signatures or encrypt".

2) The swamping is specifically related to the crypto element not necessarily
the CPU (i.e. it may be the h/w token that is swamped).

As per my post earlier today to the 3850bis list, the CERT security
considerations may be a bit more complex so having a separate discussion there
might be a good idea.

Tony

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: August 8, 2008 4:09 PM
| To: 'Paul Hoffman'; 'Jim Schaad'; 'Blake Ramsdell'
| Cc: [email-masked]
| Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| 
| 
| 
| >-----Original Message-----
| >From: Paul Hoffman [mailto:[email-masked]]
| >Sent: Thursday, August 07, 2008 6:51 PM
| >To: Turner, Sean P.; 'Jim Schaad'; 'Blake Ramsdell'
| >Cc: [email-masked]
| >Subject: RE: I-D ACTION:draft-ietf-smime-3851bis-04.txt
| >
| >At 1:42 PM -0400 8/7/08, Turner, Sean P. wrote:
| >>  >Proposed wording:
| >>>
| >>>Receiving agents that validate signatures need to be 
| cautious of CPU
| >>>usage when validating signatures larger than those 
| mandated in this 
| >>>specification. An attacker can send very large, bogus 
| signatures in 
| >>>order to swamp the CPU of the receiving party. Receiving 
| >parties that
| >>>verify large signatures are advised to have some sort of resource
| >>>management system to prevent such an attack.
| >>
| >>Is this in addition to or to replace the para that starts
| >"Larger keys
| >>are not" in 3851bis Sec 5?
| >
| >Replace.
| 
| I'm happy with replace, as long as we move the certificate 
| path validation stuff to [CERT].  Russ, Steve, and Tony all 
| suggested something about making sure the keys are validated 
| prior to use.
| 
| spt
|

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 9 Aug 2008 07:23:42 -0700

>an intended receiver's unvalidated encryption certificate to get the 

Someone who is encrypting blindly has many problems that just key 
size. We could add a warning about this as well, but it is should be 
a separate warning.

>I would not want the text to imply that this is ONLY a receiver 

It is far easier to get someone to try to validate a signature than 
it is to get them to encrypt a message.

>the CPU (i.e. it may be the h/w token that is swamped).

Good point. I would be happy with "CPU or other resources".

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 9 Aug 2008 18:15:11 -0700

Earlier, I proposed  a replacement for part of the security 
considerations in 3851bis (S/MIME message). The current text reads:

    Larger keys are not necessarily better keys.  Larger keys take more
    computational resources, and this can quickly become impractical.  In
    fact, support for an excessively large key offers a denial of service
    opportunity if the attacker can cause excessive cryptographic
    processing by providing such a public key.  One mitigation approach
    would require that the corresponding public key certificate be
    validated to a trust anchor prior to use, thus ensuring that only
    trusted public keys are used.  However, some implementations may
    choose to perform signature verification (or key establishment for
    encryption) in parallel with certificate validation, even if
    certificate validation fails.  In such cases, measures should be
    included to limit the impact, for example by limiting cryptographic
    processing time or requiring certificate validation prior to the use
    of large keys.

There is no parallel text in 3850bis.

There has been some good discussion, and I now propose different, 
more general wording that should be included in both documents. This 
would replace the above paragraph in 3851bis and be added to 3850bis.

Sending and receiving agents need to be cautious of CPU usage and 
other resources when handling public keys larger than those mandated 
in this specification (that is, larger than 2048 bits). For example, 
an attacker can send very large, bogus signatures in order to swamp 
the CPU of the receiving party. Another example is that an attacker 
can try to cause a sender to try to encrypt with a very large key. 
One mitigation approach would require that the corresponding public 
key certificate be validated to a trust anchor prior to use, thus 
ensuring that only trusted public keys are used.  However, some 
implementations may choose to perform signature verification (or key 
establishment for encryption) in parallel with certificate 
validation, even if certificate validation fails. Sending and 
receiving parties are advised to have some sort of resource 
management system to prevent such attacks.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 20 Aug 2008 06:29:48 -0700

Given what we know about the state of factoring algorithms I think that we could state that if your security needs demand higher security than you get from 2048 bit RSA you should consider a different algorithm and certainly at 4096.

________________________________

From: [email-masked] on behalf of Paul Hoffman
Sent: Sat 8/9/2008 9:15 PM
To: [email-masked]
Subject: Key size security considerations