Re: [Curdle] Multiple WGLC

[Peter Gutmann <[e-mail]>]

Daniel Migault <[e-mail]> writes:

>This emails starts a WGLC on the following drafts:
>
>    - draft-ietf-curdle-rsa-sha2-03 [1]
>    - draft-ietf-curdle-ssh-ext-info-02 [2]
>    - draft-ietf-curdle-ssh-kex-sha2-05 [3]
>    - draft-ietf-curdle-ssh-modp-dh-sha2-02 [4]
>
>Please provide your comments by March 28 on the mailing list. 

draft-ietf-curdle-ssh-modp-dh-sha2-02:

Section 5, "Many users seem to be interested in the perceived safety of using
larger MODP groups and hashing with SHA2-based algorithms", should that text
be there?  It seems rather out of place, orphaned between Figure 2 and the
References section.

draft-ietf-curdle-ssh-ext-info-02.txt:

Section 2.3, "This message is sent without delay", I'm not really sure what to
do with this requirement, why would there be a delay, necessitating a need to
say that it's sent without delay?

Section 2.3: "and immediately after SSH_MSG_NEWKEYS", whose NEWKEYs?  Logic
would seem to indicate that it's after both sending and receiving NEWKEYs to
confirm that the connection is secured, but the text is ambiguous.

Section 2.4: "If the client sent "ext-info-c", the server MAY send, but is not
obligated to send, an SSH_MSG_EXT_INFO message immediately before
SSH_MSG_USERAUTH_SUCCESS, as defined in [RFC4252]", I've already commented on
this before, this just seems weird, the client sends its
SSH_MSG_USERAUTH_REQUEST and instead of getting back SSH_MSG_USERAUTH_SUCCESS
or SSH_MSG_USERAUTH_FAILURE it gets this odd out-of-place extension message
packed in front of the success/failure indication that it's actually
interested in.

Section 3.1, "a client SHALL NOT", given that the rest of the document uses
MUST or SHOULD it'd be better to use that form as well here to save people
having to look up whether MUST or SHOULD is intended.

Section 3.2, "Former versions of this document defined extensions with names
enumerated in this heading. These proposals are removed due to current lack of
implementation", isn't that an oxymoron?  If it's not in a published RFC,
people will be reluctant to implement it, or enable it if it's implemented.
I'm certainly ready to go with "no-flow-control", but haven't enabled it
because I don't know what'll change, or break, before the spec is finalised.

Peter.