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

[Martin Duke <[e-mail]>]

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) <[e-mail]>
wrote:

> Hi Martin,
>
> Comment in-line below.
>
> > On Jul 6, 2021, at 11:48 AM, Martin Duke via Datatracker <
> [e-mail]> wrote:
> >
> > 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
>
> Agreed.
>
> >
> > 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?
>
> 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
>
>
>
>