IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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.


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




Home | Main Index | Thread Index | Old Index