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

From: Alfred Hönes <[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:

> 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.  ...

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.
>
> Would that address your concern?

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.

> Thanks,
> 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.

> On Jan 7, 2009, at 6:16 AM, Alfred Hönes wrote:
>
>> 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 3581bis, 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 ?
>>
>> ...

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]                     |
+------------------------+--------------------------------------------+