Subject: [Curdle] Martin Duke's No Objection on draft-ietf-curdle-ssh-kex-sha2-19: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Tue, 06 Jul 2021 11:48:19 -0700

Martin Duke has entered the following ballot position for
draft-ietf-curdle-ssh-kex-sha2-19: 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 DISCUSS and COMMENT positions.

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

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

Two nits:

(1.1) this is optional, but

s/man in the middle/on-path attacker

Or other suitable synonym

(3.1.1) and (3.1.2) I cannot parse the sentences with the phrase "is a
reasonable hash...", e.g.

SHA2-256 is a reasonable hash in both the KDF and integrity in both gss and
non-gss uses of curve25519 key exchange methods.

Can you reword?

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 6 Jul 2021 17:32:44 -0700

> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

I had asked about this as well.  My current understanding is that
"integrity" is something of a term of art for ssh.  Roughly, there's a
transcript hash of the SSH handshake that's used as session identifier as
well as input to the key schedule, and this provides integrity protection
for the key exchange.  As a result, I don't have much of a position for
whether we should reword this.

-Ben

---

From: mbaushke ietf <[email-masked]>
Date: Thu, 8 Jul 2021 14:33:14 -0700

> On Jul 6, 2021, at 5:32 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Ben is correct.

This is the best wording I could find that does not dive down the rabbit hole of implementation details.

The policy discussion of integrity of SSH is found in RFC 4251.

The details of key exchange integrity may be found in section 7 "Key Exchange" and section 7.2 "Output of Key Exchange" of RFC 4253.

If anyone has better wording, please let me know.

        Be safe, stay healthy,
        -- Mark

---

From: "Mark Baushke (ietf)" <[email-masked]>
Date: Sat, 17 Jul 2021 06:43:19 -0700

Hi Martin,

Comment in-line below.

> On Jul 6, 2021, at 11:48 AM, Martin Duke via Datatracker <[email-masked]> wrote:
> 

Agreed.

> non-gss uses of curve25519 key exchange methods.

Benjamin Kaduk already answered your question, but I do not know if it was satisfying or if the document should be updated.

I could add the following paragraph to section 3.1.

        RFC4253 section 7.2 "Output of Key Exchange" defines
        generation of a shared secret K (really the output of the KDF)
        and an exchange key hash H. Each key exchange method uses a
        specified HASH function which must be the same for both key
        exchange and Key Derivation. H is used for key exchange
        integrity across the SSH session as it is computed only once.
        It is noted at the end of the 7.2 section that "This process
        will lose entropy if the amount of entropy in K is larger than
        the internal state size of HASH." so care must be taken that
        the hashing algorithm used is well chosen ("reasonable") for
        the key exchange algorithms being used.

Please let me know if adding something like that will improve what 3.1.1 and 3.1.2 are trying to say.

        Be safe, stay healthy
        -- Mark

---

From: Martin Duke <[email-masked]>
Date: Mon, 19 Jul 2021 07:36:48 -0700

I'm not going to say no to more explanation, but my complaint is much more
pedestrian than that: the sentence structure makes it hard to figure out
what you're talking about. Breaking it down

SHA2-256 is a reasonable hash  // your new paragraph explains what
"reasonable" means, though I was fine with that bt

in both the KDF and integrity // I think you mean "for use in the both KDF
and integrity".
// but also "the integrity" sounds very odd to my ears; do you mean "the
integrity verification", or is "the integrity" a term of art?

in both gss and non-gss uses of curve25519 key exchange methods. // is this
modifying 'integrity' or a reasonable hash.

Here's a proposed rewording written with no understanding of the underlying
tech:
"SHA2-256 is a reasonable hash for use in both the KDF and integrity check.
It is reasonable for both gss and non-gss uses of curve25519 key exchange
methods."

Martin

On Sat, Jul 17, 2021 at 6:43 AM Mark Baushke (ietf) <[email-masked]>
wrote:

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> Benjamin Kaduk already answered your question, but I do not know if it was
> satisfying or if the document should be updated.
>

---

From: Mark Baushke <[email-masked]>
Date: Mon, 19 Jul 2021 19:59:23 -0700

Hi Martin,

> On Jul 19, 2021, at 7:36 AM, Martin Duke <[email-masked]> wrote:
> 
> SHA2-256 is a reasonable hash for use in both the KDF and integrity check. It is reasonable for both gss and non-gss uses of curve25519 key exchange methods.

Ah. I think I understand your confusion. That said, it is not an integrity check, rather it is a way of ensuring that the session integrity is maintained across many different rekeying events. As such, something like this may be closer to what you want:

            SHA2-256 is a reasonable hash for use in both the KDF and
            session integrity. It is reasonable for both gss and
            non-gss uses of curve25519 key exchange methods.

A similar paragraph is provided for the SHA2-512 hash.

        Be safe, stay healthy
        -- Mark

---

From: Martin Duke <[email-masked]>
Date: Mon, 19 Jul 2021 20:34:41 -0700

Yes, that scratches my itch

On Mon, Jul 19, 2021, 19:59 Mark Baushke <[email-masked]> wrote:

> SHA2-256 is a reasonable hash for use in both the KDF and integrity check.
> methods.
> Ah. I think I understand your confusion. That said, it is not an integrity
> check, rather it is a way of ensuring that the session integrity is
> maintained across many different rekeying events. As such, something like
> this may be closer to what you want:
>