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

The algorithm/idea itself sounds reasonable, but why not write this up as a
short RFC and get IANA to actually assign the name?

On 27 October 2015 at 23:50, denis bider <[email protected]> wrote:

> Hey everyone,
>
> so, over the past several years, it looks like everyone has proverbially
> screwed the pooch with regard to plain old DSA key sizes larger than 1024
> bits.
>
> OpenSSH is now going so far as to have dropped ssh-dss in its default
> configuration, which is reasonable, given that this algorithm is now only
> useful for 1024-bit DSA.
>
> Everyone is migrating now to ECDSA over NIST curves or Ed25559, which is
> all nice and well - these appear to be strong algorithms, according to
> information available at this time.
>
> Still, I think it's a pity for larger DSA keys to never have had a chance;
> but more than sentimentalism, I think we're losing out on heterogeneity and
> backup options in case something, anything, turns out to be wrong in
> Elliptic Curve territory.
>
> Now, if we want to agree on some way to implement large DSA keys, the
> "ssh-dss" algorithm name is tainted for use with larger key sizes, because
> there are implementations out there that implement them in incompatible
> ways:
>
> - There were older versions of OpenSSL and OpenSSH that implemented
> 2048-bit modulus, but kept 160-bit subgroup. This did not effectively
> increase the security of the scheme, compared to 1024-bit modulus.
>
> - Our (Bitvise) implementation predates FIPS 186-3 by a year. It supports
> a larger modulus, and appropriately larger subgroups, BUT continues to use
> SHA-1 as the hash function. After FIPS 186-3, other implementations of
> larger DSA keys, such as Windows CNG, support the larger DSA keys in
> conjunction with SHA-2.
>
> - A majority of other "ssh-dss" implementations support only 1024-bit key
> sizes, and can't verify signatures with larger DSA keys under that scheme.
>
> Larger DSA keys need a new scheme name for compatibility reasons.
>
> I therefore suggest a new SSH key algorithm, dsa-sha2-256, which
> cherry-picks from FIPS 186-3 the following two options:
>
> L = 2048, N = 256
> L = 3072, N = 256
>
> In other words:
> - modulus size is either 2048 or 3072
> - subgroup size is 256 bits
> - hash function is SHA2-256
>
> I choose the name "dsa-sha2-256", rather than a suffixed name ("...@
> bitvise.com") for the following reasons:
>
> - Suffixed names are overly long and clumsy. If I were to choose a
> suffixed name instead, I would go with just "...@bv".
>
> - Suffixed names complicate standardization. If a suffixed algorithm is
> commonly implemented, there's pressure to have a version with a
> non-suffixed name, and now we have multiple names for the same thing.
>
> - I don't see many ways for "dsa-sha2-256" to be implemented incorrectly
> or incompatibly by a reasonable implementor. There's really only one DSA,
> the one specified in FIPS 186. This has four variants. The suffix -sha2-256
> explicitly specifies which hash function to use, and strongly suggests use
> of the 256-bit subgroup sizes.
>
> Unless someone has a strong and reasonable objection, I intend to
> implement this for Bitvise SSH Client and Server 7.xx as described above.
>
> Comments welcome.
>
>