Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

[denis bider <ietf-ssh3%denisbider.com@localhost>]

Hey Jeffrey,

thank you for your comments. :-)

I have updated the draft based on this feedback. Same URL - new version:

http://www.denisbider.com/draft-dsa-sha2-256.txt


> Even though it's fairly obvious from the algorithm name,
> I think that should be mentioned in the abstract and
> introduction.  It might be appropriate to work it into
> the title, too

Done so.


> The reference to FIPS-186-3 in the introduction seems
> superfluous.

Removed.


> NIST SP 800-131A doesn't "suggest" or "consider" that
> 1024-bit DSA and SHA-1 are disallowed after 2013.
> It disallows them for government use(*).

Updated.


> If you don't include it, then either implementors will
> support it anyway, or users will be confused when their
> keys don't work.

I've done some testing, and found that Windows CNG cannot import an L=2048, N=224 private key generated with Crypto++.

In the interest of interoperability, I think it's better to prohibit this option. I have added language to this effect.


> I assume that with N=224, you'd want to actually use SHA-224.

It may be interesting to note that Windows built-in crypto - a major, FIPS-certified platform - does not support SHA-224 at all. With DSA, or standalone.


> For that matter, what about _larger_ key sizes?
> What's to say that NIST won't publish FIPS-186-5
> with an (L=4096, N=512) option.  

Allowing for such keys to be used with the same algorithm name would break interoperability with applications unaware of such a new standard.

I have added a section further emphasizing that any departure from the specified options and key sizes requires a different algorithm name.

denis


----- Original Message -----
From: Jeffrey Hutzelman 
Sent: Thursday, October 29, 2015 07:34
To: denis bider 
Cc: jhutz%cmu.edu@localhost ; ietf-ssh%NetBSD.org@localhost ; nisse%lysator.liu.se@localhost ; stephen.farrell%cs.tcd.ie@localhost ; mdb%juniper.net@localhost ; jon%siliconcircus.com@localhost 
Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

On Thu, 2015-10-29 at 00:25 +0000, denis bider wrote:
> I have whipped up a draft here:
> 
> http://www.denisbider.com/draft-dsa-sha2-256.txt

Not too bad.  A few comments, all minor:

- The use of SHA-256 is a departure from the original ssh-dss algorithm,
which
  specifies SHA-1.  Even though it's fairly obvious from the algorithm
name, I
  think that should be mentioned in the abstract and introduction.  It
might be
  appropriate to work it into the title, too, since that's all that
appears in
  the RFC index, but IMHO that's less important.

- The reference to FIPS-186-3 in the introduction seems superfluous.

- NIST SP 800-131A doesn't "suggest" or "consider" that 1024-bit DSA and
SHA-1
  are disallowed after 2013.  It disallows them for government use(*).
  I suggest an edit something like this...

OLD:
   The National Institute of Standards and Technology (NIST) Special
   Publication 800-131A [800-131A] suggests that DSA keys shorter than
   2048 bits, and with subgroup sizes under 224 bits, are considered
   to have an encryption strength of less than 112 bits, and are
   disallowed after 2013. DSA key sizes of 2048 bits or more, and with
   subgroup sizes of 224 bits or more, are considered acceptable.

NEW:
   National Institute of Standards and Technology (NIST) Special
   Publication 800-131A [800-131A] suggests that DSA keys shorter than
   2048 bits, and with subgroup sizes under 224 bits, are considered
   to have an encryption strength of less than 112 bits.  It disallows
   use of such keys for U.S. Government use after 2013. DSA key sizes
   of 2048 bits or more, and with subgroup sizes of 224 bits or more,
   are considered acceptable.

Similarly for the next paragraph.



> At this point, I'm most uncertain about whether we should allow the following option also:
> 
>    L = 2048, N = 224
> 
> Arguments for:
> 
> - No apparent interoperability reason to exclude it.
> - Perhaps there are DSA implementations that don't easily support
> setting subgroup size, and can only easily generate the N=224 option?
> Does anyone know of one?
> 
> Arguments against:
> 
> - Slightly weaker than N = 256
> 
> Any comments? Thoughts?

If you don't include it, then either implementors will support it
anyway, or users will be confused when their keys don't work.  I assume
that with N=224,
you'd want to actually use SHA-224.

For that matter, what about _larger_ key sizes?  What's to say that NIST
won't publish FIPS-186-5 with an (L=4096, N=512) option.  You'd want to
use SHA-512 with that, but wouldn't it be better not to constrain this
to the key sizes that are available today?

I'd suggest allowing arbitrary key sizes with L >= 2048 and N >= 224,
with the hash to be the largest of SHA-{224,256,384,512} that produces a
digest not larger than N bits.

-- Jeff


(*)  Or rather, it disallows use of all digital signature algorithms
with strength less than 112 bits.  While specific parameters are
mentioned for RSA and DSA, formally the strengths are defined in SP
800-57.  Hpwever, I think we can ignore the latter detail for our
purpose.