Subject: Straw Poll on group name

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Aug 2004 16:19:27 -0400

At the end of this message, you'll find a summary from Tero Kivinen of
the usage by other protocols of the common MODP groups on the saag
list; I think it conclusively demonstrates that every user of the MODP
groups is doing something different.

That only leaves

straw poll:
	[A] we should use small integers to refer to common groups
		[sample] diffie-hellman-group2-sha1

	[B] we should refer to groups by size:
		[sample] diffie-hellman-group2048-sha1

	[C] we should refer to groups by the ike number
		[sample] diffie-hellman-group14-sha1

In your response to the poll, please:
 a) explain the one you prefer and why.
 b) list any options you find unacceptable and explain why.

I'll use this to gauge consensus.
						- Bill

------- Forwarded Message

From: Tero Kivinen <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [saag] naming/use of rfc2412/rfc3526 groups by other protocols
In-Reply-To: <[email-masked]>
References: <[email-masked]>
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Edit-Time: 19 min
X-Total-Time: 29 min
Sender: [email-masked]
Content-Length: 2079

Bill Sommerfeld writes:
> rfc2412 (oakley) defines several "MODP" diffie-hellman groups of
> varying sizes in appendix E.  Several larger groups were defined in
> RFC3526.

And their numbers are handled by the IANA registry for the Internet
Key Exchange (IKE) attributes
(http://www.iana.org/assignments/ipsec-registry).

> SSHv2 uses one of these groups, and also includes an extension to
> allow the group to be dynamically negotiated.
> 
> Muddying the waters, SSHv2 defined its own group-numbering space;
> diffie-hellman-group1-sha1 is the same as IKE's "group 2".

Yes, that is correct, it should use its own number space, as it wants
to control what groups are allowed etc. Thats why it should have its
own registry listing the groups. 

> Do any protocols other than SSHv2 reuse IKE's MODP Diffie-Hellman
> groups?

Yes. 

> If so, what naming convention, if any, is used in that protocol?

iSCSI RFC 3723 (Securing Block Storage Protocols over IP) uses same
prime number, but different generator for those groups, and names them
with nameslike "MODP-XXXX" where XXXX is the number of bits. Their
groups are named in their own IANA registry
(http://www.iana.org/assignments/iscsi-parameters). 

draft-clancy-eap-pax-00.txt uses the 3072 bit group and gives it
number 0x01. 

draft-moskowitz-hip-09.txt uses 1536-8192 bit groups, and gives them
their own numbers from 3-6.

draft-riikonen-silc-ke-auth-08.txt uses 1024-2048 bit groups, and
gives them their own name diffie-hellman-group1 - diffie-hellman-group3.

draft-tuexen-sctp-auth-chunk-01.txt uses all IKE modp groups, and uses
the same numbers than IKE, but it seems they will allocate their own
IANA registry for number, the initial values will simply be same. 

draft-cam-winget-eap-fast-00.txt uses 2048 bit group, but I think they
send the whole group every time, i.e the groups do not have registry
or name.

draft-ietf-tls-srp-07.txt also uses 3072-8192 bit groups, but
different generators, and they send the whole group every time (I
think), thus there is no registry or name. 
- -- 
[email-masked]

------- End of Forwarded Message

---

From: Henrick Hellström <[email-masked]>
Date: Thu, 26 Aug 2004 22:34:18 +0200

> 		[sample] diffie-hellman-group14-sha1

I prefer [B] and I find [C] unacceptable.

The reason is that most application developers and administrators have 
never even heard of IKE so "Group 14" would not mean anything to them, 
but they probably would understand the significance of the number 2048.

Using the name "diffie-hellman-group14-sha1" is the worst option. It 
would in my case only lead to a stream of feature requests for the 
schemes ranging from "diffie-hellman-group2-sha1" to 
"diffie-hellman-group13-sha1", and would leave me with having to explain 
that these scheme will not be implemented because they simply do not exist.

Alternative [A] is better than [C], but I prefer [B] since it is the 
most self-documenting name.

-- 
Henrick Hellström
www.streamsec.com

---

From: Damien Miller <[email-masked]>
Date: Fri, 27 Aug 2004 08:27:57 +1000

> 		[sample] diffie-hellman-group14-sha1

Why: because it is deployed, because we should be way past the point of
making fiddling changes to things we have already agreed upon, and
because the mooted move to DH-GEX means the registry will only be of
passing importance anyway.

>  b) list any options you find unacceptable and explain why.

The other two: diffie-hellman-group14-sha1 is deployed.

-d

---

From: Anil Madhavapeddy <[email-masked]>
Date: Fri, 27 Aug 2004 00:33:54 +0100

> 		[sample] diffie-hellman-group14-sha1

I fail to see how anything other than [C] would be useful, given that:

$ pwd
/usr/src/usr.bin/ssh
$ grep -r diffie-hellman-group14-sha1 * 
kex.h:#define   KEX_DH14        "diffie-hellman-group14-sha1"

Any implementation would have to support it anyway for good interop
with OpenSSH.

-- 
Anil Madhavapeddy                                 http://anil.recoil.org
University of Cambridge                          http://www.cl.cam.ac.uk

---

From: [email-masked] (Niels Möller)
Date: 27 Aug 2004 08:49:13 +0200

> 		[sample] diffie-hellman-group14-sha1

I prefer A. It's simple, consistent with the naming of
diffie-hellman-group1-sha1, and I think we need our own registry
anyway.

/Niels

---

From: Markus Friedl <[email-masked]>
Date: Fri, 27 Aug 2004 11:17:34 +0200

> 		[sample] diffie-hellman-group14-sha1

We already agreed on the name "diffie-hellman-group14-sha1" and
OpenSSH 3.9 ships with this identifier.  The other groups don't
matter since we agreed to recommend DH-GEX for the future.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 27 Aug 2004 21:56:16 +1200

> a) explain the one you prefer and why.

[A].  SSH will need to maintain its own registry anyway even if we go for [B]
(the exact definition of "group 2048" will need to be specified somewhere in
the same way that "group 2" will), and monotonically-increasing small integers
are much cleaner and more flexible than a pile of arbitrary-sized numbers.  In
addition the fixed-bit-size numbers are non-reusable, so if (for example) a
problem is found in "group 2048" necessitating its replacement with a
different "group 2048" without the problem, there's no way to do it.  With
"group 2" you just replace it with "group 3".

As for the "group 14" issue, just CNAME it to "group 2" with a note about it
being that way for historical purposes, it's an absolutely trivial fix.

> b) list any options you find unacceptable and explain why.

[C].  It's tying SSH to the (unpredictable and uncontrollable) decisions of a
completely unrelated standards group.

Peter.

---

From: "Timo J. Rinne" <[email-masked]>
Date: Fri, 27 Aug 2004 14:26:53 +0300

>  b) list any options you find unacceptable and explain why.

I prefer A and find C unacceptable.

A is simple and gives us simple and unambiguous way to refer any 
dh-group in any standard document we like.  It is also logic 
continuation of the current practise.

B is better since we probably are not going to make more than one group 
of one specific size.  However we already have a group not using this 
convention.  Also why knowingly limit the possibility to consistently 
name several groups in a consistent matter.

C is clearly against the common practise in current protocol standard 
drafts.  It is also inherently inconsistent having already one exception 
in ssh-draft.  More inconsistency arises from the fact that we are not 
going to use entire ike namespace.

-- 
Timo J. Rinne		<[email-masked]>		http://www.ssh.com

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 27 Aug 2004 05:20:25 -0700 (PDT)

Hi,

I'll keep my "editor" hat on so don't consider this to be a vote.

> I fail to see how anything other than [C] would be useful, given that:

We could continue with [A] and define diffie-hellman-group14-sha1 in
[TRANS].  A simple note to the IANA in [NUMBERS] could state that future
values of N MUST NOT include 14.

For some reason, I am reminded of the scene from "Monty Python and the
Holy Grail" in which they discuss counting to three before throwing the
Holy Hand Grenade.  :-)  Let's get this resolved and move on.

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 27 Aug 2004 16:16:41 +0200

> values of N MUST NOT include 14.

Such a note makes no sense to me at all. If we want
"diffie-hellman-group14-sha1", then we go with [C], and that's it. It
may be a little ugly (depending on one's taste), but it's *not*
formally a special case in any way at all.

When we use words like "MUST" in a spec, those words are directed to
everyone who wants to implement the specification properly. It's
pointless to put in "MUST":s which are directed not at implementors of
our specification, but to some future working group specifying
revisions or extensions to the specification.

/Niels