Re: [Curdle] Genart last call review of draft-ietf-curdle-ssh-kex-sha2-14

["Mark D. Baushke" <[e-mail]>]

Hi Roni,

> Minor issues:
> It is not clear what is the backward interoperability is, I noticed
> that only rsa1024-sha1 is deprecated. It would be good to add some
> text maybe in section 4 that will explain it and maybe have some
> recommendations for client and server side.

The simple answer is that because a server and client always present a
list of possible key exchanges to be negotiated. The loss of one or two
should not cause any interoperability issues.

The inclusion of the original diffie-hellman-group14-sha1 key exchange
name somewhere in the list or the new "MUST"
diffie-hellman-group14-sha256 key exchange should guarantee that
interoperability will be maintained.

Background for the reviewer:

    The only Mandatory-to-Implement (MTI) Key Exchanges in any of the
    current set of standards are specified in RFC 4253 Section 6.5 are
    these:
    
       diffie-hellman-group1-sha1 REQUIRED
       diffie-hellman-group14-sha1 REQUIRED
    
    Additional key exchange methods may be added using the methods
    provided in RFC 4250.
    
    All of the other key exchange algorithms are provided in other RFCs
    are optionally added to the pool of possible key exchanges to be
    implemented.
    
    The existence of rsa1024-sha1 in RFC 4432 was not uniformly adopted
    by implementations of the secure shell and the mitigation has always
    been that the client and the server would offer the algorithms that
    they are willing to accept. In fact, there are only a handful of
    implementations supporting this key exchange.
    
    This RFC deprecates the original two MTI key exchanges by moving
    them from the "MUST" be implmeneted to "SHOULD NOT" and "MAY"
    respectively and promoting diffie-hellman-group14-sha256 to the only
    mandatory to implement algorithm.

Suggestion to the reviewer of replacement paragraphs before the table in
section 4 "Summary Guidance for Key Exchange Method Names Implementations"

    This RFC provides guidance to users and implementors as to which key
    exchanges are mandatory-to-implmement (MTI) -- MUST be implemented,
    as well as what current cryptographic key exchange methods SHOULD be
    implemented and MAY be implemented.

    The ordering of the default negotiation list is at the discretion of
    the implementor with the ability of the local adminitrator to
    configure the server in accordance with local policies and the users
    to configure the client with key exchanges that meet their needs.

    It is suggested that the MUST and SHOULD key exchange method names
    come in the preference list before the SHOULD NOT and MUST NOT
    names.

    It is suggested that SHOULD NOT and MUST NOT key exchange method
    names not be in the default negotation list provided by
    implementors, or that they be provided only at the very end of the
    negotation list.
    
    It is suggested that the MUST NOT key exchange method code be
    removed from the any implementations using them.

    The Implement column is the current recommendations of this RFC. Key
    Exchange Method Names are listed alphabetically. This is ordering is
    not intended to be the order used in either the server or client
    negotiation lists.


Please let me know if this addresses the issues raised. I wrote the
above rather quickly, so an editors touch to make it easier to read may
be desirable.

	Be safe, stay healthy,
	-- Mark