Subject: DH KEX names an "aberration"?

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 02 Feb 2005 19:59:04 -0500

In preparing a response to a message on another list, I went back to the 
current transport draft to check on what the outcome was of the DH key 
exchange group naming debate.  I found the following text:

   Note that, for historical reasons, the name
   "diffie-hellman-group1-sha1" is used for a key exchange method using
   an Oakley group as defined in [RFC2412].  Subsequently, the Working
   Group attempted to follow the numbering scheme of group numbers from
   [RFC3526] with diffie-hellman-group14-sha1 for the name of the second
   defined name.  This is considered an aberration and should not be
   repeated.  Any future specifications of Diffie-Hellman key exchange
   using Oakley groups defined in [RFC2412] or its successors should be
   performed with care and a bit of research.

Now, I remember arguing that we should name these things based on the group 
numbers assigned in RFC2412 and its successors, and that "group1" was an 
aberration.  And, I remember other people arguing that we should treat 
"group1" as existing practice to be followed, and assign our own names 
independent of those assigned in RFC2412.

The text above implies that we chose to follow the existing numbering 
scheme and use "group14", but that also that we consider _that_ an 
"aberration" and something to be avoided in the future.  That just doesn't 
make any sense to me -- if we decided we should use our own naming scheme, 
why use "group14" at all.  And if we decided not to use our own naming 
scheme, why does the document essentially say that was a bad decision?

Also, while I don't disagree with the last sentence in principle, it seems 
to be implying that the current work was not "performed with care and a bit 
of research".  Given the amount of debate and, yes, research that went into 
that decision, that seems inappropriate here.

What happened here?

-- Jeff

---

From: [email-masked] (Niels Möller)
Date: 03 Feb 2005 09:16:10 +0100

Jeffrey Hutzelman <[email-masked]> writes:

>    repeated.

> "aberration" and something to be avoided in the future.  That just
> doesn't make any sense to me -- if we decided we should use our own
> naming scheme, why use "group14" at all.  And if we decided not to use
> our own naming scheme, why does the document essentially say that was
> a bad decision?

I agree the text is a little confusing. Given that there was no
consensus on the preferred naming style, and that both the current
choices were motivated by compatibility by the deployed
implementations, I don't think it's appropriate to say that either
name is an "aberration". We might need to comment the inconsistent
naming, though.

>    Any future specifications of Diffie-Hellman key exchange

> Also, while I don't disagree with the last sentence in principle, it
> seems to be implying that the current work was not "performed with
> care and a bit of research".

I think the important message here is that adopting new Oakley groups
is not a mere formality; one shouldn't expect that oakley group 17 is
automatically given the name diffie-hellman-group17-sha1 and be
supported in the ssh protocol.

Regards,
/Niels

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 03 Feb 2005 11:53:49 -0500

> name is an "aberration". We might need to comment the inconsistent

Well, in an ideal world, the WG would come to some consensus on which 
naming form we should use.  Then we could state which convention the WG had 
decided to adopt, and indicate that the non-conformant name was used in 
order to promote interoperability with deployed implementations.  I'd much 
rather have this debate resolved once and for all than have the same 
argument every time we go to add new groups.

Is this the issue we had Nico flip a coin for, or was that something else?

> supported in the ssh protocol.

In fact, one shouldn't assume it gets any particular name or is 
automatically supported.  Perhaps we just need to point out that key 
exchange names are in general not constructed, and each variation must be 
defined and registered explicitly.

-- Jeff

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 4 Feb 2005 08:18:08 -0800 (PST)

Hi,

The coin toss was for this subject.  Please read over the prior and
current text and let me know if the proposed text sounds good.
Wordsmithing would be appreciated.

Past - [TRANS]-21:

   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
   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.

Current - [TRANS]-22:

   Additional methods may be defined as specified in [SSH-NUMBERS].

Proposed - [TRANS]-next

   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
   an Oakley group as defined in [RFC2412].  Subsequently, the Working
   Group attempted to follow the numbering scheme of group numbers from
   [RFC3526] with diffie-hellman-group14-sha1 for the name of the second
   defined name.  This inconsistency should not be repeated.  The naming
   of future specifications of Diffie-Hellman key exchange using Oakley
   groups defined in [RFC2412] or its successors should be performed
   with forethought and care.

Thanks,
Chris

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 04 Feb 2005 09:36:37 -0700

>    with forethought and care.

I don't recall the results of the coin toss, and it isn't
clear from this.  So how about one of the following, depending
on which way the toss went:

   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
   an Oakley group as defined in [RFC2412].  Subsequently, the Working
   Group attempted to follow the numbering scheme of group numbers from
   [RFC3526] with diffie-hellman-group14-sha1 for the name of the second
   defined name.  Future groups borrowed from [RFC2412] should continue
   to use the same numbering scheme used by [RFC3526].  However, without
   specific IETF action, no addition groups from [RFC3526] are valid in
   the SSH protocol.

OR:

   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
   an Oakley group as defined in [RFC2412].  Subsequently, the Working
   Group attempted to follow the numbering scheme of group numbers from
   [RFC3526] with diffie-hellman-group14-sha1 for the name of the second
   defined name.  Future groups borrowed from [RFC2412] should not attemp
   to use the same numbering scheme used by [RFC3526], but should
   use numbering unique to SSH.  I.e., the next group defined for SSH
   should be diffie-hellman-group2-sha1, regardless of it's source.

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Feb 2005 12:40:58 -0500

>>    [...] This inconsistency should not be repeated.  The naming

I think I prefer the phrasing "[RFC2412] and its successors".  Otherwise, 
Joseph's text looks good.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 04 Feb 2005 14:04:41 -0500

On Friday, February 04, 2005 07:44:39 PM +0100 denis bider 
<[email-masked]> wrote:

>> I think I prefer the phrasing "[RFC2412] and its successors".
>> Otherwise, Joseph's text looks good.
>
> Looks good to me too.
>
> It is my impression that the second variant is where we are headed, i.e.,
> with Jeffrey's nit, like this:
>
>
>> Note that for historical reasons the name "diffie-hellman-group1-sha1"
>> is used for a key exchange method using an Oakley group as defined
>> in [RFC2412].  Subsequently, the Working Group attempted to follow
>> the numbering scheme of group numbers from [RFC3526] with
>> diffie-hellman-group14-sha1 for the name of the second defined name.

So far, so good - these groups come from specific documents

>> Future groups borrowed from [RFC2412] and its successors should not

But "future groups" could come from any of this series of documents, so 
again, this is the right phrasing.

>> attempt to use the same numbering scheme used by [RFC3526], but

The numbering scheme is shared by all the documents, not just this one.

How about something like...

>> Future groups borrowed from [RFC2412] and its successors { should
>> continue | should not attempt } to use the same numbering scheme
>> used in those documents...

I really don't recall the results of the coin flip.  A quick check of the 
proceedings shows:

> ticket 460, 601: no consensus on list.
> flipped coin, heads for "group2", tails for "group14", came up tails
> will stick with diffie-hellman-group14-sha1

That implies the coin flip was only intended to apply to that one decision, 
and not to set a direction for future naming.  Bill, can you comment on 
this?

I'd prefer to have a direction for future naming, but not at the expense of 
delaying things indefinitely.  If we can agree on a direction, or accept 
the coin toss as setting one, then we should use one of Joseph's proposed 
paragraphs (modulo the wordsmithing we've just done).

Otherwise, if/when it is time to submit new documents to resolve the 
trademark issue, I think we should use Chris's proposed text, which cleans 
up the explanation of the situation while still leaving the long-term 
question unresolved.

-- Jeff

---

From: "denis bider" <[email-masked]>
Date: Fri, 4 Feb 2005 19:44:39 +0100

Looks good to me too.

It is my impression that the second variant is where we are headed, i.e.,
with Jeffrey's nit, like this:

> should use numbering unique to SSH.  I.e., the next group defined for
> SSH should be diffie-hellman-group2-sha1, regardless of its source.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 04 Feb 2005 15:32:21 -0500

> and not to set a direction for future naming.  Bill, can you comment on 

correct.  it was intended only for that one decision.

> paragraphs (modulo the wordsmithing we've just done).

(wg chair hat off)

For future direction, my preference would be to do something which doesn't
involve us arguing over which small integer refers to a which large integer.

but who am I to interfere with what appears to be gathering consensus..

						- Bill

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 7 Feb 2005 13:34:00 -0800 (PST)

Hi,

Way back in time, the WG agreed to use diffie-hellman-group2-sha1 for the
second defined kex method.  We never put that into any of the IDs as we
started discussing "proper naming".  I believe it was early last year and
we went for some time before we got into the discussion of associating the
number used with the group to the "group" number defined in RFC3526.
This led us to agree to use diffie-hellman-group14-sha1 and that's the way
it became in [TRANS]-19 and continues this way in the IDs.  Tero Kevininen
pointed out (in August) that "14"  should probably not be used as that
wasn't going to be a consistently referenceable number for the future.
This led some to think about going back to "2" but others argued that "14"
was in shipping code.  The coin toss resulted in us agreeing to use "14"
but we did not mention what we were to do with "2" nor with what we were
to do about recommending future naming schemes.  I was hoping to duck that
issue which I will now name "the briar patch issue".  (Every time I try to
crawl out of it, I get stuck worse.)

Going with the assumption that those who forget history are doomed to
repeat it, I'll propose the following text:

   Additional methods may be defined as specified in [SSH-NUMBERS].
   Note that the name "diffie-hellman-group1-sha1" is used for the first
   defined key exchange method using an Oakley group referenced from
   [RFC2412].  The Working Group first attempted to progress the
   namespace scheme by using "diffie-hellman-group2-sha1" for the second
   defined key exchange (kex) name.  This name was never used in any
   Working Group documents but was discussed in the mailing list.  It is
   not known if this kex name was implemented in any shipping code.
   During this deliberation period, the Working Group wanted to provide
   for a better naming scheme and attempted to follow the numbering
   scheme of group numbers from [RFC3526].  This resulted in the
   selection of "diffie-hellman-group14-sha1" rather than
   "diffie-hellman-group2-sha1" which the Working Group felt was not as
   descriptive.  After this name was generally approved by consensus and
   started appearing in subsequent Internet Drafts (and shipping code),
   it was noted that the numbers associated with the groups in [RFC3526]
   were assigned by the IANA and may be changed in the future, or that
   numbers may not be used at all.  This caused some indecision within
   the Working Group which was resolved at the Working Group meeting at
   the 60th IETF with the formal adoption of the
   "diffie-hellman-group14-sha1" name for the second defined kex method.
   This inconsistency should not be repeated in the future.  Future
   groups borrowed from [RFC2412] or its successors should not attempt
   to associate SSH kex algorithms with numbers from [RFC3526].  The
   naming of future specifications of Diffie-Hellman kex methods using
   Oakley groups defined in [RFC2412] or its successors should be
   performed with forethought and care.  It will probably be best if
   future names are unique to SSH and not dependent upon any external
   naming or numbering schemes.  Authors of future kex proposals may
   wish to consider the use of "diffie-hellman-group3-sha1" or
   "diffie-hellman-group15-sha1" for the next name.

I'll take input on the following which may modify this text:

- Did anyone actually use "diffie-hellman-group2-sha1" in shipping code?

- Should we state that "2" has been poisoned because of that?

- Should we leave it as use "3" or "15" next?  (If anyone responds with
"no" then they'll have to propose something better.)

--prior discussion elided for brevity--

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 07 Feb 2005 16:56:31 -0500

>    "diffie-hellman-group15-sha1" for the next name.

I don't think this level of "legislative history" needs to be in the 
document; that is what we have mailing list archives for.

I do not believe this document should make a value judgement on whether "it 
will probably be best if future names are unique to SSH", because I do not 
believe that we have consensus on whether that statement is true.

When I started reading your message, I was going to avoid revisiting Tero's 
argument that numbers assigned in an IANA-managed registry are not stable. 
However, since you've included a statement to that effect in the text, I 
must point out that this also was a point of contention.  It was not 
"pointed out" or "noted" that IANA was a bunch of morons who would randomly 
change the meaning of a protocol constant defined by IETF consensus.  It 
was argued, and there was argument against this position.

I'm sorry, but given that there was considerable argument over these issues 
and no clear resolution, I am opposed to any language in the draft which 
implies otherwise.  An IETF standards-track document simply cannot say "the 
working group was unable to reach consensus, but it should be this way". 
Any statement made in such a document must be the _result_ of WG consensus.

-- Jeff

---

From: Ben Harris <[email-masked]>
Date: Tue, 08 Feb 2005 00:15:22 +0000

>believe that we have consensus on whether that statement is true.

I agree.  To my mind, the naming of future KEX methods really isn't
important, and certainly isn't worth an entire page of explanatory text. 
The names are opaque strings, and anyone wanting to know what one means will
have to refer to the IANA registry anyway (since the two methods defined so
far use different naming schemes), so the next one (if group exchange
doesn't make it redundant) could perfectly well be called
diffie-hellman-plippyploppycheesenose-sha1 without causing any problems.

My feeling is that [SSH-TRANS] should be silent both on the history of the
existing names and what names should be used in future.

-- 
Ben Harris

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 07 Feb 2005 21:42:35 -0500

> document; that is what we have mailing list archives for.

Agreed.

> believe that we have consensus on whether that statement is true.

Also agreed.  Let's not try to predict the future.

> An IETF standards-track document simply cannot say "the 

When i took a straw poll, there was no clear consensus either way.  Since this 
*should have been* a trivial matter, we had a public coin flip.

we seem to have gotten lost inside the bikeshed
(see http://www.unixguide.net/freebsd/faq/16.19.shtml).

						- Bill

---

From: der Mouse <[email-masked]>
Date: Tue, 8 Feb 2005 00:16:11 -0500 (EST)

> [...], so the next [KEX method] (if group exchange doesn't make it
> redundant) could perfectly well be called

Well, except that some people would probably prefer
diffie-hellman-eblisoshaughnessy-sha1. :-)  Shall we toss a coin?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 10 Feb 2005 08:52:12 -0800 (PST)

Hi,

> (see http://www.unixguide.net/freebsd/faq/16.19.shtml).

The prior text which seemed to have near consensus was:

From the comments it looks like we should remove the text about the
history and the guidance for the future.  As such we would then have:

   Additional methods may be defined as specified in [SSH-NUMBERS]. The
   name "diffie-hellman-group1-sha1" is used for a key exchange method
   using an Oakley group as defined in [RFC2412].  The Working Group
   followed the numbering scheme of group numbers from [RFC3526] with
   diffie-hellman-group14-sha1 for the name of the second defined name.
   Future groups borrowed from [RFC2412] or its successors should not
   attemp to use the same numbering scheme used by [RFC3526].

Is this acceptable?

I do want to say that the primary purpose of this is for [NUMBERS]; this
is supposed to be the instructions for the IANA for the namespace.  It's
duplicated in [TRANS] for completeness.

Since we're meeting in Minneapolis, I'd like to get the IDs resubmitted
before the deadline which is 21 February.  Can I get some feedback on this
soon?

Thanks,
Chris

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 10 Feb 2005 12:10:58 -0500

here's a revision which documents the past rather than constraining the future:

   Additional methods may be defined as specified in [SSH-NUMBERS]. The
   name "diffie-hellman-group1-sha1" is used for a key exchange method
   using an Oakley group as defined in [RFC2412].  SSH maintains its own
   group identifier space which is logically distinct from Oakley and IKE;
   however, for one additional group, the Working Group adopted the number
   assigned by [RFC3526], using diffie-hellman-group14-sha1 for the name of 
   the second defined group.  Implementations should treat these names as 
   opaque identifiers and should not assume any relationship between the groups
   used by SSH and the groups defined in 2412 and its successors.

						- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Thu, 10 Feb 2005 11:04:16 -0700

>    used by SSH and the groups defined in 2412 and its successors.

This sounds good to me.

Thanks,

Joseph

---

From: Ben Harris <[email-masked]>
Date: Fri, 11 Feb 2005 13:49:52 +0000

>   used by SSH and the groups defined in 2412 and its successors.

That seems good to me.  Having looked at the relevant RFCs and the IANA
IPsec registry, it looks like the official reference for IPsec group 2 is
RFC 2409 rather than RFC 2412, and RFC 3526 is only vaguely a successor to
either.  Perhaps "in 2412 and its successors" should read "for IKE".

-- 
Ben Harris

---

From: [email-masked] (Niels Möller)
Date: 14 Feb 2005 16:12:15 +0100

> - Did anyone actually use "diffie-hellman-group2-sha1" in shipping code?

Shipped versions of lsh have used "diffie-hellman-group2-sha1" and
"diffie-hellman-group14-sha1" as synonyms.

> - Should we state that "2" has been poisoned because of that?

No.

> "no" then they'll have to propose something better.)

I think it's best to not try to make promises on behalf of the future
working group. Bill's neutral text looked good to me.

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 14 Feb 2005 07:32:02 -0800 (PST)

Hi,

> either.  Perhaps "in 2412 and its successors" should read "for IKE".

Ben points out something important.  2412 is INFORMATIONAL.  2409 and 3526
are STANDARDS TRACK.  Since the proposed text appears to have general
consensus, I'll modify the referents as follows:

   Additional methods may be defined as specified in [SSH-NUMBERS]. The
   name "diffie-hellman-group1-sha1" is used for a key exchange method
   using an Oakley group as defined in [RFC2409].  SSH maintains its own
   group identifier space which is logically distinct from Oakley
   [RFC2412] and IKE; however, for one additional group, the Working Group
   adopted the number assigned by [RFC3526], using
   diffie-hellman-group14-sha1 for the name of the second defined group.
   Implementations should treat these names as opaque identifiers and
   should not assume any relationship between the groups used by SSH and
   the groups defined for IKE.

2409 and 3526 will be normative references and 2412 will be informational.

Thanks,
Chris