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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Fri, Jun 11, 2004 at 05:34:23AM -0700, Chris Lonvick wrote:
> Hi Markus,
> 
> On Fri, 11 Jun 2004, Markus Friedl wrote:
> 
> > 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.

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

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

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.

And you also wrote:

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

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