Subject: [Curdle] comments on draft-ietf-curdle-ssh-kex-sha2-05

From: Daniel Migault <[email-masked]>
Date: Sun, 26 Mar 2017 14:29:45 -0500

Hi,

Please find some comments of draft-ietf-curdle-ssh-kex-sha2-05.

Yours,
Daniel

I have the impression that only RFC4253 provided some recommendations, in
which case I would be incline to say that the current draft only updates
this document. The other RFC only defines new suites.

I suggest we either use MUST/SHOULD/MAY or REQUIRE/RECOMMEND/OPTIONAL but
not both. Note that if the recommendations for ipsec
[draft-ietf-ipsecme-rfc4307bis] we also introduced some additional notation
such as SHOULD+/- to specify whether the SHOULD is expect to raise its
status or that SHOULD is only here for interoperability.

Note that recommendations are not the purpose of IANA, so I would probably
change the title of the section. The IANA only adds the code points. It is
god that you mentioned the IANA link. I would encourage you to have the URL
as an informative  reference.

Recommendations should regularly updated so implementations have the time
to introduce new suites or remove old suites while still providing
interoperability. If the starting point is RFC4253, then we have:

      diffie-hellman-group1-sha1 REQUIRED
      diffie-hellman-group14-sha1 REQUIRED

and all other suites are OPTIONAL or MAY. Correct me if I am wrong, At
least I believe that that appendix section would be useful to comment on
the update with the previous recommendations.

       curve25519-sha256                    ssh-curves MUST

Maybe a MUST statement may be to strong as curves have just been defined.
Maybe that could be SHOULD+ mentioning it is expected to become a MUST next
time. In fact it is usually hard to move from MAY to MUST. If you do so,
reasons should be provided in the text. Currently it seems it is
implemented in libssh and OpenSSH, not sure it is sufficient for a MUST.

        curve448-sha512                      ssh-curves MAY
By default, the suites with MAY status are not mentioned.

        diffie-hellman-group-exchange-sha1   RFC4419    SHOULD NOT
SHA1 is probably at MUST NOT, so I am expected any suites to be MUST NOT.
Because it represents a threat you are likely to move to MUST NOT directly.

        diffie-hellman-group-exchange-sha256 RFC4419    MAY
        diffie-hellman-group1-sha1           RFC4253    SHOULD NOT
If group 1 is 768-bit MODP Group , I would consider there are two reasons
to have this as MUST NOT.

        diffie-hellman-group14-sha1          RFC4253    SHOULD
My understanding is that this one is kept for interoperability. However,
the text should make it clear this suite will be deprecated soon.

        diffie-hellman-group14-sha256        new-modp   MUST
        diffie-hellman-group15-sha512        new-modp   MAY
        diffie-hellman-group16-sha512        new-modp   SHOULD
        diffie-hellman-group17-sha512        new-modp   MAY
        diffie-hellman-group18-sha512        new-modp   MAY
        ecdh-sha2-nistp256                   RFC5656    SHOULD
        ecdh-sha2-nistp384                   RFC5656    SHOULD
        ecdh-sha2-nistp521                   RFC5656    SHOULD

The current trend is also to reduce the number of suites implementation. DO
we want to have these three suites as SHOULD. We should also explain what
the next step is expected to be.

        ecdh-sha2-*                          RFC5656    MAY
        ecmqv-sha2                           RFC5656    SHOULD NOT
        gss-gex-sha1-*                       RFC4462    SHOULD NOT
        gss-group1-sha1-*                    RFC4462    SHOULD NOT
        gss-group14-sha1-*                   RFC4462    SHOULD
        gss-group14-sha256-*                 new-modp   SHOULD
        gss-group15-sha512-*                 new-modp   MAY
        gss-group16-sha512-*                 new-modp   SHOULD
        gss-group17-sha512-*                 new-modp   MAY
        gss-group18-sha512-*                 new-modp   MAY
        gss-*                                RFC4462    MAY

        rsa1024-sha1                         RFC4432    SHOULD NOT
Maybe we could set it as MUST NOT both for key size and SHA1.

        rsa2048-sha256                       RFC4432    MAY

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 27 Mar 2017 01:28:54 -0700

> this document. The other RFC only defines new suites.

Good point. 

RFC 4353 itself suggests that additional key exchange method names will
be defined in RFC 4250, but no update to RFC 4250 has been issued.

I have changed to update="4353" and removed 4419, 4432, 4462, 5656 from
the list in my copy of the draft. I wonder if I need to add RFC4250 to
the update list instead of or in addition to 4353? Comments?

> not both. 

I favor MUST/SHOULD/MAY. If you notice any REQUIRE/RECOMMEND/OPTIONAL in
the updated draft, it should be corrected before it goes to final call.

> Note that if the recommendations for ipsec
> [draft-ietf-ipsecme-rfc4307bis] we also introduced some additional
> notation such as SHOULD+/- to specify whether the SHOULD is expect to
> raise its status or that SHOULD is only here for interoperability.

Sure, I can add a section for SHOULD+ and SHOULD- borrowing from that
draft.

> Note that recommendations are not the purpose of IANA, so I would
> probably change the title of the section.

Okay. "Guidance for Key Exchange Method Names" ?

> The IANA only adds the code points. It is god that you mentioned the
> IANA link. I would encourage you to have the URL as an informative
> reference.

Point taken. I have made the change.

> Recommendations should regularly updated so implementations have the
> time to introduce new suites or remove old suites while still
> providing interoperability. If the starting point is RFC4253, then we
> have:
> 

You are not wrong, but RFC 4253 does point to 4250 (SSH-NUMBERS)
for the official Key Exchange Method Names list in section 4.10.

Hmmm... I suppose I need to revisit the Overview and Rational section
and partition some of the choices into an appendix ?

The diffie-hellman-group1-sha1 uses the RFC2409 Oakley Group 2 1024-bit
MODP group prime P, with generator G=2, Q=(p-1)/2. This RFC will
recomment MUST NOT for this key exchange method name.

The diffie-hellman-group14-sha1 will be moved to SHOULD- primarily
because the sha1 is a way to allow transitional implementation overlap.

>        curve25519-sha256                    ssh-curves MUST

I believe this to be a SHOULD+ algorithm.

> By default, the suites with MAY status are not mentioned.

Okay, I will update the list..

> Because it represents a threat you are likely to move to MUST NOT directly.

Reasonable.

> to have this as MUST NOT.

The diffie-hellman-group1-sha1 is a 1024-bit MODP prime (the Oakely 
Group 2). I agree MUST NOT is better.

> the text should make it clear this suite will be deprecated soon.

Agreed. It is now a SHOULD-

> The current trend is also to reduce the number of suites
> implementation. DO we want to have these three suites as SHOULD. We
> should also explain what the next step is expected to be.

Okay. I think this makes more sense:

>         ecdh-sha2-nistp256                   RFC5656    SHOULD-
>         ecdh-sha2-nistp384                   RFC5656    SHOULD+

The idea being that a number of standards want ECDH/ECDSA and the
CNSA-SUITE only approves of nistp384.

That said there do exist constant-time impleemntations of SHA2-256 and
at least a few non-constant time SHA2-384. A user "SHOULD" implement at
least one ECDH hashing algorithm, but it is not clear that there is much
choice yet. So, both may be needed.

> Maybe we could set it as MUST NOT both for key size and SHA1.

Agreed.

>         rsa2048-sha256                       RFC4432    MAY

	-- Mark