Subject: Re: 3850bis and 3851bis: proposed changes to cryptographic key sizes

From: Alfred Hönes <[email-masked]>
Date: Wed, 7 Jan 2009 12:16:22 +0100 (MEZ)

Folks,

I agree with Paul with regard to the process (new I-D preferable).

The AD proposed changes at first glance are intended to make the
requirements *stronger* (as far as possible without relying on
an official version of FIPS PUB 186-3) without sacrificing
backwards compatibility.

Therefore, I agree with the amended Security Considerations text,
for both 3850bis and 3581 bis, and the changes proposed for
receiving agent (signature verifier) behavior -- although these
now allow small key sizes (< 512) which were not allowed by
RFC 3850, and hence this change comes a bit to surprise.

However, I really do not understand why, at the 'low end', signature
*generating* agents shall now be allowed (via 'MAY') to generate
signatures with the even worse key sizes < 512, for both RSA and DSA.
Since already S/MIME v3.1 agents had no requirement for being able
to verify such signatures, why now adding the capability to produce
such signatures ?

Finally, nits for 3851bis, in (1) / Section 4.2 :

- I suggest    s!generated!generating!

- Also, for alignment with (2) / Section 4.3,
  it might be preferable to use plural:

  s!an S/MIME agent!S/MIME agents!

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Tim Polk <[email-masked]>
Date: Thu, 8 Jan 2009 09:13:47 -0500

Hi Alfred,

The lower bound was dropped for a couple of reasons.  Practically  
speaking,
any RSA/DSA keys smaller than 1024 bits offer little security.   
Setting any lower bound
seems to imply that there is a significant break point, and I did not  
want to give
that implication.  I also thought that implementations might want to  
set a more
aggressive bound (e.g., 768 bits) and leaving off the lower bound might
encourage making an explicit choice rather than supporting 512  
because it
was specified in the table.

Perhaps the right thing would be to add one more sentence in each of the
security considerations sections.

For 3850bis:

Note that previous versions of this standard set the lower bound for  
RSA and DSA key
sizes at 512 bits; implementations that support verification of  
certificates or CRLs
generated with weak keys MUST NOT support RSA or DSA keys of less  
than 512 bits.

For 3851bis:

Note that previous versions of this standard set the lower bound for  
RSA and DSA key
sizes at 512 bits; implementations that support verification of  
digital signatures
generated with weak keys MUST NOT support RSA or DSA keys of less  
than 512 bits.

Would that address your concern?

Thanks,

Tim Polk

On Jan 7, 2009, at 6:16 AM, Alfred HÎnes wrote:

> +------------------------ 
> +--------------------------------------------+
> +------------------------ 
> +--------------------------------------------+
>

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Jan 2009 12:00:30 -0800

At 9:13 AM -0500 1/8/09, Tim Polk wrote:
>Hi Alfred,
>
>The lower bound was dropped for a couple of reasons.  Practically speaking,
>seems to imply that there is a significant break point, and I did not want to give
>that implication.  I also thought that implementations might want to set a more
>encourage making an explicit choice rather than supporting 512 because it
>Note that previous versions of this standard set the lower bound for RSA and DSA key
>sizes at 512 bits; implementations that support verification of certificates or CRLs
>generated with weak keys MUST NOT support RSA or DSA keys of less than 512 bits.
>
>For 3851bis:
>
>Note that previous versions of this standard set the lower bound for RSA and DSA key
>sizes at 512 bits; implementations that support verification of digital signatures
>generated with weak keys MUST NOT support RSA or DSA keys of less than 512 bits.
>

I cannot say if it affects Alfred's concern, but I *strongly* object to such a normative change at this late date in the document cycle. Your original logic (don't imply a break point) is still valid. There may be perfectly valid local policy for a site to want to support shorter keys for historical reasons. We have already made it clear what the interoperability issues are, and we have set them based on security in the Internet context. The current wording obviously discourages anything under 1024 bits.

---

From: "Alfred H\Nnes" <[email-masked]>
Date: Thu, 8 Jan 2009 18:28:22 +0100 (MEZ)

On Thu, 8 Jan 2009 09:13:47 -0500, Tim Polk <[email-masked]> wrote:

> speaking, any RSA/DSA keys smaller than 1024 bits offer little
> security.  ...

Agreed.
(... I bet by all -- maybe except the majority of lazy users
     and admins, and a few vendors ...    :-) )

>       ...  Setting any lower bound seems to imply that there is
> a significant break point, and I did not want to give that
> implication.

My primary observation was that removing the break (that more or
less explicitely was present in S/MIME v3.1) might be observed by
implementers updating their software as indicating the converse.

> I also thought that implementations might want to set a more
> aggressive bound (e.g., 768 bits) and leaving off the lower
> bound might encourage making an explicit choice rather than
> supporting 512 because it was specified in the table.

That conceivably is comprised in the "MAY".

> Perhaps the right thing would be to add one more sentence in each
> of the security considerations sections.
>
> For 3850bis:
>
>   Note that previous versions of this standard set the lower bound
>   for RSA and DSA key sizes at 512 bits; implementations that support
>   verification of certificates or CRLs generated with weak keys MUST
>   NOT support RSA or DSA keys of less than 512 bits.
>
> For 3851bis:
>
>   Note that previous versions of this standard set the lower bound
>   for RSA and DSA key sizes at 512 bits; implementations that support
>   verification of digital signatures generated with weak keys MUST
>   NOT support RSA or DSA keys of less than 512 bits.
>

Only marginally.

These additions are useful as they contain additional information
not present elsewhere.

But my major concern was *not* the considerations for *receiving*
agents (signature / certificate / CRL *verification*), it was for
agents *generating* signatures (cf. the final paragraph quoted below).

All arguments w.r.t. installed base, existing certs, filed messages,
etc. hold for the verifier case, but they should not entangle the
production of new signatures.

Furthermore, despite the iterated parenthetical clause
"see Security Considerations" in the quoted requirements sections,
I strongly fear that many folks will be tempted to conceive the
striking tabular form there as "the message" the memo sends to
implementors.
If (only) the above explanations (and/or similar text for signature
generation) were added to the Security Considerations, then *their*
message should be clear -- but it might be overlooked.

Furthermore, arguably the tabular forms and the explanations would
be inconsistent, with a "MUST NOT" superimposed over the "MAY" in the
tabular form.  I strongly suspect that this would be perceived as
confusing, and at best cause never-ending discussions after the next
succcessfully solved RSA Challenge.

Therefore, I'd prefer having the "MUST NOT" lines for key size < 512
also added to the tabular listing of (at least) the signature
generating requirements.

> Tim Polk

One more point:

  Based on the still ongoing discussion on rogue certificates,
  the 3850bis Security Considerations should perhaps also be
  amended giving a perspective on probable ongoing consequences,
  for instance raising the awareness of the reader for expected
  enhancements, e.g. the use of Randomized Hashing.

  I suggest that the PKIX working group should start working
  on that topic ASAP, and SMIME should build on such work,
  with a document amending 3850bis.

>> for both 3850bis and 3581bis, and the changes proposed for
>> ...

Kind regards,
  Alfred.

--

---

From: Sean Turner <[email-masked]>
Date: Fri, 09 Jan 2009 11:23:29 -0500

> I cannot say if it affects Alfred's concern, but I *strongly* object to such a normative change at this late date in the document cycle. Your original logic (don't imply a break point) is still val…

I think I'm with Paul on not including this text.  We're giving a pretty 
darn big hint not to use keys less than 1024, but if they really really 
need to they ought to be able to without being considered non-compliant.

spt