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

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

On Tuesday, June 15, 2004 08:53:54 -0700 Chris Lonvick <clonvick%cisco.com@localhost> 
wrote:

> Hi Folks,
>
> From all of the notes on this subject, it looks like we may have some
> consensus on how to address this issue.  Many thanks to everyone who
> partifipated in this discussion; it helps to move us forward.  I believe
> that this is going to require edits to 4 places in the documents.
>
>
> [TRANSPORT] - revise section 8.1 (formerly titled
> "diffie-hellman-group1-sha1")
>
> 8.1 Required Key Exchange Methods
>
>    Two methods for key exchange are defined in this document.
>
>    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.
>
>    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.


I don't like the section name.
Structurally, this section isn't about defining required methods; it's 
about defining some specific methods that build on the functional 
description in the section before.  IMHO this would work better with 
separate sections 8.1 and 8.2, defining diffie-hellman-group1-sha1 and 
diffie-hellman-group14-sha1, resepectively.


In any case, the new method needs to be listed in section 6.5, "Key 
Exchange Methods".



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

Fine.

> [ARCHITECTURE]  (2 changes needed)
>
> (1)
> Section 9.2.7 discusses Forward Secrecy and PFS, and it specifically names
> diffie-hellman-group1-sha1.  This can be changed to "the key exchange
> methods described in Section 8.1 in [TRANS]".

Make it section 8.  Really, the statement applies to anything built on that 
general description, including new methods that may be defined in the 
future with different groups or hashes.


> (2)
> 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
>    methods for key exchange.  The preferred method will be the first in
>    the list.  The preferred method SHOULD be the cryptographically
>    strongest method, and the method most likely to satisfy the conditions
>    stated in that section.

The conditions are all about negotiating a method which both sides support. 
The only way to choose an order such that the preferred method is "likely 
to satisfy" these conditions is to choose one that you think the peer 
supports, and for which there is a suitable host key algorithm that you 
think the peer supports.  That would imply either waiting for the other 
side's KEXINIT message (both sides can't do this, and neither should), or 
making guesses based on the version string.

I propose dropping everything after the last comma.


>  Of the two methods defined in Section 8.1 of
>    [TRANS], diffie-hellman-group14-sha1 MUST be listed before
>    diffie-hellman-group1-sha1 in the kex list.

I don't think we have concensus for this requirement.



> - Parameterizing the kex namespace.

I don't feel real strongly about this one way or the other.  I don't think 
we have agreement to do it yet, and I'm not sure how important it is.


> - Using SSH"group1" when we mean IKE"group2".  From what I understand,
> making changes to this would have interoperability ramifications to the
> deployed products.

Yeah; it would suck.


> - Referencing DH-GEX.

I don't think this needs to be much more than a line in section 6.5 of the 
transport draft listing diffie-hellman-group-exchange-sha1 as a RECOMMENDED 
method, plus a mention somewhere in section 9.2 of the architecture draft.

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