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

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Monday, June 14, 2004 21:18:55 -0400 der Mouse 
<mouse%Rodents.Montreal.QC.CA@localhost> wrote:

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

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.

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

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.

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

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.


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

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.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA