Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal (fwd)

From: Chris Lonvick <[email-masked]>
Date: Wed, 4 Aug 2004 09:42:24 -0700 (PDT)

Hi,

I was hoping that this was a closed issue but I believe that Tero knows
something about this subject.  Can we have some discussion on this?  I'd
like to try to come to some consensus around one of the following:

- Tero knows of what he is saying and we need to adjust our wording.
<Extra points will be awarded for a wording proposal.>

- Tero knows of what he is saying but what we now have is good enough for
our purposes.

- "And now for something entirely different..."

Thanks,
Chris

---------- Forwarded message ----------
Date: Wed, 4 Aug 2004 01:28:35 +0300 (EEST)
From: Tero Kivinen
To: Chris Lonvick <[email-masked]>
Subject: Re: [psg.com #460] IESG - Transport - Oakley - new proposal

[I am not normally following secsh list, I am just reading last few
hundred emails, because I am bored in the PMTUD meeting, and I am
going through all ietf mailing list, so I do not send this directly to
the list (probably wouldn't go through because of spam filters), you
can forward this to the list if you feel like so. I will not be
reading the list again in near future, so I will not see any replies
to my email in few months...]

Chris Lonvick <[email-masked]> writes:
>      diffie-hellman-group1-sha1       REQUIRED
>      diffie-hellman-group14-sha1      REQUIRED

I think the group14 is very misleading. The number 14 is from the IANA
number allocated for the IKE to the "2048-bit MODP group" of the RFC
3526. (http://www.iana.org/assignments/ipsec-registry). The next
revision of the RFC 3526 might not have the numbers at all, or the
numbers might be different. Also IPsec WG might decide to change the
numbers if they want to do it.

It would be same as renaming the 3des-cbc with cipher5 etc...

>    Additional methods may be defined as specified in [SSH-NUMBERS].
>    Note that, for historical reasons, the name
>    "diffie-hellman-group1-sha1" is used for a key exchange method
>    using
>    Oakley Group 2. This is considered an aberration and should not
>    be

It happens to use the same group that is also used in the IPsec and
there it has been allocated number 2 from the IANA... There is no
reason why secsh should use the IPsec IANA registry for the numbers.

>    repeated. Any future specifications of Diffie Hellman key
>    exchange
>    using Oakley groups defined in [RFC2412] or its successors should
>    be
>    named using the group numbers assigned by IANA, and names of the
>    form
>    "diffie-hellman-groupN-sha1" should be reserved for this purpose.

Note, that group 14 is NOT oakley group. It is not defined in the
RFC2412, and the RFC 3526 does not use name oakley group anywhere. The
IANA registry for IKE (ipsec-registry) allocates the numbers for those
groups.

> 8.2 diffie-hellman-group14-sha1
>
>    The "diffie-hellman-group14-sha1" method specifies Diffie-Hellman
>    key
>    exchange with SHA-1 as HASH, and Oakley Group 14 [RFC3526]
>    (2048bit
>    MODP Group), and it MUST also be supported.

Oakley group 14 is very misleading and plainly wrong. Any groups
defined in the RFC3526 are not oakley groups. They do not have
anything to do with the oakley document.

The "2048-bit MODP group" group defined in the RFC3526 has been
allocated number 14 in the IPsec/IKE registry, but secsh should be
using their own registries, not to share the IKE registry. Note, that
IKEv2 will have its own registry for the groups, and that registry
might not be kept sync with the IKEv1 registry of groups.

> Please send back your comments to this proposal.

--

---

From: Damien Miller <[email-masked]>
Date: Thu, 05 Aug 2004 21:15:01 +1000

> like to try to come to some consensus around one of the following:

I think that we should just change the drafts to read "RFC3526 group 14"
instead of "oakley group 14". The RFC isn't going to change
retrospectively and it seems like total overkill to set up an IANA
registry for a couple of groups, especially if DHGEX is going to be
preferred in the future.

-d

---

From: [email-masked] (Niels Möller)
Date: 19 Aug 2004 17:25:00 +0200

> registry for a couple of groups, especially if DHGEX is going to be

I'm sorry if I haven't been following the group closely enough
recently, but now I'm confused. I thought the entire purpose of the
secsh-numbers document was to specify an IANA registry for ssh-related
names and numbers. The creation of that new registry seems totally
orthogonal to whether or not we try to keep some of the numbers in the
registry somehow in "sync" with the ipsec iana registry.

As for the appropriateness of the name "oakley group 14" for our
group, I have been assuming that the group, and the name "group 14",
originates in some paper (outside of the RFC series), together with
some motivation and analysis of the method by which the primes were
selected. I would have expected a reference to such a paper in RFC
2412 and RFC 3526, but I can't seem to find any.

If that's not the case, I'd have to agree with Tero that it doesn't
make much sense to copy arbitrary numbers from the ipsec iana registry
into our registry.

Can any onebody shed some light on the origins of the "oakley groups"
and their names?

Confusedly yours,
/Niels

PS. And also "RFC3526 group 14" doesn't make much sense to me; the
motivation for the "group14" naming we've been discussing have been to
make it *easily* generalizable to new groups that appear in some well
defined (by somebody else) series. Doing that, and then referring to a
fix document like RFC3526 defining precisely 6 groups for the
definition of the supposedly growing series, makes it all pretty
pointless.

PPS. I've been on vacation off the net for a few weeks. Hence my late
comments.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 19 Aug 2004 17:39:59 -0400

> registry somehow in "sync" with the ipsec iana registry.

The numbers document _does_ create a registry for the names of key exchange 
methods.  What we are discussing is a guideline for choosing the names of a 
certain class of key exchanges; namely, those defined in the same way as 
the existing diffie-hellman-group1-sha1 but using different groups.

> 2412 and RFC 3526, but I can't seem to find any.

The name "group 14" does not originate in any paper; it derives from the 
fact that the group in question is identified by the constant 14 in IKE. 
See the IANA registry for IKE attributes.

> defined (by somebody else) series.

Yup.  The appropriate phrase would be IKE group 14, preferably with a 
reference to the aforementioned registry.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: [email-masked] (Niels Möller)
Date: 20 Aug 2004 08:25:10 +0200

> reference to the aforementioned registry.

But then, do we mean ike-1 or ike-2? If these numbers are arbitrarily
selected by the ipsec wg, as my understanding is now, then that
matters, because there's no requirement that ike-1 and ike-2 use the
same numbers, right? (I'm not following ipsec closely, but my
impression is that ike-2 is not a small incremental change to ike-1,
but more or less a rewrite, trying to remedy the ike-1 disaster).

Regards,
/Niels

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 20 Aug 2004 11:12:13 -0400

On Friday, August 20, 2004 08:25:10 +0200 Niels Möller 
<[email-masked]> wrote:

> selected by the ipsec wg, as my understanding is now

They're not selected arbitrarily.  There is an IANA registry.
If you go look at the registry, you'll see that so far, group numbers
have been assigned in sequence, though not all of the groups are MODP
groups and not all are defined in the documents we're discussing.

So, the problem here was that we borrowed a group defined elsewhere (good), 
and then gave it our own number which didn't match the number it had in the 
other place (bad), and did match the number that some other group had in 
the other place (even more bad).

The proposed solution is "don't do that"; particularly, don't make up our 
own numbers.  As long as we are borrowing groups from that registry, we 
should borrow the numbers along with them.

We can include a reference to the group table in the Internet Key Exchange 
Attributes registry at IANA.  I think that will be sufficiently 
non-ambiguous, especially if ikev2 reuses the registry, as it should.

-- Jeff

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 20 Aug 2004 13:03:45 -0400

the problem is that we've already gone down the road of defining our
own group numbers.  IIRC,  SSH group 1 is IKE group 2.

names such as "rfc3526-modp2048" seem more appropriate and unambiguous
for the family of groups defined in that document.

						- Bill

---

From: [email-masked] (Niels Möller)
Date: 20 Aug 2004 22:31:06 +0200

> for the family of groups defined in that document.

In this case, we're considering two different naming schemes:

A:

  diffie-hellman-group1-sha1  "well known group 2", see RFC 2412
  diffie-hellman-group2-sha1  "2048-bit modp group", see RFC 3526

B:

  diffie-hellman-group1-sha1  "well known group 2", see RFC 2412
  diffie-hellman-group14-sha1 "2048-bit modp group"/"IKE group 14", see RFC 3526

The first consistently uses an independent ssh-specific name space.
The second attempts to borrow a subspace of that namespace from a
namespace defined elsewhere, and by doing so, it also *attempt* to
define the meaning of

  diffie-hellman-groupx-sha1

for arbitrary x. That's the main selling point of B, right?

I believe this selling point simply fails. To define e.g.
diffie-hellman-group3-sha1, an RFC must be published that defines its
meaning unambigously. That requirement is from
draft-ietf-secsh-assignednumbers-06.txt, section 4.3, and I think it's
an appropriate requirement.

To me, it seems cleaner and less confusing to stick to the original
intentions of Tero and others and use a small ssh-specific name space,
and naming scheme A above. Then diffie-hellman-group1-sha1 means "well
known group 2" from one RFC. diffie-hellman-group2-sha1 means a
2028-bit group from a different RFC. diffie-hellman-group3-sha1 will
mean whatever we choose it to mean at the time we decide we need yet
another fixed group.

(Also note that it is consistent with the numbers document to have
some later RFC define diffie-hellman-ike2-groupx-sha1 for some set of
x, if we ever want that. That's however something that we *don't* need
to address at the moment).

I'm sorry we're digging up this old issue again. I want to state that
I don't feel very strongly about this naming stuff, but I'd prefer
that we get it right and clean. And from the earlier discussions, I
think the rest of you have a similar attitude to it.

So, what's the right thing to do now?

Regards,
/Niels

-- 
  There are two difficult unsolved problems in computer science:
  1. Cache invalidation
  2. Naming of things                             -- Phil Karton

---

From: "Timo J. Rinne" <[email-masked]>
Date: Sun, 22 Aug 2004 00:31:45 +0300

> mean whatever we choose it to mean at the time we decide we need yet

I fully agree with Niels here.  This way we would get it clear once and 
for all.  Should we borrow group numbering from ike, we should then 
include all of them instead of arbitrary subset.  Anyways, it is much 
simpler and straightforward to use independent numbering in SecSh.

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

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 25 Aug 2004 10:58:26 -0700 (PDT)

Hi,

It appears that there is some consensus about going back to our own
namespce  " diffie-hellman-groupN-sha1 "

We have defined N=1 and N=2 so we could propose to the IANA that new ones
- be created via the consensus method
- N monotonically increases
- once assigned, N must not be reused
- future assignments not using DH and/or SHA1 may have entirely different
  formats.

This will remove the proposal for the use of  diffie-hellman-group14-sha1 .

Is there any significant dissent?

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 25 Aug 2004 16:08:13 -0400

On Wednesday, August 25, 2004 10:58:26 -0700 Chris Lonvick 
<[email-masked]> wrote:

> This will remove the proposal for the use of  diffie-hellman-group14-sha1

(1) I don't see a need for a sub-registry.  There is a registry of key 
exchange method names; that is all that is required.  Saying "use these 
group numbers defined over here" made sense when the intent was to 
normalize our naming to reflect another existing registry.  If we're not 
going to do that, than no more needs to be said.

(2) I still think it is a bad idea to continue the practice of using 
phrases like "group N" to mean completely different groups than the rest of 
the community means when they say "group N".  I wonder how many times 
various members of this WG are going to have to explain that no, the group 
size is not inadequate, because by "group 2" we mean not the 1024-bit MODP 
group that everyone else means when they say "group 2", but instead a 
2048-bit MODP group, which in the rest of the world is known as "group 14".

There is value in using the same names as other people.
There is value in using them to mean the same things.
Doing so is fundamental to successful communication.

BTW, I seem to recall someone asking about how these group moduli were 
selected, and asking for a reference.  The appropriate reference is 
RFC2412, appendix E, in which the original 5 well-known Oakley groups are 
defined.  The appendix describes the algorithm in some detail, such that 
one could repeat the process and get the same values, or apply it to 
generate larger groups of arbitrary size.  It also explains why that 
particular algorithm was chosen.

---

From: [email-masked] (Niels Möller)
Date: 26 Aug 2004 12:41:01 +0200

> > namespce  " diffie-hellman-groupN-sha1 "

I think a lot of peple are silent. It's hard to tell if that's because
they agree, or don't care, or are all on vacation.

> exchange method names; that is all that is required.  Saying "use
> these group numbers defined over here" made sense when the intent was
> to normalize our naming to reflect another existing registry.  If
> we're not going to do that, than no more needs to be said.

Agree fully. Keep it simple.

> phrases like "group N" to mean completely different groups than the
> rest of the community means when they say "group N".

I don't think it's possible to fix that, given that we already have
"diffie-hellman-group1-sha1 mean "well known group 2", (and I think we
have agreed that it is far too late to change our name for that
group). I'm afraid that using both an ssh-specific numbering scheme
(for oakley group 2) and an ipsec-spcific numbering (for oakley group
14) will cause even more confusion than sticking to an ssh-specific
numbering.

> RFC2412, appendix E, in which the original 5 well-known Oakley groups
> are defined.

It was me asking about that some days ago. Thanks.

Regards,
/Niels

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 26 Aug 2004 22:55:34 +1200

[email-masked] (=?iso-8859-1?q?Niels_M=F6ller?=) writes:

>I think a lot of peple are silent.

Well there's a challenge I can't back down from: IMHO the most appropriate
solution is to use SSH-specific values, monotonically increasing small
integers, etc etc as already proposed.

Perhaps we could have a quick straw poll on this.

Peter.

---

From: Simon Tatham <[email-masked]>
Date: Thu, 26 Aug 2004 13:09:14 +0100

> they agree, or don't care, or are all on vacation.

I think any scheme would be perfectly adequate provided it was
clearly defined what name went with which group, and clearly defined
which groups implementors needed to support in the general case.

As far as I'm concerned, this is one of those situations in which
the utilities of the various choices go something like:

 * choice A, ten points
 * choice B, nine and a half points
 * choice C, nine points
 * long delay caused by debating the various options in detail,
   minus one thousand points. :-)

-- 
Simon Tatham         "Happiness is having a large, warm, loving,
<[email-masked]>    caring, close-knit family in another city."

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 26 Aug 2004 15:23:14 +0100

> they agree, or don't care, or are all on vacation.

Oh - All right then :-)  I happen to agree with using our own range of
simple numbers for the above,  N=1, N=2, etc...

DF

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 26 Aug 2004 10:38:41 -0400

> 14) will cause even more confusion than sticking to an ssh-specific

Yes, I think we're agreed we can't rename diffie-hellman-group1-sha1.
Personally, I think living with one legacy exception is acceptable, and I 
think consistency with other usage is more important than consistency with 
the previous (IMHO poor) choice.

But, I don't think it's more important than getting the documents out 
sometime this century.

So yes, let's take a straw poll, and move on.

I think everyone knows my position. :-)

-- Jeff

---

From: "Timo J. Rinne" <[email-masked]>
Date: Thu, 26 Aug 2004 17:54:55 +0300

> I think everyone knows my position. :-)

My vote goes goes for having a SecSh protocol specific namespace for 
groups.  1, 2, 3 ...

-- 
Timo J. Rinne <[email-masked]>

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 26 Aug 2004 10:02:21 -0600

> My vote goes goes for having a SecSh protocol specific namespace for 

My vote goes for secsh protocol specific namespace as well.

Thanks,

Joseph

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 26 Aug 2004 13:26:52 -0400

hang on.  i'm collecting some data on what other protocols have done
on this front and will send it out shortly and will (re)start the
straw poll at that time..

						- Bill

---

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

>    minus one thousand points. :-)

Hear, hear. IMO the cost of having a slightly inconsistent group naming
convention (which we already agreed on) is much less than the cost of
deploying secsh yet again.

-d

---

From: Damien Miller <[email-masked]>
Date: Fri, 27 Aug 2004 09:24:23 +1000

> deploying secsh yet again.

s/deploying/delaying/

-d