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

["Mark D. Baushke" <[e-mail]>]

Daniel Migault <[e-mail]> writes:

> 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.

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?

> I suggest we either use MUST/SHOULD/MAY or REQUIRE/RECOMMEND/OPTIONAL but
> 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:
> 
>       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.

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.

> 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.

Okay, I will update the list..

>         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.

Reasonable.


>         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.

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

>         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.

Agreed. It is now a SHOULD-

>         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.

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.


>         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.

Agreed.

>         rsa2048-sha256                       RFC4432    MAY

	-- Mark