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

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> writes:

> [TRANSPORT] - revise section 8.1 (formerly titled
> "diffie-hellman-group1-sha1")

Looks ok.

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

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

This is the same for all algorithm names. It would make sense to
describe this name syntax in *one* place, and not repeat it several
times in the document. Besides from that nit, it looks ok to me.

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

Or just make it clear that diffie-hellman-group1-sha1 is an *example* of
a specified key exchange method that have PFS-properties.

> A new section 9.2.8 will be needed to discuss the ordering of key exchange
> method proposals.  Currently, [TRANS] Section 7.1 states:

I don't think this is needed at all. To me, the rules are the same as
for all the other algorithm lists: Each client lists the algorithms it
is willing to use, in the client's preferred order.

The client's preferences can be based on perceived relative strength,
or on cpu cost, or on explicit user configuration. It's totally up to
the client to decide.

The key exchange method is no different, in this respect, than the
host key algorithm list, encryption algorithm list and mac algorithm
list.

>    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.  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.  Implementors are
>    encouraged to review current literature to decide upon the order of any
>    other locally defined kex methods listed in the kex proposal.

"You can get this nice car in any color of your choice, as long as
your choice is black", or "You must put the algorithm you prefer
first, and you MUST prefer the one I say". It makes the word "prefer"
meaningless. 

I *strongly* object to having MUSTs and SHOULDs here. And I'd prefer
not having this section at all.

If we, now or in the future, really want to deprecate
diffie-hellman-group1-sha1, the right way to do that is to *formally*
deprecate it, by changing

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

to

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

in the appropriate document.

I don't want any semi-deprecated state that is is buried elsewhere in
the text, and in particular, the architecture document is *not* the
right place.

> - Parameterizing the kex namespace.

I see no need to do anything formal about that.

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

Don't change diffie-hellman-group1-sha1, it's too late. Also, a new
alias for the same thing is unnecessary and pointless.

> - Referencing DH-GEX.
> 
> If there is strong consensus from the WG that any of these issues really
> needs to be addressed, I will work on them.

I don't have any strong opinion on that. I don't think it's necessary;
the dh-gex spec seems to be the right place for recommending dh-gex.

Regards,
/Niels