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

From: Chris Lonvick <[email-masked]>
Date: Mon, 21 Jun 2004 13:41:26 -0700 (PDT)

Hi Folks,

I've gone through all of the notes on this Issue again and now have
6 changes to make to the documents for this.

---------------------
(1)
[TRANSPORT] - revise section 6.5

6.5  Key Exchange Methods

   The key exchange method specifies how one-time session keys are
   generated for encryption and for authentication, and how the server
   authentication is done.

   Two REQUIRED key exchange method has been defined:

     diffie-hellman-group1-sha1       REQUIRED
     diffie-hellman-group14-sha1      REQUIRED

   These methods are described later in this document.

   Additional methods may be defined as specified in [SSH-NUMBERS].
   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.

---------------------
(2)
[TRANSPORT] - revise section 8.1

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.

---------------------
(3)
[TRANSPORT] - add section 8.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.

---------------------
(4)
[NUMBERS] - Add a line in the current Section 4.3

4.3 Key Exchange Method Names

   The Key Exchange Method Name describes a key-exchange method for the
   protocol [SSH-TRANS]. The names MUST be printable US-ASCII strings,
   and MUST NOT contain the characters at-sign ('@'), comma (','), or
   whitespace or control characters (ASCII codes 32 or less). Names are
   case-sensitive, and MUST NOT be longer than 64 characters.

   Requests for assignment of new key-exchange method names must be
   accompanied by a reference to a standards-track or Informational RFC
   which describes this method.

   Method name Reference
   ------------ ---------
   diffie-hellman-group1-sha1 [SSH-TRANS, Section 8.1]
   diffie-hellman-group14-sha1 [SSH-TRANS, Section 8.2]

---------------------
(5)
[ARCHITECTURE]  modify 9.2.7 (Security Considerations for TRANS)
Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically
names diffie-hellman-group1-sha1. I'd like to reference both defined
key exchange methods in this section.

Current extract from 9.2.7
   SSH sessions resulting from a key exchange using
   diffie-hellman-group1-sha1 are secure even if private keying/
   authentication material is later revealed, but not if the session
   keys are revealed.  So, given this definition of PFS, SSH does have
   PFS.
Change to:
   SSH sessions resulting from a key exchange using
   diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1
   are secure even if private keying/
   authentication material is later revealed, but not if the session
   keys are revealed.  So, given this definition of PFS, SSH does have
   PFS.

---------------------
(6)
[ARCHITECTURE]  new section 9.2.8 (Security Considerations for TRANS)
A new section 9.2.8 will be needed to discuss the ordering of key
exchange method proposals. Currently, [TRANS] Section 7.1 states:
+++
kex_algorithms
   Key exchange algorithms were defined above. The first
   algorithm MUST be the preferred (and guessed) algorithm. If
   both sides make the same guess, that algorithm MUST be used.
   Otherwise, the following algorithm MUST be used to choose a key
   exchange method: iterate over client's kex algorithms, one at a
   time. Choose the first algorithm that satisfies the following
   conditions:
   + the server also supports the algorithm,
   + if the algorithm requires an encryption-capable host key,
   there is an encryption-capable algorithm on the server's
   server_host_key_algorithms that is also supported by the
   client, and
   + if the algorithm requires a signature-capable host key,
   there is a signature-capable algorithm on the server's
   server_host_key_algorithms that is also supported by the
   client.
   + If no algorithm satisfying all these conditions can be
   found, the connection fails, and both sides MUST disconnect.
+++
The proposed new section in [ARCH] will say:

   As stated in Section 7.1 of [TRANS], each device will send a list of
   preferred methods for key exchange.  The most-preferred method is the
   first in the list.  Implementations are free to determine their default
   preferences based upon relative cryptographic security, performance
   or other criteria.  If only the two methods defined in Section 8 of
   [TRANS] are are implemented, it is RECOMMENDED that
   diffie-hellman-group14-sha1 be listed before
   diffie-hellman-group1-sha1 in the kex list.

---------------------
Please send back your comments to this proposal.

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 21 Jun 2004 18:25:24 -0400

>    Two REQUIRED key exchange method has been defined:

"have"
Otherwise OK.

> [TRANSPORT] - revise section 8.1

OK.

> [TRANSPORT] - add section 8.2

OK.

> [NUMBERS] - Add a line in the current Section 4.3

OK.

>    keys are revealed.  So, given this definition of PFS, SSH does have

I guess this is OK, but I would still rather refer to TRANS section 8 in 
general, rather than to only the specific methods we happen to define.

  SSH sessions resulting from a key exchange using the diffie-hellman
  method described in [TRANS] Section 8 (including
  diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1) are
  secure even if private keying/authentication material is later
  revealed, but not if the session keys are revealed.  So, given this
  definition of PFS, SSH does have PFS.

> exchange method proposals.

I guess that text looks OK to me.  I've sort of become indifferent on this; 
I won't object strongly if people don't want to add this sort of text.

-- Jeff

---

From: [email-masked] (Niels Möller)
Date: 22 Jun 2004 11:39:07 +0200

> [TRANSPORT] - revise section 6.5

[...]

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

I'd say "are reserved for this purpose", if such text can go in this
document (rather than the numbers document). No need to be vague about
the reservation. 

> [TRANSPORT] - revise section 8.1

Ok.

> [TRANSPORT] - add section 8.2

Ok.

> 8.2 diffie-hellman-group14-sha1

Ok.

> [NUMBERS] - Add a line in the current Section 4.3

Ok.

> key exchange methods in this section.

Ok.

> [ARCHITECTURE]  new section 9.2.8 (Security Considerations for TRANS)

[...]

>    diffie-hellman-group1-sha1 in the kex list.

I can accept this writing, but I would still prefer that it either be
deleted, or be generalized to something like "if an implementation
doesn't have any other reason to preferring one algorithm over the
other, it's recommended to sort the algorithms by cryptographic
strength, strongest first", which applies to all algorithm lists, not
just the key exchange method.

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 24 Jun 2004 08:16:22 -0700 (PDT)

Hi,

> just the key exchange method.

also

On Tue, 22 Jun 2004, Jeffrey Hutzelman writes:

> I guess that text looks OK to me. I've sort of become indifferent on
> this; I won't object strongly if people don't want to add this sort of
> text.

So, it doesn't look like everyone is ready for a group hug on this one.
I'll make this alternate proposal for this section:

   As stated in Section 7.1 of [TRANS], each device will send a list of
   preferred methods for key exchange.  The most-preferred method is the
   first in the list.  Implementators are free to determine their default
   preferences.  If an implementation doesn't have any other reason to
   preferring one algorithm over the other, it is RECOMMENDED to sort the
   algorithms by cryptographic strength, strongest first.  Some additional
   guidance for this is given in BCP 86 [RFC 3766].
ftp://ftp.rfc-editor.org/in-notes/rfc3766.txt

I'll also find a spot to globalize that for all proposal lists.

I need to get some consensus on this so please vote for one of the
following:

A - Use this wording in a new section.
B - Use the old wording in a new section.
C - Delete the proposed new section.
D - [write-in your new proposal]

The default is "A".  If I don't hear from anyone, or if the votes received
don't give clear consensus, I'll go with that.

Thanks,
Chris

---

From: Damien Miller <[email-masked]>
Date: Thu, 24 Jun 2004 16:42:27 -0600

Chris Lonvick wrote:
> Hi,
> 
> On Tue, 22 Jun 2004, [iso-8859-1] Niels M?ller wrote:
> 
> 

I think this is too wordy. It is axiomatic that implementors can
determine their own preferences.

Perhaps this:

> first in the list. It is RECOMMENDED to sort
> the algorithms by cryptographic strength, strongest first. Some
> additional guidance for this is given in BCP 86 [RFC 3766].

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 25 Jun 2004 05:51:43 -0700 (PDT)

Hi,

> > additional guidance for this is given in BCP 86 [RFC 3766].

I'm OK with this.  I have one other vote for "A" but since this has the
essential gist of the thought I'll ask if anyone really opposes it.  If
not, I'll integrate those changes into the docs.

Just FYI,  I'm going to a part of west Texas next week where the Internet
doesn't reach.  I believe that there's also some strange localized
phenomena in the area which prevents computers from booting.  I'll pick
things up when I'm back.  :-)

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 25 Jun 2004 10:04:19 -0400

> not, I'll integrate those changes into the docs.

Works for me.