I have whipped up a draft here:
http://www.denisbider.com/draft-dsa-sha2-256.txtAt 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
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
> ("...@bitvise.com") 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