Subject: [Cfrg] Fwd: Re: Proposal and intent to implement "dsa-sha2-256" SSH key algorithm

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Oct 2015 00:34:02 +0000

FYI, some discussion on ssh list of larger key sizes for dsa
in ssh. Be interested in folks' opinions about this if you
care to express them on the ssh list.

TIA,
S.

-------- Forwarded Message --------
Subject: Re: Proposal and intent to implement "dsa-sha2-256" SSH key
algorithm
Date: Thu, 29 Oct 2015 00:25:37 +0000
From: denis bider <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked],
[email-masked], [email-masked]

I have whipped up a draft here:

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

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?

 ----- Original Message ----- From: Jeffrey Hutzelman  Sent: Wednesday,
October 28, 2015 15:31 To: denis bider  Cc: [email-masked] ;
[email-masked]  Subject: Re: Proposal and intent to implement
"dsa-sha2-256" SSH key  algorithm   On Tue, 2015-10-27 at 22:50 +0000,
denis bider wrote: > I choose the name "dsa-sha2-256", rather than a
suffixed name > ("[email-masked]") for the following reasons:   Please
don't do that, unless you are going to write and publish an  IETF
consensus RFC and register the name properly.  Just making up names
leads to collisions and resulting interop problems, which is a very
real possibility if someone else is thinking the same as you but isn't
active on this list.   Also, with no registration, someone seeing this
and wanting to interoperate has no idea where to look for a
specification.     > - Suffixed names are overly long and clumsy. If I
were to choose  a > suffixed name instead, I would go with just
"...@bv".   Please don't do that either.  Besides being non-compliant,
it again leaves anyone wanting to interoperate with no idea how to find
a  spec.       > - 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.   Yes, that's an issue, if the thing actually gets
standardized.  The right answer is to keep using the original name,
rather than inventing  a new one, unless the algorithm has actually
changed during the standardization process.       > - 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.   Well, someone could decide
to implement only one of the two modulus sizes available with 256-bit
subgroups.  Or, they could decide that  all four options are
permissible, as long as the hash is SHA-256.  I  think it would be
desirable to publish an RFC to nail these sorts of things down.   -- Jeff

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 28 Oct 2015 19:54:08 -0700

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

Why are you trying to enhance DSA support when SSH has many better options
available? RSA support is ubiquitous, and both ECDSA and EdDSA are pretty
common now.

-- 
Tony Arcieri