Subject: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-gss-keyex-sha2-09: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 20:41:44 -0700

Adam Roach has entered the following ballot position for
draft-ietf-curdle-gss-keyex-sha2-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who invested work in this document.

I support Alissa's discuss, especially in light of RFC 2743 being an IETF-stream
document.

---------------------------------------------------------------------------

§1:

>  SSH GSS-API Methods [RFC4462] allows the use of GSSAPI for
>  authentication and key exchange in SSH.

It seems that RFC 2743 needs to be included as a normative reference for
GSSAPI here.

---------------------------------------------------------------------------

§4:

>  Base64 encoding is described in
>  Section 6.8 of [RFC2045].

For uses outside of MIME, RFC 4648 is far more conventional to cite. You want to
point to section 4.

---------------------------------------------------------------------------

§5:

>  Additionally we utilize also the curves defined in
>  [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined

Nit: "NIST-defined"

---------------------------------------------------------------------------

§5.1:

>  Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 perform the
>  Diffie-Helman protocol using the functions X25519 and X448,
>  respectively.  Implementations SHOULD compute these functions using
>  the algorithms described in [RFC7748].

I don't usually quibble of "SHOULD" versus "MUST," but it seems that any
implementation that doesn't heed this "SHOULD" simply won't interoperate. Unless
I'm completely misunderstanding how Diffie-Helman works, it seems that
this needs to be a "MUST" (or, in extremis, "MUST compute these functions using
the algorithms described in [RFC7748] or functionally equivalent algorithms.")

---------------------------------------------------------------------------

§5.1:

>  For NIST Curves the keys use the uncompressed point representation
>  and must be converted using the algorithm in Section 2.3.4 of
>  [SEC1v2].

"must" or "MUST"?

---------------------------------------------------------------------------

§5.1:

>  To verify the integrity of the handshake, peers use the Hash Function
>  defined by the selected Key Exchange method to calculate H:
>
>  H = hash(V_C || V_S || I_C || I_S || K_S || Q_C || Q_S || K).

Please indicate that these variables and the "||" operator will be described
later in this section.

---------------------------------------------------------------------------

§5.1:

>  The server may responds with:

Nit: "...may respond with:"

---------------------------------------------------------------------------