Subject: Re: [psg.com #460] IESG - Transport - Oakley

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 10 Jun 2004 22:14:38 -0400

This message got caught in a filter at netbsd due to a false positive
keyword hit.  sorry for the delay in forwarding this..

Date: Wed, 9 Jun 2004 09:57:30 -0700 (PDT)
From: Chris Lonvick <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: [psg.com #460] IESG - Transport - Oakley
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>
References: <[email-masked]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi Folks,

This is the issue we were discussing a few weeks ago about the Oakley
groups.  The recommendation at the time was to
- reference the proper RFC for Oakley Group 2
- delete the actual value of the prime from the document
- state that other works will be forthcoming for better Groups.

I made an effort to capture it this way:

8.1  diffie-hellman-group1-sha1

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit
   MODP Group).  At the time of this writing, this method MUST be
   supported for interoperability as all of the known implementations
   support it.  The Working Group RECOMMENDS that implementations also
   support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method.
   However, at the time of this writing, those methods have not been
   defined.  It is expected that this Working Group will produce a
   document that defines this method for use in this protocol, so
   readers should look carefully at documents produced by this Working
   Group to see if other methods are required.

You can see the difference (htmlwdiff) from the prior version here:
  http://www.employees.org/~lonvick/secsh-wg/june02/transport-17-18.html

Can I get some feedback on this?

Thanks,
Chris

---

From: Markus Friedl <[email-masked]>
Date: Fri, 11 Jun 2004 09:51:22 +0200

again, why change a deployed protcol?

>    defined.

i think it vague comments like this should not be
in the document. just state that further groups
might be defined in additional documents.

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 11 Jun 2004 05:34:23 -0700 (PDT)

Hi Markus,

> again, why change a deployed protcol?

What I'm trying to do is to get the wording right in these documents so
that
1) the documents reflect the deployed protocol and,
2) they address the nits posted by the IESG.

As we saw in the discussion about the "@", the IESG may be incorrect in
their views.  In that case, we should make the document more clear to
minimize any confusion.  In this case, I don't see that I'm making any
changes to the protocol.  If I inadvertently do, please point it out and
I'll adjust it back.

> might be defined in additional documents.

OK.

> >   http://www.employees.org/~lonvick/secsh-wg/june02/transport-17-18.html

New proposal:

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit
   MODP Group).  At the time of this writing, this method MUST be
   supported for interoperability as all of the known implementations
   support it.  The Working Group RECOMMENDS that implementations also
   support the Oakley Group 14 [RFC3526] (2048bit MODP Group) method
   which is not defined in this document.  Other groups may be defined
   in additional documents.

Please comment on this.

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 11 Jun 2004 10:32:36 -0400

>    Group to see if other methods are required.

Don't say "At the time of this writing, this method MUST be supported...".
The use of MUST indicates something that implementors are _required_ to do 
in order to be compliant with the spec.  Either something is a requirement 
or it isn't; don't hedge.  In this case, diffie-hellman-group1-sha1 is 
REQUIRED, not just "at the time of this writing" but for any implementation 
that ever wants to claim compliance with this spec.

Don't say "The Working Group RECOMMENDS..." something that then isn't 
specified.  RECOMMENDED is also requirements language; it means "do this 
unless you have a good reason not to".  It's inappropriate to use it to 
describe something we don't specify.

It would be reasonable to RECOMMEND or (IMHO) even REQUIRE support for 
dh-gex; I think this issue has come up before.  It might be reasonable for 
the dh-gex document to RECOMMEND or REQUIRE support for a particular group, 
though I don't believe that's necessary.

RFC's are mostly timeless documents, and should avoid talking about the 
current state of things, which is likely to have changed by the time the 
reader sees the document.  For example, by the time this document is 
published as an RFC, dh-gex will probably be done and approved (looking at 
the I-D tracker, it looks like it only needs a corrected copyright).

Finally, section 8.1 is about defining the KEX method identified by the 
protocol constant "diffie-hellman-group1-sha1".  It should not define other 
methods, or include text or requirements that are not actually part of the 
definition of that method.

Let's limit section 8.1 to something like:

   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit
   MODP Group).  This method is REQUIRED.

The the security considerations section of the architecture document can 
talk about the issue and recommend support of dh-gex as a solution.
For that matter, we can list dh-gex as RECOMMENDED in section 6.5 (did the 
WG ever come to concensus on whether we should do this?), though it will 
mean a normative reference to that document.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 Jun 2004 13:00:44 -0500

> changes to the protocol.  If I inadvertently do, please point it out and

The IESG comment on this is:

"
13. Section 6.1. There is only one Oakley group defined, and it has an
equivalent strength of 80-bit symmetric encryption. There should be
additional Oakley groups that offer strength commensurate with the other
recommendations in the document. The document should explicitly
reference RFC 3526, and make use of group 14 (2048 bits).
"

To me this means that the IESG is unhappy with
diffie-hellman-group1-sha1.

But diffie-hellman-group1-sha1 is really a MUST for interop for
historical reasons.  I think it should remain a MUST, or, if downgraded
to SHOULD, an interop note should be added to the spec.

As for larger groups, we have three choices:

 - specify diffie-hellman-group14-sha1 and make it MANDATORY to implement
 - make diffie-hellman-group-exchange-sha1 MANDATORY to implement
 - both of the above

[...]
>    which is not defined in this document.  Other groups may be defined

How can the WG RECOMMEND that something be implemented which isn't
specified??  RFC3526 does not, after all, specify an SSHv2 key exchange
protocol for the various groups it describes.

I seriously doubt that this is what the IESG had in mind.

> - state that other works will be forthcoming for better Groups.

"state that other works will be forthcoming" does not amount to "[the
WG] RECOMMENDS that implementations also support the Oakley Group 14..."

See above.

Cheers,

Nico
--

---

From: der Mouse <[email-masked]>
Date: Fri, 11 Jun 2004 14:43:16 -0400 (EDT)

>  - make diffie-hellman-group-exchange-sha1 MANDATORY to implement

As an implementor, I would argue for the first of these.  Getting
diffie-hellman-group-exchange-sha1 right is a good deal more
complicated than simply using another fixed group.

Of course, as a security geek, I argue for the second, or perhaps the
third, since g-ex-sha1 is stronger than g14-sha1 just on general
principles (because the putative attacker knows less a priori) - at
least if the size parameters are suitable.

/~\ 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: [email-masked] (Niels Möller)
Date: 12 Jun 2004 20:15:16 +0200

> complicated than simply using another fixed group.

I also argue this way. If we need to change anything at all at this
stage (and it seems the IESG has a valid concern), then I think we
should do it the simple way and get it over with.

Mandating one more fix group, diffie-hellman-group14-sha1, is a simple
change to the spec, and a 20-line change to update an implementation.

Is it still appropriate to use sha1 (rather than sha256) with group
14? Staying with sha1 has the advantage that it reduces the number of
cryptographic algorithms that must be included in a minimalistic
implementation of the protocol.

Regards,
/Niels

---

From: Damien Miller <[email-masked]>
Date: Sun, 13 Jun 2004 22:53:49 +1000

> change to the spec, and a 20-line change to update an implementation.

Agreed, so long as the diffie-hellman-group1-sha1 remains a MUST.

I'd like to see DH-GEX recommended, but I think that can be done in the
DH-GEX draft itself when it is advanced.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Sun, 13 Jun 2004 15:28:14 -0400

> Agreed, so long as the diffie-hellman-group1-sha1 remains a MUST.

Yes, there is a strong interoperability argument for keeping 
diffie-hellman-group1-sha1.  Not only is there a very large installed base, 
but there are many distinct implementations.  Expecting every implementor 
to support the new group and every user to deploy a new version overnight 
would be unreasonable.

> I'd like to see DH-GEX recommended,

Me too.

> but I think that can be done in the

Yeah, but it would be better to do it in the core specification, where the 
recommendation will have more visibility.  IIRC all DH-GEX needs is some 
cleanup wrt copyright issues (and, by now, new boilerplate).  If that can 
happen soon it doesn't seem like it would be unreasonable to have a 
normative reference to it.

> implementation of the protocol.

I don't know, but it certainly would be desirable to stick with sha1.  For 
one thing, it means the new method can be specified in one sentence, and as 
you note, implemented very nearly as easily.

It might be desirable to RECOMMEND or even REQUIRE that 
diffie-hellman-group14-sha1 be listed _before_ diffie-hellman-group1-sha1, 
so that its use is preferred when both sides support it.  And of course, I 
imagine that implementors will provide policy options to turn off support 
for either group.

-- 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: 14 Jun 2004 09:51:12 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> diffie-hellman-group14-sha1 be listed _before_
> diffie-hellman-group1-sha1, so that its use is preferred when both
> sides support it.

I don't think such a recommendation or requirement is appropriate at
all; algorithm selection is an implementation/local configuration
issue. Saying that both groups MUST be supported is clear enough, I'd
expect that all implementations except possibly very constrained ones
will prefer group14 over group1, as soon as it's implemented and
tested.

As I understand it, the goal of this wg since the beginning has been
that the specified algorithms, and in particular, all RECOMMENDED or
REQUIRED algorithms, should be *good enough* from a security
perspective. So that users can choose freely between algorithms for
whatever reasons they have, without compromising security by mistake.
A user should not be able to break security by using ordinary
algorithm selection options[2], and then the default algorithm
preferences in implementations shouldn't matter either.

No matter what the specification and implementations do, there will
always be some link that is weakest (and that could well be something
out of scope of the protocol spec, like the backup routines for the
seedfile of the randomness generator, whatever). Our job is to ensure
that the weakest link is reasonably strong, not to spell out the
relative strength of each link.

Now I'm afraid I'm not up to date on the state of art in computing
discrete logarithms. If it's the case that group1 really is considered
insecure, then the spec should grandfather[1] its use (in much the
same way as we would discourage plain DES, if it had ever appeared as
a MUST in te specification), but as far as I'm aware, that's not the
case.

Bottom line: Just specify diffie-hellman-group14-sha1.

Regards,
/Niels

--
[1] Thanks to our chair Bill who explained the meaning of this very
useful verb a while ago.

[2] And letting users prefer "none" at all in an implementation
degrades the user interface. I should probably stop supporting it, or
at least rename the command line option from -c none to
--I-dont-want-any-security-and-I-know-what-I-am-doing.

---

From: Jon Bright <[email-masked]>
Date: Mon, 14 Jun 2004 11:16:08 +0200

> will prefer group14 over group1, as soon as it's implemented and

Nonetheless, providing a hint to possibly-ill-informed implementors 
about what should come first by default wouldn't be a bad thing?  I 
agree that it certainly shouldn't be REQUIRED, but RECOMMENDing that the 
default configuration prefers group14 would hardly be a bad thing?  Few 
admins I know would trust themselves to play with the ordering of 
algorithm selection, making the implementor's default choice a very 
relevant issue.  Helping the implementors to get this right doesn't 
really have many disadvantages?

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: [email-masked] (Niels Möller)
Date: 14 Jun 2004 13:22:18 +0200

Jon Bright <[email-masked]> writes:

> about what should come first by default wouldn't be a bad thing?

Adding such a recommendation would not be the end of the world as we
know it, but it would be a useless bloat of the spec, imho. The
protocol specification should explain the details needed for
implementing the protocol, it's not the place for random advice on how
to best use and implement the protocol. For example we don't include a
long discussion on the pros and cons of aes vs des3, and I think it's
good that we don't do that.

I think it should be fairly obvious that group14 is harder to crack
than group1, and that using group14 will consume more cpu cycles. If
there's anybody who doesn't agree it's obvious, and who is willing to
write a *concise* and correct piece of text that says that group14 is
believed to be more secure than group1, then I won't strongly oppose
that such text is added to the spec. But I still think it's
unnecessary, and I certainly don't want to have to wait for such text
to materialize.

Defining the group and referring to RFC 3526 should be enough (it's a
little unfortunate that RFC 3526 doesn't include group two for
comparison).

BTW, about naming. The proposed naming is a little confusing:

  SSH name                      "Well known" name
  
  diffie-hellman-group1-sha1    Well known group 2     (RFC 2412)
                      ^                          ^
  diffie-hellman-group14-sha1   Well known group 14    (RFC 3516)
                      ^^                         ^^

On one hand, it would be a little more consistent to use
"diffie-hellman-group2-sha1" for oakley group 14 (meaning simply the
second fixed group defined for the ssh protocol). On the other hand,
it would be nice to be able to generalize

  diffie-hellman-groupXX-sha1   Well known group XX    (RFC 3516)

but then diffie-hellman-group1-sha1 would be a kind-of ugly exception.
I don't feel very strongly about this, though.

Regards,
/Niels

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Jun 2004 11:21:05 -0400

On Monday, June 14, 2004 13:22:18 +0200 Niels Möller <[email-masked]> 
wrote:

> to best use and implement the protocol.

Actually, the protocol specification is a perfectly reasonable place for 
advice to implementors.

> than group1, and that using group14 will consume more cpu cycles.

Well, that's the expectation I would have.  But I don't agree it will be 
obvious to everyone.

In any case, I don't have any particular attachment to adding such a 
recommendation; I just tossed it out there as an idea.

>   diffie-hellman-group14-sha1   Well known group 14    (RFC 3516)

Yup.  I blame the people who named diffie-hellman-group1-sha1.

> On the other hand,

I was assuming it was pretty much agreed that this would be the appropriate 
solution.  It does mean there's no name for the method which uses group 1, 
but somehow I suspect we don't care very much...

Oh, and for those reading who are confused...
- Groups 1-4 are defined in RFC2409 (IKE) and RFC2412 (Oakley).
  Groups 1 and 2 are MODP groups of size 768 and 1024 bits, and
  are defined identically in both places.
  Groups 3 and 4 are EC2N groups; they are _not_ defined identically
  in both places -- one of the two documents is in error, but I'm not
  awake enough to tell which.
- Groups 5 and 14-18 are defined in RFC3526 (not RFC2516).  They
  are MODP groups of increasing size, from 1536 to 8192 bits.

---

From: [email-masked] (Niels Möller)
Date: 14 Jun 2004 17:34:34 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> I was assuming it was pretty much agreed that this would be the
> appropriate solution.  It does mean there's no name for the method
> which uses group 1, but somehow I suspect we don't care very much...

Agreed, it's reasonable to not care about the 768-bit "well known
group 1". It just wasn't clear to me before that the numbering in
"diffie-hellman-group1-sha1" does *not* match the numbering elsewhere
(RFC 2412).

Regards,
/Niels

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2004 11:34:46 -0500

> you note, implemented very nearly as easily.

DH-GEX uses SHA-1, so if SHA-1 is not appropriate for DH group 14 then
it doesn't seem appropriate for DH-GEX either...

> imagine that implementors will provide policy options to turn off support 

Why not generalize diffie-hellman-group<N>-<hash> and recommend group 14
w/ SHA-1?

Then when adding new ciphers we can ensure that eash new cipher has a
recommended group (and recommended group size for DH-GEX).

And then recommend that peers advertise first groups of the recommended
size for the cipher with the largest key size.

I don't mean to replace DH-GEX by this suggestion, just a quick and easy
way to satisfy the IESG's concerns without requiring much effort on the
part of any implementors, particularly ones that don't implement DH-GEX.

One result of using standardized DH groups is a higher degree of
confidence, for clients, in the quality of selected groups over groups
offered by servers in DH-GEX.

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Tue, 15 Jun 2004 07:57:14 +1000

> it doesn't seem appropriate for DH-GEX either...

If the issue is that sha1 only returns 160 bits, insufficient to fully
populate the keys for aes192-cbc and aes256-cbc then I don't believe
that this is a practical prolem (maybe in ~70 years) and certainly not
one to delay publication over.

-d

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2004 17:15:11 -0500

> one to delay publication over.

I don't think it's a practical problem now, no.

But parametrizing the SSHv2 DH kex (diffie-hellman-group<N>-<hash>)
shouldn't hold up publication as long as we quickly reach consensus
on the meaning of <N> and <hash>.

I'm not opposed to limitting <hash> to SHA-1 to begin with.

Nico
--

---

From: Damien Miller <[email-masked]>
Date: Tue, 15 Jun 2004 08:34:40 +1000

> on the meaning of <N> and <hash>.

Throughout the protocol, all of these fields are names, not parameters.
Parametising one but not all may give implemntors the idea that they
have the ability to pick and choose (e.g. cipher key lengths).

I think we should specify diffie-hellman-group1-sha1 (MUST),
diffie-hellman-group14-sha1 (RECOMMENDED or MUST), perhaps recommend
DH-GEX (ideally *in* the DH-GEX document when it is advanced) and leave
it at that.

-d

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 14 Jun 2004 17:43:13 -0500

> have the ability to pick and choose (e.g. cipher key lengths).

They are names, but there's no reason that we can't parametrize names
for the simple DH kex.  I see no reason why we couldn't let implementors
pick and choose as long as there are required ones for interop.

> DH-GEX (ideally *in* the DH-GEX document when it is advanced) and leave

I don't oppose this.

I do prefer that we parametrize the DH kex in addition, but that is not
essential.  Whatever else we do though, let's make sure that the DH
group namespace is consistent going forward; we can use "group14" or
"group2" now, but then after that we should follow the whichever
convention in adding new groups.

And I do prefer "group14" over "group2" because that places the DH group
namespace control in one place.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Jun 2004 18:50:49 -0400

> DH-GEX (ideally *in* the DH-GEX document when it is advanced) and leave

I still believe that recommending DH-GEX in the core document is better 
than doing so only in the DH-GEX document.  People can claim to implement 
ssh without having ever _read_ the DH-GEX document.

Other than that, I'm inclined to agree.  We should adopt the groupNN 
convention informally, but making it a formal parameter seems to invite 
implementors to interpret other names the same way.

At this point I don't think we have any disagreement that
- we should specify diffie-hellman-group14-sha1
- it should be at least RECOMMENDED (I prefer REQUIRED; who objects?)
- we should not specify other hashes at this time

---

From: Damien Miller <[email-masked]>
Date: Tue, 15 Jun 2004 09:29:43 +1000

> ssh without having ever _read_ the DH-GEX document.

Well, DH-GEX seems to need a little more work than the core docs and it
has not received as much scrutiny. If mentioning a document that will
not likely be published until well after the core docs is deemed
acceptable, then we don't oppose it.

> - we should not specify other hashes at this time

Agree.

-d

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 14 Jun 2004 20:24:32 -0400

On Tuesday, June 15, 2004 09:29:43 +1000 Damien Miller <[email-masked]> 
wrote:

>> than doing so only in the DH-GEX document.  People can claim to
>> implement  ssh without having ever _read_ the DH-GEX document.
>

According to the ID-tracker, this document went through IESG-wide last call 
back in January, and there are very few comments on record, all procedural. 
It sure looks to me like it needs little more than for the editor to submit 
a new document which addresses the remaining issues.  Can someone who knows 
please explain whether this is correct, and if not, what is the real status 
of this document?

If we want to put a normative reference to DH-GEX into the core document, 
we can do so.  It will hold up publication until DH-GEX is published, but 
only at the last minute (like, RFC-Editor will sit on the completed 
document until the references can all be resolved).  I don't consider that 
to be a big deal, especially since I think the actual delay will be zero.

-- Jeff

---

From: der Mouse <[email-masked]>
Date: Mon, 14 Jun 2004 21:18:55 -0400 (EDT)

>> Throughout the protocol, all of these fields are names, not
>> parameters.  Parametising one but not all may give implemntors the
>> idea that they have the ability to pick and choose (e.g. cipher key
>> lengths).
> for the simple DH kex.  I see no reason why we couldn't let
> implementors pick and choose as long as there are required ones for
> interop.

By parameterizing, here, are we talking about something like

	diffie-hellman-groupN-HASH is a valid method name for any N for
	which $REFERENCE defines a group, and any HASH for which
	<blah>.

or are we talking about

	diffie-hellman-groupN-HASH is a method name; the first protocol
	packet contains the group number and the hash name ...

or are we talking about standardizing group14-sha1 and group1-sha1 and,
in our own minds, reserving the rest of the diffie-hellman-group%d-%s
namespace for future specification along similar lines?

My own impression has been that we've been doing the last of these, but
now I'm not sure.

For what it's worth, I agree with

>> DH-GEX (ideally *in* the DH-GEX document when it is advanced) and
>> leave it at that.

As for...

> we can use "group14" or "group2" now, but then after that we should
> follow the whichever convention in adding new groups.

...for what it's worth, I prefer group14, with the group1/group2
confusion grandfathered.  (If it were entirely up to me, I'd define
group2 as the official name for the old one, with group1 as a
deprecated equivalent for the sake of interoperability.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Niels Provos <[email-masked]>
Date: Mon, 14 Jun 2004 21:28:10 -0400

> please explain whether this is correct, and if not, what is the real status 

It's on my TODO list.  I will have a new draft sometime this week.

Niels.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 14 Jun 2004 22:12:17 -0400

> 	which $REFERENCE defines a group, and any HASH for which

some seem to be implying this.

> 	packet contains the group number and the hash name ...

I haven't seen any indication that anyone was seriously suggesting
this; moreover, I believe this breaks group negotiation unless all
parties agree in advance to support all groups (which sort of defeats
the purpose) since you can't add parameters to the offered group..

> My own impression has been that we've been doing the last of these, but

I believe consensus is congealing around this option.  Anyone who
believes otherwise should speak up ASAP.

> deprecated equivalent for the sake of interoperability.)

I'm speculating that the ssh group 1 == ike group 2 confusion arose
from a desire to have a distinct group number space for the two
protocols.  If you're going to use the same groups at each bit size,
that makes no sense to me.

						- Bill

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jun 2004 11:49:42 -0400

> 	which $REFERENCE defines a group, and any HASH for which

Yes, that's what Nico meant when he proposed parameterizing these kex 
method names, at least for the case where HASH is 'sha1'.  The advantage is 
that if we do this, we then have a well-defined kex method for any of the 
standard Oakley MODP groups, including any defined in the future, without 
having to define them separately in each document.  This is analogous to 
the approach we take with the GSSAPI key exchanges, where there is 
automatically a well-defined SSH key exchange for any GSSAPI mechanism that 
meets certain requirements.

I think it was understood that the HASH namespace would really just be 
cases defined by this WG, but that any suitable value of N would be usable 
without a new specification.

> 	packet contains the group number and the hash name ...

No, we're certainly not doing this.  Or rather, we are; the method name in 
question is diffie-hellman-group-exchange-sha1, and it is defined in 
draft-ietf-secsh-dh-group-exchange-04.txt.  But it is not the subject of 
this discussion.

Note that we're mostly talking about group selection here.  I don't think 
anyone is seriously considering another hash, and it's not at all clear 
that there's a convenient namespace to draw hash names from as there is for 
groups.

Of course, for any specific hash we want to use it is easy to write a 
document that says "diffie-hellman-group1-FOO specifies Diffie-Hellman key 
exchange as described in [ssh-transport] Section 8 with [... description of 
the FOO hash ...] as the hash and Oakley Group 2 [RFC2409] (1024bit MODP 
Group).".

If we make "groupN" a parameter, the text changes somewhat:
"For any N>2, if RFC2412 or its successors define Oakley group N as a MODP 
group, then diffie-hellman-groupN-FOO specifies Diffie-Hellman key exchange 
as described in [ssh-transport] Section 8 with [... description of the FOO 
hash ...] as the hash and the specified group."

And of course, it is easy to write similar text for DH-GEX.

> namespace for future specification along similar lines?

We've pretty much agreed we're going to do at least this much.  The 
question is whether we will formalize the groupN syntax, such that other 
groups can be used without explicit specification.

> deprecated equivalent for the sake of interoperability.)

Actually, I don't think anyone's spoken up who _doesn't_ prefer the 
"group14" nomenclature.  But I don't think we should assign an alternate 
name to diffie-hellman-group1-sha1 -- I can see no benefit to having 
multiple names for the same thing.

---

From: [email-masked] (Niels Möller)
Date: 15 Jun 2004 18:04:50 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> "For any N>2, if RFC2412 or its successors define Oakley group N as a
> MODP group, then diffie-hellman-groupN-FOO specifies Diffie-Hellman

As far as I'm aware, the requirement above that a group is of the
"modp" kind is unnecessary. Not that I'm planning to implementing any
more fancy groups (like EC, discussed some weeks ago) anytime soon,
but SSH diffie-hellman exchange should work fine with any group where
the DH-problem is hard. For groups where it's not obvious how to
represent an element as a single bignum, the mapping from group
elements to byte strings would also have to be specified somewhere, of
course.

Anyway, I think this parameterization thing is unnecessarily
complicated. We need one more fix group, let's just do that. If we
find that we need another fix group in the future (e.g. if
dh-group-exchange for some reason isn't universally accepted as the
way to go, or if we want ec-groups, or whatever), then it's simple to
choose another fix group and a suitable name for it when the need
arises.

> "group14" nomenclature.  But I don't think we should assign an
> alternate name to diffie-hellman-group1-sha1 -- I can see no benefit
> to having multiple names for the same thing.

Agree totally. Keep it simple.

/Niels

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Jun 2004 11:21:31 -0500

> 	which $REFERENCE defines a group, and any HASH for which

Though I have no fundamental objections to this, it does seem to go too
far.

> 	packet contains the group number and the hash name ...

No.

> namespace for future specification along similar lines?

Yes, but, I'd like the namespace reservation to be a bit more than just
"in our minds" -- though we can't bind subsequent changes to SSHv2 to
a group naming policy, we can certainly recommend one in the spec.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jun 2004 12:33:44 -0400

> elements to byte strings would also have to be specified somewhere, of

Sure; there's certainly no reason other groups wouldn't work.  But as you 
note, the wire representation of group elements would have to be defined 
for those groups where they're not single integers, including EC groups. 
In addition, the method description in section 8 embeds the MODP group 
operation; for this method to be well-defined with other groups, the 
description would have to be generalized.

Really, I don't expect there will be any new ECP or EC2N Oakley groups. 
But the existing groups 3 and 4 are both EC2N groups, and I didn't want to 
give anyone ideas about trying to use these groups when the protocol is not 
well-defined for them.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jun 2004 12:41:06 -0400

> a group naming policy, we can certainly recommend one in the spec.

[TRANSPORT]

8.1 diffie-hellman-group1-sha1
   The "diffie-hellman-group1-sha1" method specifies Diffie-Hellman key
   exchange with SHA-1 as HASH, and Oakley Group 2 [RFC2409] (1024bit
   MODP Group).  This method MUST be supported for interoperability as all
   of the known implementations currently support it.  Note that, for
   historical reasons, this method is named using the phrase "group1"
   even though it specifies the use of Oakley Group 2.

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.

[NUMBERS]

4.3  Key Exchange Method Names

   ...

   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.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Jun 2004 12:11:46 -0500

>   "diffie-hellman-groupN-sha1" should be reserved for this purpose.

No mention of HASH functions other than SHA-1?  Should there be an IANA
registry for SSHv2 kex names?

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jun 2004 13:22:35 -0400

On Tuesday, June 15, 2004 12:11:46 -0500 Nicolas Williams 
<[email-masked]> wrote:

> No mention of HASH functions other than SHA-1?

Eh; I was going to write that text and decided not to.

> Should there be an IANA

Indeed there should.  It is defined in section 4.3 of
draft-ietf-secsh-assignednumbers-06.txt, which is the section I was 
proposing to append text to.

-- Jeff

---

From: Damien Miller <[email-masked]>
Date: Wed, 16 Jun 2004 08:22:29 +1000

> choose another fix group and a suitable name for it when the need

Agree