RE: DH KEX names an "aberration"?

[Chris Lonvick <clonvick%cisco.com@localhost>]

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