Generic Security Service Application Program Interface (GSS-API) Key Exchange with SHA-2
draft-ietf-curdle-gss-keyex-sha2-10

** Section 5.1, Per “The exchange hash SHOULD be kept secret”, when should it not be (i.e., why isn’t this a MUST?)?

Editorial Items:
** Section 2.  Provide a reference to X25519 and X448 Curves

** Section 3.  Typo.  s/>RFC2119/RFC2119/

** Section 4.  Editorial.  The sentence “The following new key exchange …” is indented.

** Section 4 and 5.2.  Per “Each key exchange method id implicitly registered by this document”, aren’t these key exchange methods explicitly registering them in IANA-KEX-NAMES per Section 7?

** Section 4.  Explicitly name, number and reference the table in the text

** Section 4.  Typo.  s/refences/references/

** Section 5.  Editorial. s/Additionally we utilize also/Additionally, we also utilize/

** Section 5.  Editorial.  s/3 classic/three classic/

** Section 5.1.  It is worth repeating (or moving the text) to Section 8 that the Security Considerations of RFC7546 apply

** Section 5.1.  Typo.  s/trasmitted/transmitted/

** Section 5.1. Typo.  s/estalishment/establishment/

** Section 5.1.  The various variable (e.g., V_C, V_S) are introduced early in the algorithm to construct H and the messages in page 6, but they aren’t described until the end of page 7.  I wasn’t following the narrative until I hit that section.

** Section 5.2.  Explicitly number the table and reference it in the text.

** Section 5.2.  Typo.  s/refences/references/

** Section 6.  This section references a table.  Explicitly name and number that table.

Thank you for for writing this - it was clear enough that I could understand the bits that I needed to :-)

I have a few comments:
"Additionally we utilize also the curves defined in [I-D.ietf-curdle-ssh-curves] to complement the 3 classic NIST defined curves required by [RFC5656]."
I checked on the status of I-D.ietf-curdle-ssh-curves - this seems to have stalled. I realize it isn't your problem, but is there a plan to progress I-D.ietf-curdle-ssh-curves ?

"The parties generate each an ephemeral key pair, according to ..."
I think that this would be easier to understand as: "The parties each generate an ephemeral key pair, according to ..."

Like Alissa, I am puzzled by having the IESG owning key exchange methods.

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:"

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

Thank you for addressing my DISCUSS.

-- Section 2 --

   we propose the use of the SHA-2 [RFC6234] based hashes

Two nits here: first, the second "the" seems odd.  Second, "SHA-2-based hashes" needs to be hyphenated, which makes the double hyphen odd and moves the citation.  I suggest, "we propose the use of hashes based on SHA-2 [RFC6234]".

-- Section 4 (and also 5.2) --

   Each key exchange method is implicitly registered by this document.

The registration is not implicit; it's explicit in Section 7.  I suggest removing "implicitly".

-- Section 8.3 --
Nits: "Some mechanisms implementations" should be "Some mechanism implementations", "(like commonly used krb5 libraries)" should be "(such as commonly used krb5 libraries)", and "may results" should be "may result".

Support Alissa's Discuss.

I support Alissa's discuss as I also don't understand what that means, however, I hope that's easy to resolve.

* Section 8.3

I think a pointer to DNSSEC might be relevant here in the context of spoofed DNS responses.