Subject: RE: S/MIME v3.2 IDs key size text

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 2 May 2008 13:39:03 -0400

Paul has suggest a rewording of his text for 4.1 as follows:

A receiving agent needs to be able to verify signatures whose key length is
chosen by the signer. For interoperability, a receiving agent MUST be able
to verify signatures whose key length is 1024 bits or shorter. Being able to
verify signatures is mandatory because earlier versions of this
specification required the ability to generate signatures with shorter key
lengths. Note that most receiving agents are likely to see signatures whose
key length is longer than 1024 bits during the next decade, and those
receiving agents will want to be able to verify those signatures.

He's also suggested the following security consideration:

Receiving agents are only required to validate signatures that are the same
length as sending agents are required to produce, namely 1024 bits. Many
people feel that signatures of 1024 bits do not meet their security
requirements today, or even if they meet their requirements today, they will
not meet their requirements in the foreseeable future. Therefore, sending
and receiving agents need to decide what strength of signature they want to
produce and validate, respectively. Further, those decisions need to be
reviewed periodically in light of decreasing cryptographic strength over
time of signatures.

spt

>-----Original Message-----
>From: Paul Hoffman [mailto:[email-masked]] 
>Sent: Tuesday, March 25, 2008 2:12 PM
>To: Turner, Sean P.; 'Russ Housley'; [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text
>
>At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote:
>>This sounds reasonable. I replace the following sentence in 3851bis:
>>
>>A receiving agent SHOULD be able to verify signatures with 
>keys of any 
>>size over 512 bits.
>>
>>with
>>
>>A receiving agent SHOULD be able to verify signatures with keys up to 
>>16384 bits.
>
>I disagree with the upper limit. Verifying signatures with 16K 
>bit keys is very difficult for constrained  devices; this 
>"SHOULD" may have the effect of making device makers need to 
>use faster CPUs than they would normally want to have.
>
>It is unclear which part of the SHOULD is not a MUST here. 
>Because we are talking only about interoperability, then the 
>number is 1024, which is what the key creators SHOULD be 
>making. But that is clearly a lower bound of what a typical 
>receiver might expect. Therefore, a short sentence like the 
>one proposed is insufficient. How about:
>
>A receiving agent needs to be able to verify signatures whose 
>key length is chosen by the signer. At a minimum, a receiving 
>agent MUST be able to verify signatures whose key length is 
>1024 bits or shorter. However, most receiving agents are 
>likely to see signatures whose key length is longer than that 
>during the next decade.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 03 May 2008 06:16:23 +1200

"Turner, Sean P." <[email-masked]> writes:

>chosen by the signer. For interoperability, a receiving agent MUST be able to
>verify signatures whose key length is 1024 bits or shorter.

[...]

>length as sending agents are required to produce, namely 1024 bits.

Aren't these mutually exclusive?

(The "or shorter" attached to the "1024" is also going to prove problematic
with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for
those).

Peter.

---

From: "Tony Capel" <[email-masked]>
Date: Fri, 2 May 2008 14:35:55 -0400

Sean:

I think the minimum supported size needs to be 2048 because:

1) Since at least April 2007 (over a year ago) Verisign has been issuing certs
with 2048 keys (I believe this is selectable when enrolling) (although the root
cert is only 1024!).
2) NIST is recommending 2048 by end of 2008 for signatures and key transport for
some apps [SP-800-78-1 Table 3.1].
3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting 1024
and 2048 (only).

As far as going larger than 2048, in my brief survey, while there appears to be
a small level of interest in 3072 (and even 4096), beyond that many appear to be
recommending a switch to ECC because of the exponentially rising power/cpu costs
for larger RSA sizes (e.g. NSA Suite B).

So I would suggest making 2048 and smaller mandatory. And using a sentence like:
" Note that receiving agents may see signatures whose key length is longer than
2048 
 bits in the future, and support for lengths of 3072 and 4078 SHOULD be provided

 to verify those signatures."

Or

 "... for lengths up to and including 4078 SHOULD ..."

to address optional support.

Tony

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: May 2, 2008 1:39 PM
| To: [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
| 
| 
| 
| Paul has suggest a rewording of his text for 4.1 as follows:
| 
| A receiving agent needs to be able to verify signatures whose 
| key length is chosen by the signer. For interoperability, a 
| receiving agent MUST be able to verify signatures whose key 
| length is 1024 bits or shorter. Being able to verify 
| signatures is mandatory because earlier versions of this 
| specification required the ability to generate signatures 
| with shorter key lengths. Note that most receiving agents are 
| likely to see signatures whose key length is longer than 1024 
| bits during the next decade, and those receiving agents will 
| want to be able to verify those signatures.
| 
| He's also suggested the following security consideration:
| 
| Receiving agents are only required to validate signatures 
| that are the same length as sending agents are required to 
| produce, namely 1024 bits. Many people feel that signatures 
| of 1024 bits do not meet their security requirements today, 
| or even if they meet their requirements today, they will not 
| meet their requirements in the foreseeable future. Therefore, 
| sending and receiving agents need to decide what strength of 
| signature they want to produce and validate, respectively. 
| Further, those decisions need to be reviewed periodically in 
| light of decreasing cryptographic strength over time of signatures.
| 
| spt
| 
| >-----Original Message-----
| >From: Paul Hoffman [mailto:[email-masked]]
| >Sent: Tuesday, March 25, 2008 2:12 PM
| >To: Turner, Sean P.; 'Russ Housley'; [email-masked]
| >Subject: RE: S/MIME v3.2 IDs key size text
| >
| >At 10:16 AM -0400 3/25/08, Turner, Sean P. wrote:
| >>This sounds reasonable. I replace the following sentence in 3851bis:
| >>
| >>A receiving agent SHOULD be able to verify signatures with
| >keys of any
| >>size over 512 bits.
| >>
| >>with
| >>
| >>A receiving agent SHOULD be able to verify signatures with 
| keys up to
| >>16384 bits.
| >
| >I disagree with the upper limit. Verifying signatures with 16K
| >bit keys is very difficult for constrained  devices; this 
| >"SHOULD" may have the effect of making device makers need to 
| >use faster CPUs than they would normally want to have.
| >
| >It is unclear which part of the SHOULD is not a MUST here.
| >Because we are talking only about interoperability, then the 
| >number is 1024, which is what the key creators SHOULD be 
| >making. But that is clearly a lower bound of what a typical 
| >receiver might expect. Therefore, a short sentence like the 
| >one proposed is insufficient. How about:
| >
| >A receiving agent needs to be able to verify signatures whose
| >key length is chosen by the signer. At a minimum, a receiving 
| >agent MUST be able to verify signatures whose key length is 
| >1024 bits or shorter. However, most receiving agents are 
| >likely to see signatures whose key length is longer than that 
| >during the next decade.
|

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 May 2008 14:43:30 -0700

>I think the minimum supported size needs to be 2048 because:

Please be more specific. Supported for what? Signing, verifying, or both?

>3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) are supporting 1024

The wording clearly says that you should expect to validate larger 
keys, which are covered by those three data points.

Your last point (hardware tokens signing at 1024) is exactly why I 
think mandating the ability to sign at least 1024 bits is a good idea.

>for larger RSA sizes (e.g. NSA Suite B).

The current text encourages being able to verify at any level, not 
just 1024 or even 2048.

>  to verify those signatures."

I fully disagree. We are talking about interoperability here, not 
best practice. We should not be mandating that receivers be able to 
verify things that beyond what is mandated for signers. If you want 
to change the length of what signers are required to do, that's fine, 
I would want both sides to be accordance. But until then, saying "you 
must be able to verify something larger than what you can sign" 
doesn't make sense from an interoperability standpoint.

Also, we should not mandate SHOULD-level requirements for particular 
size keys. For verification, specific bit-lengths are not important: 
it is the maximum key length.

>to address optional support.

This doesn't seem to be a good reading of RFC 2119.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 May 2008 14:43:47 -0700

>Aren't these mutually exclusive?

Yes; that's why they are in separate sections.

>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits for

That's just plain wrong. Nothing in the FIPS evaluation says that you 
cannot verify signatures shorter than what they require.

---

From: Luther Martin <[email-masked]>
Date: Fri, 2 May 2008 15:17:43 -0700

> cannot verify signatures shorter than what they require.

I'm not sure that's accurate. A FIPS security policy is fairly clear about exactly what keys and key sizes you can use in FIPS mode, and I'm fairly sure that this stops you from using smaller keys in FIPS mode, even to verify a signature.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 May 2008 15:46:21 -0700

At 3:17 PM -0700 5/2/08, Luther Martin wrote:
>I'm not sure that's accurate. A FIPS security policy is fairly clear 
>about exactly what keys and key sizes you can use in FIPS mode, and 
>I'm fairly sure that this stops you from using smaller keys in FIPS 
>mode, even to verify a signature.

That's quite different than what I said. In FIPS mode, you may need 
to only validate FIPS-mandated signatures (there is even some 
disagreement about this). However, a FIPS-evaluated system can also 
validate non-FIPS-mandated signatures, just not in FIPS mode (maybe).

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 03 May 2008 16:56:38 +1200

>Yes; that's why they are in separate sections.

How does this reconcile them?  Do we get to choose which ones we want?

>>with FIPS-evaluated crypto implementations, since you can't do < 1024 bits
>>for those).
>
>That's just plain wrong. Nothing in the FIPS evaluation says that you cannot
>verify signatures shorter than what they require.

I didn't say you couldn't verify sigs, I said you couldn't get the code to do
that evaluated because the minimum they'll accept is 1024 bits.  In other
words you'd be using non-evaluated code (or code run in a non-evaluated mode)
to do the sig. verification.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 3 May 2008 08:49:25 -0700

>How does this reconcile them?  Do we get to choose which ones we want?

You follow the MUST, not the "if you care about doing things 
flexibly, you also do this". This is the same as for almost any IETF 
standard.

>to do the sig. verification.

I admit that I haven't gone through a FIPS evaluation myself, but 
what you say seems wrong. .I assume that verifying code does not have 
different code paths for different sizes of keys being verified, so 
the evaluated code works for the mandated sizes and others. Even if 
you structured your code along key sizes, the "wrong" sizes would be 
non-evaluated, and the "right" sizes would be evaluated.

If someone from NIST or from a test lab wants to chime in here, that 
would be grand.

---

From: "Tony Capel" <[email-masked]>
Date: Sat, 3 May 2008 14:49:57 -0400

Paul:

1A) Both signing and verifying.

Verisign has been issuing both 1k and 2k single keypair certs for some
time, 2k is becoming common in many product specifications and recommended
by many reputable authorities.

I communicate today within a community of 2k and lower certificate holders
not 1K and lower holders.  I have a 2k "off-the-shelf" cert from Verisign,
I cannot generate 1k signatures, so anyone I send to must be able to
verify 2k signatures.  So verify 2k support is required today.  It is true
that users who only intend to use 1k certs could get away with software
which cannot sign using 2k keys; but I think this is a pretty subtle
detail which would be lost in the noise of most specifications.

1B) And encryption and decryption as well.

Furthermore, since those Versign certs are single keypair, I need 2k
encrypt/decrypt since obviously the same keypair is used.  Those using
multiple keypair infrastructures with separate signing and encryption
certs could use differing sizes, but in my experience the infrastructures
themselves tend to have the same specification for both sign and encrypt
(sign/verify and decrypt/encrypt).

For encryption of course the keysize is specified by the destination cert;
so if anyone in my community has 2k keys, I must be able to encrypt with
2k keys.  So encrypt support for 2k keys is required today.  Again, 1k
only support for decryption would be lost in the noise.

So if we wish to guarantee a minimum level of "out-of-the-box"
interoperability from a box which has a simplistic specification
"compliant to smime v3.2"; then we should include a mandate for 2k and
lower support for all operations to meet today's requirement.

2) Support beyond the mandatory.

I agree that support beyond 2k should be optional.  I am sorry I misused
the word "SHOULD", I operate in several standardization arenas and rfc2119
is not a universal standard!!  I meant OPTIONAL or MAY for the larger
sizes.

The reason for my identifying the specific 3k and 4k values was an attempt
to address an earlier thread where 4k and larger keysizes were proposed -
which led to a discussion of denial of service attacks by senders
specifying large keysizes - and then this led to comments about improper
modulus selection, etc. etc....

The origin of the earlier thread was concern about leaving larger keysizes
completely open (even as OPTIONAL). I prefer to leave this issue, if it
remains an issue, to Peter and the others who contributed to that thread.
(I would just note that in my reading 3k and 4k certs are mentioned, but
it is not clear to me that there is a future beyond 4k RSA with
competition from other algorithms.)

Tony

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| Sent: May 2, 2008 5:44 PM
| To: [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
| 
| 
| 
| At 2:35 PM -0400 5/2/08, Tony Capel wrote:
| >I think the minimum supported size needs to be 2048 because:
| 
| Please be more specific. Supported for what? Signing, 
| verifying, or both?
| 
| >1) Since at least April 2007 (over a year ago) Verisign has been 
| >issuing certs with 2048 keys (I believe this is selectable when 
| >enrolling) (although the root cert is only 1024!).
| >2) NIST is recommending 2048 by end of 2008 for signatures and key 
| >transport for
| >some apps [SP-800-78-1 Table 3.1].
| >3) Many/most hardware tokens (e.g. Safenet, Gem, Aladdin) 
| are supporting 1024
| >and 2048 (only).
| 
| The wording clearly says that you should expect to validate larger 
| keys, which are covered by those three data points.
| 
| Your last point (hardware tokens signing at 1024) is exactly why I 
| think mandating the ability to sign at least 1024 bits is a good idea.
| 
| >As far as going larger than 2048, in my brief survey, while there
| >appears to be
| >a small level of interest in 3072 (and even 4096), beyond that many 
| >appear to be
| >recommending a switch to ECC because of the exponentially rising 
| >power/cpu costs
| >for larger RSA sizes (e.g. NSA Suite B).
| 
| The current text encourages being able to verify at any level, not 
| just 1024 or even 2048.
| 
| >So I would suggest making 2048 and smaller mandatory. And using a
| >sentence like:
| >" Note that receiving agents may see signatures whose key length is 
| >longer than
| >2048
| >  bits in the future, and support for lengths of 3072 and 
| 4078 SHOULD 
| >be provided
| >
| >  to verify those signatures."
| 
| I fully disagree. We are talking about interoperability here, not 
| best practice. We should not be mandating that receivers be able to 
| verify things that beyond what is mandated for signers. If you want 
| to change the length of what signers are required to do, that's fine, 
| I would want both sides to be accordance. But until then, saying "you 
| must be able to verify something larger than what you can sign" 
| doesn't make sense from an interoperability standpoint.
| 
| Also, we should not mandate SHOULD-level requirements for particular 
| size keys. For verification, specific bit-lengths are not important: 
| it is the maximum key length.
| 
| >Or
| >
| >  "... for lengths up to and including 4078 SHOULD ..."
| >
| >to address optional support.
| 
| This doesn't seem to be a good reading of RFC 2119.
|

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 3 May 2008 12:11:20 -0700

>by many reputable authorities.

How is this relevant to the discussion thread? There are lots of 
communities that use (and even require) higher security than what is 
in the current spec. For example, the US Department of Defense is now 
mandating the use of elliptic curve cryptography for digital 
signatures. Using them as the base, instead of VeriSign, we would 
have a mandatory-to-implement requirement for ECC. I do not imagine 
you would support that, so I don't see why picking one product (the 
2K certs) from one vendor should affect our decision for the 
mandatory-to-implement requirements as long as we make it clear that 
it is likely that any application will probably want to do more than 
that.

>lower support for all operations to meet today's requirement.

This completely confuses mandatory-to-implement and optional. 
VeriSign uses one of the options available to them, namely longer key 
sizes. They also use the mandatory-to-implement size, and they still 
distribute their own certificates using much-lower-than-mandatory 
sizes. None of that is relevant to anyone other than VeriSign and 
their customers.

Our task is to create a standard that is usable by as many people as 
possible while at the same time as setting some minimum operational 
security expectations. For interoperability, we need to say "you can 
verify signatures created following this spec". For minimum 
operational security, we have to pick a size that is reasonable for 
the vast majority of users while encouraging software developers to 
support all reasonable sizes.

Please read RFC 3766. If you believe that the numbers in there are 
wrong, by all means let the IETF community know. If you believe that 
the numbers there are right but you still think that a typical user 
needs more than 75 bits of symmetric strength for their signatures, 
even though no one has ever done that much effort for even a single 
attack in public, please say why.

---

From: "Turner, Sean P." <[email-masked]>
Date: Sat, 3 May 2008 20:51:28 -0400

I think if we struck ", namely 1024 bits" from the text in the security
considerations that it's still a true statement and we won't have to change
it every time we update the spec.

spt 

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Friday, May 02, 2008 5:44 PM
>To: [email-masked]
>>>A receiving agent needs to be able to verify signatures whose key 
>>>length is chosen by the signer. For interoperability, a receiving 
>1024 bits or shorter.
>>>Receiving agents are only required to validate signatures 
>that are the 
>>>same length as sending agents are required to produce, 
>namely 1024 bits.
>>
>>(The "or shorter" attached to the "1024" is also going to prove 
>>problematic with FIPS-evaluated crypto implementations, since 
>you can't 
>>do < 1024 bits for those).
>
>That's just plain wrong. Nothing in the FIPS evaluation says 
>that you cannot verify signatures shorter than what they require.
>

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 3 May 2008 19:08:13 -0700

>it every time we update the spec.

I'm OK with that, but I also feel that if we're updating the minimum 
mandatory signing length, it is trivial to update the Security 
Considerations as well.

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 04 May 2008 19:57:46 +1200

Paul Hoffman <[email-masked]> writes:
>I admit that I haven't gone through a FIPS evaluation myself, but what you
>say seems wrong.

I've gone through several, and talked to numerous others who have as well.
It's the usual crapshoot, some labs will allow < 1024-bit keys and some won't.
For my own code I've had one lab pass 512-bit keys OK and another one say that
any ability to use keys of less than 1024 bits would mean it couldn't be
evaluated.  In another, more amusing case reported to me by someone else, they
got one lab to OK it at 512 bits, then a second lab required them to submit
paperwork showing that they blocked all keys of less than 1024 bits, and after
they did that the first lab complained that they were failing their tests on
512-bit keys.  In the end they just declared that their product didn't support
any keys less than 1024 bits and everything was OK.

>If someone from NIST or from a test lab wants to chime in here, that would be
>grand.

What really matters is what the labs in sum total enforce, not what NIST
thinks or what one individual lab does.  As the above examples show, you can
jury-shop your lab to get 512-bit keys passed if you like, but it only works
in some cases and to be safe you need to use a minimum key size of 1024 bits.

Peter.

---

From: Luther Martin <[email-masked]>
Date: Sun, 4 May 2008 11:49:29 -0700

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Paul Hoffman
> Sent: Saturday, May 03, 2008 12:11 PM
> To: [email-masked]
> Subject: RE: S/MIME v3.2 IDs key size text (resend, this time not opaque
> signed with 2k key)

> attack in public, please say why.

These are interesting points.

I believe that the vast majority of users are actually either at government agencies or financial institutions. The government guys need FIPS 140-2, which is fairly clear about requiring bigger keys (actually the SP that the IG refers to is), and the FI people need to follow the ANSI X9 recommendations. Both of these require the use of 2K keys Really Soon. Because of this, I believe that making things reasonable for the vast majority of users means requiring the support for 2K keys ASAP.

I'd also say that what RFC 3766 says is totally irrelevant. The people who rely on cryptography are the ones that say what an acceptable level of risk is. In the case of FIs who rely on X9 standards, this means using keys that are fairly big, and may be bigger that RFC 3766 describes. In the case of government users, this is defined by NIST in SP 800-57.

From the point of view of a cryptographer, the key sizes that they require may seem a bit big, but then the cryptographers aren't the ones dealing with trillions of dollars of risk, either.

---

From: "Tony Capel" <[email-masked]>
Date: Mon, 5 May 2008 16:08:35 -0400

All:

I agree that deleting " namely 1024 bits" from the first sentence of the
proposed security considerations section paragraph is good.  The second "1024"
in the proposed paragraph is not a problem for me since it is not "normative".

With respect to section 4.1 (Key Pair Generation).  Is it intended to change the
title of this section?  The second paragraph of the current text in
3851bis-01.txt begins "If an S/MIME agent needs to generate ...".  So if the
S/MIME agent does NOT need to generate keys (and this is typically the case,
most enrollment & key generation are done externally to messaging clients) the
balance of this paragraph (which mentions the key sizes) is not normative (as
currently drafted - its quite possible that the last sentence of this paragraph
should have been in a separate paragraph).  Key generation requirements are
normally (hopefully!) cited in the corresponding CP, where things such as
required key sizes, where they are generated (locally or at the CA), FIPS-140
Level, etc. should be (!!) explicitly identified.  Maybe the second paragraph of
4.1 could be replaced with a simple statement:

"If an S/MIME agent needs to generate one or more key pairs, each SHOULD be
generated according to the corresponding certificate policy, refer for example
to [RFC3647]."

The proposed text, and the discussion so far, is really speaking about "what
range of RSA key sizes" needs to be supported.  We are NOT providing security
advice, we are just trying to ensure that most smime v3.2 implementations will
interwork in the typical environments expected "in the wild" (and special
environments will be understood by purchasers anyway, so we likely need not
worry about high security applications - only the general "public"
environments). 

A similar issue is already addressed in CERT v3.2 (
draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate  validation.
We might consider copying the last sentence of CERT v3.2 Sec 4.3 to the end of
sections 2.2 and 2.3 (just before the Notes):

   "Key sizes from 1024 bits to 2048 bits MUST be supported." 

This would also have the advantage of aligning CERT and MSG.

Tony

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| Sent: May 3, 2008 10:08 PM
| To: Turner, Sean P.; [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
| 
| 
| 
| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
| >I think if we struck ", namely 1024 bits" from the text in 
| the security 
| >considerations that it's still a true statement and we won't have to 
| >change it every time we update the spec.
| 
| I'm OK with that, but I also feel that if we're updating the minimum 
| mandatory signing length, it is trivial to update the Security 
| Considerations as well.
|

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 5 May 2008 16:57:48 -0400

Tony,

There was a comment from Paul against the text you cite from 3850bis. He
objected to moving the lower bounds from 512 to 1024. I figured I'd post
both -02 drafts once we knocked this issue out.

spt

>From: Tony Capel [mailto:[email-masked]] 
>Sent: Monday, May 05, 2008 4:09 PM
>To: 'Paul Hoffman'; 'Turner, Sean P.'; [email-masked]
>I agree that deleting " namely 1024 bits" from the first 
>sentence of the proposed security considerations section 
>paragraph is good.  The second "1024"
>With respect to section 4.1 (Key Pair Generation).  Is it 
>intended to change the title of this section?  The second 
>paragraph of the current text in 3851bis-01.txt begins "If an 
>S/MIME agent needs to generate ...".  So if the S/MIME agent 
>does NOT need to generate keys (and this is typically the 
>case, most enrollment & key generation are done externally to 
>messaging clients) the balance of this paragraph (which 
>mentions the key sizes) is not normative (as currently drafted 
>- its quite possible that the last sentence of this paragraph 
>should have been in a separate paragraph).  Key generation 
>requirements are normally (hopefully!) cited in the 
>corresponding CP, where things such as required key sizes, 
>where they are generated (locally or at the CA), FIPS-140 
>"If an S/MIME agent needs to generate one or more key pairs, 
>each SHOULD be generated according to the corresponding 
>certificate policy, refer for example to [RFC3647]."
>
>The proposed text, and the discussion so far, is really 
>speaking about "what range of RSA key sizes" needs to be 
>supported.  We are NOT providing security advice, we are just 
>trying to ensure that most smime v3.2 implementations will 
>interwork in the typical environments expected "in the wild" 
>(and special environments will be understood by purchasers 
>anyway, so we likely need not worry about high security 
>applications - only the general "public"
>environments). 
>
>We might consider copying the last sentence of CERT v3.2 Sec 
>4.3 to the end of sections 2.2 and 2.3 (just before the Notes):
>

---

From: "Tony Capel" <[email-masked]>
Date: Mon, 5 May 2008 17:34:02 -0400

Sean:

Agreed, the text in 3850bis and 3851bis needs to align.  I have no problems with
support for smaller key sizes.

I expect constraints on key size to be implemented by the certificate issuer
anyway.  If you get a 512 key in a cert you trust you must be able to use it,
no?  

Tony

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Turner, Sean P.
| Sent: May 5, 2008 4:58 PM
| To: 'Tony Capel'; 'Paul Hoffman'; [email-masked]
| Subject: RE: S/MIME v3.2 IDs key size text
| 
| 
| 
| Tony,
| 
| There was a comment from Paul against the text you cite from 
| 3850bis. He objected to moving the lower bounds from 512 to 
| 1024. I figured I'd post both -02 drafts once we knocked this 
| issue out.
| 
| spt
| 
| >-----Original Message-----
| >From: Tony Capel [mailto:[email-masked]]
| >Sent: Monday, May 05, 2008 4:09 PM
| >To: 'Paul Hoffman'; 'Turner, Sean P.'; [email-masked]
| >Subject: RE: S/MIME v3.2 IDs key size text
| >
| >All:
| >
| >I agree that deleting " namely 1024 bits" from the first
| >sentence of the proposed security considerations section 
| >paragraph is good.  The second "1024"
| >in the proposed paragraph is not a problem for me since it is 
| >not "normative".
| >
| >With respect to section 4.1 (Key Pair Generation).  Is it
| >intended to change the title of this section?  The second 
| >paragraph of the current text in 3851bis-01.txt begins "If an 
| >S/MIME agent needs to generate ...".  So if the S/MIME agent 
| >does NOT need to generate keys (and this is typically the 
| >case, most enrollment & key generation are done externally to 
| >messaging clients) the balance of this paragraph (which 
| >mentions the key sizes) is not normative (as currently drafted 
| >- its quite possible that the last sentence of this paragraph 
| >should have been in a separate paragraph).  Key generation 
| >requirements are normally (hopefully!) cited in the 
| >corresponding CP, where things such as required key sizes, 
| >where they are generated (locally or at the CA), FIPS-140 
| >Level, etc. should be (!!) explicitly identified.  Maybe the 
| >second paragraph of
| >4.1 could be replaced with a simple statement:
| >
| >"If an S/MIME agent needs to generate one or more key pairs,
| >each SHOULD be generated according to the corresponding 
| >certificate policy, refer for example to [RFC3647]."
| >
| >The proposed text, and the discussion so far, is really
| >speaking about "what range of RSA key sizes" needs to be 
| >supported.  We are NOT providing security advice, we are just 
| >trying to ensure that most smime v3.2 implementations will 
| >interwork in the typical environments expected "in the wild" 
| >(and special environments will be understood by purchasers 
| >anyway, so we likely need not worry about high security 
| >applications - only the general "public"
| >environments). 
| >
| >A similar issue is already addressed in CERT v3.2 (
| >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for 
| >certificate  validation.
| >We might consider copying the last sentence of CERT v3.2 Sec 
| >4.3 to the end of sections 2.2 and 2.3 (just before the Notes):
| >
| >   "Key sizes from 1024 bits to 2048 bits MUST be supported."
| >
| >This would also have the advantage of aligning CERT and MSG.
| >
| >Tony
| >
| >
| >| -----Original Message-----
| >| From: [email-masked] 
| >| [mailto:[email-masked]] On Behalf Of Paul Hoffman
| >| Sent: May 3, 2008 10:08 PM
| >| To: Turner, Sean P.; [email-masked]
| >| Subject: RE: S/MIME v3.2 IDs key size text
| >| 
| >| 
| >| 
| >| At 8:51 PM -0400 5/3/08, Turner, Sean P. wrote:
| >| >I think if we struck ", namely 1024 bits" from the text in
| >| the security
| >| >considerations that it's still a true statement and we
| >won't have to
| >| >change it every time we update the spec.
| >| 
| >| I'm OK with that, but I also feel that if we're updating 
| the minimum
| >| mandatory signing length, it is trivial to update the Security 
| >| Considerations as well.
| >| 
| >
|

---

From: "Turner, Sean P." <[email-masked]>
Date: Tue, 6 May 2008 12:37:19 -0400

Tony,

Inline...

spt

>[mailto:[email-masked]] On Behalf Of Tony Capel
>Sent: Monday, May 05, 2008 5:34 PM
>To: 'Turner, Sean P.'; 'Paul Hoffman'; [email-masked]
>Agreed, the text in 3850bis and 3851bis needs to align.  I 
>have no problems with support for smaller key sizes.

You got it.  I was just trying to say we need to keep the two algined.

>I expect constraints on key size to be implemented by the 
>certificate issuer anyway.  If you get a 512 key in a cert you 
>trust you must be able to use it, no?  

Originally, I thought the answer really was no, but I think for interop with
v3 and v3.1 we need to say yes. If you get a 512 key in a cert from a source
you trust, then you can decide to not use it but it's not because you don't
trust the source it's because of some other reason. I can see where maybe
short lived certs are used because the info gets stale quickly, they need to
sign/verify really quickly, etc. I am a little concerned about the FIP-140
issue though.

Just a thought ... since we've now got a way to indicate + and - with
requirements should we apply it the key sizes in 3850bis?  That way people
will have a hint that in the next update the shorter keys will likely become
not so welcome and large keys more so? 

   0 < key size < 511  : MUST NOT
 512 < key size < 1023 : SHOULD-
1024 < key size < 2048 : MUST
2049 < key size < 4096 : MAY

>3850bis. 
>| He objected to moving the lower bounds from 512 to 1024. I 
>figured I'd 
>| post both -02 drafts once we knocked this issue out.
>| 
>| spt
>| 
>sentence of 
>| >the proposed security considerations section paragraph is 
>good.  The 
>| >second "1024"
>| >in the proposed paragraph is not a problem for me since it is not 
>| >"normative".
>| >
>intended to 
>| >change the title of this section?  The second paragraph of the 
>| >current text in 3851bis-01.txt begins "If an S/MIME agent needs to 
>| >generate ...".  So if the S/MIME agent does NOT need to 
>generate keys 
>| >(and this is typically the case, most enrollment & key 
>generation are 
>| >done externally to messaging clients) the balance of this paragraph 
>| >(which mentions the key sizes) is not normative (as 
>currently drafted
>| >- its quite possible that the last sentence of this 
>paragraph should 
>| >have been in a separate paragraph).  Key generation 
>requirements are 
>| >normally (hopefully!) cited in the corresponding CP, where things 
>| >such as required key sizes, where they are generated (locally or at 
>| >the CA), FIPS-140 Level, etc. should be (!!) explicitly 
>identified.  
>| >Maybe the second paragraph of
>| >"If an S/MIME agent needs to generate one or more key pairs, each 
>| >SHOULD be generated according to the corresponding certificate 
>| >policy, refer for example to [RFC3647]."
>| >
>| >The proposed text, and the discussion so far, is really speaking 
>| >about "what range of RSA key sizes" needs to be supported.  We are 
>| >NOT providing security advice, we are just trying to ensure 
>that most 
>| >smime v3.2 implementations will interwork in the typical 
>environments 
>| >expected "in the wild"
>anyway, so 
>| >we likely need not worry about high security applications - 
>only the 
>| >general "public"
>| >environments). 
>| >
>| >draft-ietf-smime-3850bis-01.txt ) in Section 4.3 for certificate  
>| >validation.

---

From: Russ Housley <[email-masked]>
Date: Fri, 09 May 2008 14:11:21 -0400

Are you saying that I MAY NOT support keys bigger than 4096?

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 May 2008 14:40:17 -0700

>2049 < key size < 4096 : MAY

Beyond what Russ just pointed out, I find the first line to be in bad 
taste. Any IETF spec that says "you must not be able to verify a 
signature even though it is valid" is pretty offensive.

Can we return to talking about interoperability?

---

From: Blake Ramsdell <[email-masked]>
Date: Fri, 9 May 2008 17:12:39 -0700

On Fri, May 09, 2008 at 02:40:17PM -0700, Paul Hoffman wrote:
> taste. Any IETF spec that says "you must not be able to verify a signature 
> even though it is valid" is pretty offensive.
>

I think you and I are on the same page, and there's two things:

1. Interoperability. The key sizes to guarantee two implementations will talk
   to each other.

2. Security considerations. The key sizes that are a no-no due to insufficient
   or overly-sufficient size.

Have we given up on the separation of these?

Blake

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 May 2008 18:14:10 -0700

>Have we given up on the separation of these?

For interoperability, the receiver MUST be able to verify all sizes 
that the signer MUST be able to sign. For security, the signer MUST 
be able to sign using keys of at least a certain size.

A receiver should expect that some of the signatures it wants to 
verify will be bigger than the one size in the spec because a 
receiver cannot accurately predict the security decisions of all the 
senders with which it interacts.

I propose that that size is 1024 bits: that's plenty of strength for 
most typical non-paranoid applications for at least five years. If it 
turns out to be too short due to an unexpected large reduction in 
strength of RSA, we can revise then. Quite frankly, in that case, we 
might be recommending ECDSA anyhow.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 10 May 2008 19:45:00 +1200

Paul Hoffman <[email-masked]> writes:
>Beyond what Russ just pointed out, I find the first line to be in bad taste.
>Any IETF spec that says "you must not be able to verify a signature even
>though it is valid" is pretty offensive.

So an implementation is supposed to do what, tell the user that they can be
absolutely totally assured that the signature is valid, all 12 bits of it?  I
guess it'll save implementation time because you can just report "signature
might be valid" without even having to verify it.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 10 May 2008 15:23:07 -0700

At 7:45 PM +1200 5/10/08, Peter Gutmann wrote:
>absolutely totally assured that the signature is valid, all 12 bits of it?

Yes. Why not? If you don't want to fully comply with the standard for 
any of a variety of reasons, by all means don't.

---

From: Timothy J Miller <[email-masked]>
Date: Mon, 12 May 2008 08:31:18 -0500

> Beyond what Russ just pointed out, I find the first line to be in  
> bad taste. Any IETF spec that says "you must not be able to verify a  

How about adding a "MUST warn the user that key is too damn short to  
be considered safe, even though the signature is valid" clause instead?

-- Tim

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 12 May 2008 10:03:10 -0400

> How about adding a "MUST warn the user that key is too damn short to
be considered safe, even though the 
> signature is valid" clause instead?
> 
> -- Tim

This isn't sufficient for verification of archived email.  A weak
signature may be covered by a timestamp that enables its verification.
This problem should be addressed using something like DSSC.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 May 2008 08:10:10 -0700

At 8:31 AM -0500 5/12/08, Timothy J Miller wrote:
>>bad taste. Any IETF spec that says "you must not be able to verify 
>>a signature even though it is valid" is pretty offensive.
>

I seriously doubt we could get consensus on the number of bits for 
that to kick in. Also, this would prevent an automated signature 
validation system with no UI from being able to be conformant.

We are not the security nannies of the Internet. As long as we give a 
reasonable number of bits that all implementations should be able to 
sign and verify in order to make reasonably-strong signatures, we 
should step back and let organizations make their own rules.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 May 2008 03:32:46 +1200

Paul Hoffman <[email-masked]> writes:

>reasonable number of bits that all implementations should be able to sign and
>verify in order to make reasonably-strong signatures, we should step back and
>let organizations make their own rules.

No, that's exactly what we shouldn't do, because then organisations will use
the fact that the standard doesn't set a sane limit on the key size to justify
using completely stupid key sizes (or as a generalisation completely insecure
"security" practices) [0].  I realise that it's not possible to explicitly
outlaw every kind of stupid behaviour that users will engage in, but since
there's a list of key sizes in the doc anyway it's a pretty trivial change to
add a sensible lower bound to it.

Peter.

[0] The best one I've ever heard in this area was a government department that
    said that while a NIST standard required the use of security technology
    X, it didn't say it had to be *effectively* applied, merely applied
    (imagine the computer equivalent of "doors must be fitted with Medeco
    locks", but since the standard never said you have to actually lock the
    doors, merely that they had to be there, it was fine to leave all the
    doors unlocked).  That's an extreme case, but it's merely the tip of the
    iceberg of lesser stupidity that organisations will engage in because a
    standard doesn't say they can't.

---

From: "Tony Capel" <[email-masked]>
Date: Mon, 12 May 2008 12:14:03 -0400

Sean et al:

How about:

   0 <  key size < 512     : MAY     but refer to security considerations
section
 512 <= key size < 1024    : SHOULD- but refer to security considerations
section
1024 <= key size <= 2048   : MUST
2048 <  key size           : MAY     but refer to security considerations
section

For larger keys, some text for the security considerations section might
be added, e.g. something like:

"A denial of service opportunity may exploitable by attackers who provide
an excessively large key, or a key selected to require excessive
cryptographic processing.  One mitigation approach would require that the
corresponding public key certificate be validated to a trusted root [trust
anchor] prior to use, thus ensuring that only trusted public keys are
used.  However, some implementations may choose to perform signature
verification (or data encryption) in parallel with certificate validation,
or 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."

For smaller keys, this is already addressed to some extent for encryption
in the security considerations section, maybe this needs updating based on
our experience with smime:

Current text:

   40-bit encryption is considered weak by most cryptographers. Using
   weak cryptography in S/MIME offers little actual security over
   sending plaintext.  However, other features of S/MIME, such as the
   specification of tripleDES 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.

Proposed Draft text:

"Using weak cryptography in S/MIME offers little actual security over
sending plaintext.
Some cryptographers consider public keys of less than 1024* bits to be
weak, along with symmetric encryption algorithms of less than 64 bits and
certain older hash algorithms used for signing.
In any given application, an appropriate analysis of the threats and risks
SHOULD lead to the selection of appropriate algorithms and key sizes.
For public keys, algorithms and key sizes are normally defined by the
public key issuer in the corresponding certificate, and thus not under the
control of the end user.
For symmetric encryption and hash algorithms, S/MIME supports the ability
of parties to communicate their capabilities to each other, allowing the
use of appropriately strong measures.
When feasible, sending and receiving agents SHOULD inform senders (prior
to transmission) and recipients of the relative cryptographic strength of
messages and SHOULD provide a warning if weak algorithms or key sizes are
used.
Such warnings are especially important if the symmetric encryption or hash
algorithm are significantly weaker than the corresponding public key,
since this will result in a message with weaker security than that implied
by the public key certificate. "

Tony

* of course this could be a smaller value.

PS: sorry about earlier e-mail with opaque signing, I did a "Reply to"
which copied the security properties from Timothy's e-mail (but not
cleartext option!) - defaulting to signing which I did not intend!!!

| -----Original Message-----
| From: [email-masked]
| [mailto:[email-masked]] On Behalf Of Timothy J Miller
| Sent: May 12, 2008 9:31 AM
| To: Paul Hoffman
| Cc: Turner, Sean P.; [email-masked]
| Subject: Re: S/MIME v3.2 IDs key size text
|
|
|
| On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
| >
| > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
| >>
| >>   0 < key size < 511  : MUST NOT
| >> 512 < key size < 1023 : SHOULD-
|
| > Beyond what Russ just pointed out, I find the first line to be in
| > bad taste. Any IETF spec that says "you must not be able to
| verify a
| > signature even though it is valid" is pretty offensive.
|
| How about adding a "MUST warn the user that key is too damn short to
| be considered safe, even though the signature is valid"
| clause instead?
|
| -- Tim
|
|

| -----Original Message-----
| From: [email-masked] 
| [mailto:[email-masked]] On Behalf Of Timothy J Miller
| Sent: May 12, 2008 9:31 AM
| To: Paul Hoffman
| Cc: Turner, Sean P.; [email-masked]
| Subject: Re: S/MIME v3.2 IDs key size text
| 
| 
| 
| On May 9, 2008, at 4:40 PM, Paul Hoffman wrote:
| >
| > At 12:37 PM -0400 5/6/08, Turner, Sean P. wrote:
| >>
| >>   0 < key size < 511  : MUST NOT
| >> 512 < key size < 1023 : SHOULD-
| 
| > Beyond what Russ just pointed out, I find the first line to be in
| > bad taste. Any IETF spec that says "you must not be able to 
| verify a  
| > signature even though it is valid" is pretty offensive.
| 
| How about adding a "MUST warn the user that key is too damn short to  
| be considered safe, even though the signature is valid" 
| clause instead?
| 
| -- Tim
| 
|

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 May 2008 09:36:30 -0700

At 3:32 AM +1200 5/13/08, Peter Gutmann wrote:
>"security" practices) [0].

You'll need to justify this one, Peter. Show me some examples where 
any previous version of S/MIME, none of which have "sane" lower 
limits, was used by any organization to justify a stupid key size.

>I realise that it's not possible to explicitly

It is a list of two elements: there is already a sensible lower 
bound. Please suggest specific text that would meet your criteria.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 May 2008 09:49:00 -0700

>2048 <  key size           : MAY     but refer to security considerations

Could you add verbs to your table? MAY what? SHOULD- what?

>processing time or requiring certificate validation prior to the use of

Regardless of small key size issue, I think text like this would be a 
good addition to the Security Considerations section of many 
documents.

>certain older hash algorithms used for signing.

And some don't consider 1024 bits weak. For example, there are lots 
of 1024-bit certificates in the trust anchor pile in your browser. To 
date, no one is known to have compromised even one of them, even 
though doing so would have higher value than compromising almost any 
individual's signing key. Cryptographers who look at the real world 
of costs and benefits have noticed this.

>SHOULD lead to the selection of appropriate algorithms and key sizes.

That SHOULD is misplaced. Please re-read RFC 2119. Further, we all 
know that this sentence is more often false than true in the real 
world. What is the advantage of reproducing this fairy tale in the 
S/MIME spec?

>messages and SHOULD provide a warning if weak algorithms or key sizes are

I'm lost here. Using the protocol described in the document, how 
would I send such information? How would I send such a warning?

---

From: Timothy J Miller <[email-masked]>
Date: Mon, 12 May 2008 13:43:37 -0500

> would I send such information? How would I send such a warning?

Yet similar advice exists elsewhere in the cert handling spec:

"""
A receiving agent SHOULD provide some explicit alternate processing of  
the message if this comparison     fails, which may be to display a  
message that shows the recipient the addresses in the certificate or  
other certificate details.
"""  (ref: sec 3)

Are you saying that this should come out as well, since your objection  
to the RFC advising implementors to warn users re: key strength  
clearly also applies to the RFC advising implementors re: an email  
mismatch?

-- Tim

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 May 2008 13:19:10 -0700

At 1:43 PM -0500 5/12/08, Timothy J Miller wrote:
>A receiving agent SHOULD provide some explicit alternate processing 
>of the message if this comparison     fails, which may be to display 
>a message that shows the recipient the addresses in the certificate 
>or other certificate details.
>"""  (ref: sec 3)

Only somewhat similar. Tony's proposed changes has a "SHOULD inform" 
and a "SHOULD provide a warning". The quoted test is "SHOULD provide 
alternate processing" which may be displaying a message. That's a big 
difference.

>Are you saying that this should come out as well, since your 
>objection to the RFC advising implementors to warn users re: key 
>strength clearly also applies to the RFC advising implementors re: 
>an email mismatch?

Nope. I have nothing against advising implementers. Heck, I've 
written a lot of the text that does that. What I object to is a 
SHOULD-level "inform" or "provide a warning" when we have no 
protocol-standard way of doing so.

---

From: Timothy J Miller <[email-masked]>
Date: Mon, 12 May 2008 15:51:22 -0500

On May 12, 2008, at 3:19 PM, Paul Hoffman wrote:

> alternate processing" which may be displaying a message. That's a  
> big difference.

Yet the very next paragraph says:

"""
A receiving agent SHOULD display a subject name or other certificate  
details when displaying an indication of successful or unsuccessful  
signature verification.
"""

Sounds the same to me.

Here's the thing:  You're advocating interpreting the spec as purely a  
protocol spec.  If that's what you're after, then that's a bigger  
issue than trading barbs over key length recommendations.  There are a  
number of clauses that require UI implementation that need to be  
struck out (or at least moved to the security considerations section).

But here's my problem with that thinking:  S/MIME isn't just a  
protocol, it's a ceremony.  There's an fundamental UI aspect to  
ceremonies.  This needs to be dealt with properly and *prominently* or  
we'll end up with implementations that don't just *allow* bad things  
to be done, but that *mislead users* into thinking things are true  
about messages that just aren't.

Moving all UI-related issues or security related recommendations to a  
separate section lowers their visibility, and that's not a good thing  
IMHO.

-- Tim

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 May 2008 14:25:34 -0700

At 3:51 PM -0500 5/12/08, Timothy J Miller wrote:
>>Only somewhat similar. Tony's proposed changes has a "SHOULD 
>>inform" and a "SHOULD provide a warning". The quoted test is 
>>"SHOULD provide alternate processing" which may be displaying a 
>>message. That's a big difference.
>

Reading that quoted sentence, can you see that the "SHOULD" does not 
apply when not "displaying an indication..."? That sentence does not 
mandate showing anything. If there is something in an S/MIME document 
that mandates "showing" or "warning", it is an error. We spent years 
(well, now a decade) working on this so that a conformant 
implementation does not need to have a UI.

>Here's the thing:  You're advocating interpreting the spec as purely 
>a protocol spec.  If that's what you're after, then that's a bigger 
>issue than trading barbs over key length recommendations.  There are 
>a number of clauses that require UI implementation that need to be 

Struck out, definitely. By all means point them out. I've read this 
too many times to find them, I guess.

>ceremonies.

I disagree strongly with the former while agreeing strongly with the latter.

>This needs to be dealt with properly and *prominently* or we'll end 
>up with implementations that don't just *allow* bad things to be 
>done, but that *mislead users* into thinking things are true about 
>messages that just aren't.

That "misleading" will happen regardless of what the spec says. It 
already happens now, and it happened before the IETF took over 
S/MIME. And it's not just S/MIME: nearly every security protocol the 
IETF has developed has the same problem. It's in the nature of 
security and users and vendors.

If you want to write a BCP for implementers, that's great. This 
mailing list would be a great place for it to be discussed. This spec 
is not a BCP: it is a standard that needs to be consistent on both 
interoperability and security.

>Moving all UI-related issues or security related recommendations to 
>a separate section lowers their visibility, and that's not a good 
>thing IMHO.

It definitely lowers their visibility, and it's also the way we 
usually do things in the IETF. We've done it for over a decade for 
much higher-profile security protocols such as TLS and IPsec as well.

---

From: "Turner, Sean P." <[email-masked]>
Date: Mon, 12 May 2008 17:57:54 -0400

>Sent: Monday, May 12, 2008 12:49 PM
>To: Tony Capel
>Cc: [email-masked]
>Subject: RE: S/MIME v3.2 IDs key size text (resend, no signature)
>
>

Not sure what Tony was thinking but I suggested that this go in 3850bis so
it would have been for receiving agents.

>>"A denial of service opportunity may exploitable by attackers who 
>>provide an excessively large key, or a key selected to require 
>>excessive cryptographic processing.  One mitigation approach would 
>>require that the corresponding public key certificate be 
>validated to a 
>>trusted root [trust anchor] prior to use, thus ensuring that only 
>>trusted public keys are used.  However, some implementations 
>may choose 
>>to perform signature verification (or data encryption) in 
>parallel with 
>>certificate validation, or 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."
>
>Regardless of small key size issue, I think text like this 
>would be a good addition to the Security Considerations 
>section of many documents.

I had something similar in the -02 version, but I'll swap out that text for
this text.

spt

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 12 May 2008 15:20:31 -0700

>it would have been for receiving agents.

In your mind, what verb goes with "SHOULD-" for a receiving agent? 
"SHOULD be able to verify but we won't require it in a future 
version"? If so, that means that we are saying "we intend to break 
interoperability with previous versions of this spec because of 
security issues". Breaking the implied stability promise we made when 
there is no real threat (such as people forging 768-bit signatures) 
seems a bit over the top.

Further, such an interpretation of SHOULD- also means that we intend 
to deprecate 1024 bit keys in the foreseeable future even though the 
cryptographic security of >90% of Internet commerce is based on those 
keys. If the intention was to get implementers to take us seriously, 
saying this may not have the desired effect.

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 13 May 2008 18:50:02 +1200

Paul Hoffman <[email-masked]> writes:

>You'll need to justify this one, Peter. Show me some examples where any
>previous version of S/MIME, none of which have "sane" lower limits, was used
>by any organization to justify a stupid key size.

How many would you like?  Without naming names (if anyone really insists I
could perhaps name them in private), there's an organisation using 128-bit RSA
keys for access control to significant amounts of power switching gear because
everyone knows that 128-bit keys are good so it should be fine for RSA.  Since
this is in the US I'm not that fussed about someone using it to take out their
power transmission systems :-), but I think some other people might be.  Uhh,
Canadian health board using RSA in ECB mode to encrypt patient data, and they
ended up using either 128- or 64-bit keys because otherwise things ran too
slowly.  Signing using 384-bit keys by a european government organisation...
how many do you want, and how long have you got?  I haven't got them all
committed to memory so I'd have to dig back through old email and whatnot.

I realise these aren't all specificially for S/MIME (the signing one was, at
least for PKCS #7) but they're examples of just what people will do if the
standards don't disallow it.  A number of the examples came from talking to
other IETF security folks so there's probably a lot more like this floating
around (every time I post one of these horror-story comments I tend to get a
bunch of email saying "That's nothing, you should hear this one...").  In the
case of two of the three above the justification given was some variation on
"if these really were no good then they'd be explicitly disallowed.  Since
they aren't, it's perfectly OK to do this".

>Please suggest specific text that would meet your criteria.

The original (proposed) MUST NOT text.  There's no point in verifying a
signature that you know is insecure because you know no more about the
validity of the data after the verification than you did before.  If the
signature can't tell you anything about the validity of the data that's been
signed then it should be rejected as an invalid signature because it's not
serving the purpose for which it was intended.

Peter.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 May 2008 09:08:43 -0700

At 6:50 PM +1200 5/13/08, Peter Gutmann wrote:
>How many would you like?

Only real ones that relate to this thread, thank you.

>Without naming names (if anyone really insists I

...and none of these relate to the S/MIME standard, right?

>standards don't disallow it.

I'll take that as a "right, they don't relate to the S/MIME standard, 
they're general key-size blunders". That is, the current S/MIME 
standard mandates being able to sign with 512-bit keys, but your 
examples above show that the blunderers don't do that. Please explain 
why you think that changing the standard will have any effect on them 
at all.

>A number of the examples came from talking to
>bunch of email saying "That's nothing, you should hear this one...").

Fully agree.

>In the

I'm skeptical, to say the least. If you have actual quotes of people 
saying that, fine; quoting someone third-hand through an IETF 
security geek is not a good way to get accurate results.

>The original (proposed) MUST NOT text.

There was no verb in that text. Are you supporting "MUST NOT sign 
with keys under 512 bits", "MUST NOT verify signatures whose keys are 
under 512 bits", or both?

>There's no point in verifying a
>validity of the data after the verification than you did before.

Fully agree. Please say why you know that every signature with keys 
of 511 bits is insecure, yet ones with 512 bits are secure enough.

>If the

Fully agree.

---

From: Luther Martin <[email-masked]>
Date: Tue, 13 May 2008 10:47:59 -0700

> security geek is not a good way to get accurate results.

I'm with Peter on this one.

I don't want to try to one-up Peter's stories (although I might be able to), I've also seen all sorts of blunders caused by people unfamiliar with public-key technology not understanding things that everyone on this list almost certainly takes for granted. I'd guess that most people who have worked with users of public-key technology for any length of time have a similar set of stories.

I've also seen people wanting to do make all sorts of crypto-blunders to make things easier to use, more efficient, or to comply with the letter of regulations instead of the spirit.

So explicitly banning things that might qualify as such blunders is probably a very good idea.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 13 May 2008 12:18:23 -0700

At 10:47 AM -0700 5/13/08, Luther Martin wrote:
>I don't want to try to one-up Peter's stories (although I might be 
>able to), I've also seen all sorts of blunders caused by people 
>unfamiliar with public-key technology not understanding things that 
>everyone on this list almost certainly takes for granted. I'd guess 
>that most people who have worked with users of public-key technology 
>for any length of time have a similar set of stories.

Of course this is true. What I question is Peter's assertion that 
putting a "don't be stupid" clause in the S/MIME RFC will cause any 
of them to be less stupid. In order to believe that, I want to hear 
someone say "I read the RFC and I still made this decision". I doubt 
that is true because I doubt any of these folks read the RFC.

>I've also seen people wanting to do make all sorts of 
>crypto-blunders to make things easier to use, more efficient, or to 
>comply with the letter of regulations instead of the spirit.
>

Maybe so, but that's not what Peter was advocating. I'm pretty sure 
he was supporting a statement that applications MUST NOT validate 
signatures that are 511 bits long while allow applications to 
validate signatures that are 512 bits long.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 14 May 2008 18:35:56 +1200

>...and none of these relate to the S/MIME standard, right?

Uhh, my posting specifically mentioned PKCS #7 signing (you actually quote the
sentence right below the above comment), which the last time I checked was
still S/MIME.

>Only real ones that relate to this thread, thank you.

Geeze, how many do you want me to dig up?  The three I mentioned are ones
readily to hand and ones where I knew I could mention them (in anonymised
form), I'd have to ask about posting some of the others (and also spend way
more time than it's worth digging through old email to locate them).  In any
case here's another one, from some years ago, again PKCS #7 (although PKCS #7
could probably be valid today as well, some places still don't know there's
something called CMS).  Anyway, some folks were using 256-bit RSA keys to send
signed EDI messages around wrapped in PKCS #7 envelopes.  The reason they used
these was because their application, written by some contractor in Java [0],
ran really slowly and their security guy [1] told them that the performance
problems were because of the RSA key size being used, which was initially 1K
bits (it had nothing to do with the fact that it was written in Java, it was
purely the RSA key size's fault).  Since they were using keys twice as large
as the industry standard 128 bits and everyone knew 128 bits was totally
secure, they were perfectly OK.

>If you have actual quotes of people saying that, fine; quoting someone third-
>hand through an IETF security geek is not a good way to get accurate results.

It wasn't third-hand, it was either from me if I was involved in the work or
from the person who was involved if it wasn't me [2].  In the above case
(which I was directly involved with) "the standard doesn't disallow it" was
the argument given for using the 256-bit keys, some mere coders tried to point
out that this was wrong and the response was that there was nothing in the
standard so say it was wrong and anyway the contractors had already spent X
amount of time on it so unless anyone could come up with a good reason not to,
it was being deployed with 256-bit RSA signatures.  And so it went.

Peter.

[0] This was before things like Bouncy Castle were freely available and
    people had to build higher-level protocols from raw JCE parts with their
    own three hands.
[1] He'd read the first two chapters of Applied Crypto.
[2] Or are you saying that other members of this list, who provided some of
    the information, aren't reliable sources?  Is there a vetting procedure
    they're supposed to go through first?  Shall I ask for affidavits?