Re: [Curdle] Last Call: <draft-ietf-curdle-ssh-kex-sha2-14.txt> (Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)) to Proposed Standard

Dear colleagues:

I did have a brief look at this draft and have the following (small) 
comments:

Draft: draft-ietf-curdle-ssh-kex-sha2-14

Comments:
- the document seems to take a half-hearted stance on deprecating the 
use of SHA1. Why not simply strike all key exchange methods that use it 
off Table 6 altogether?
- in Section 1.1 (p. 3, forelast para), it is suggested to not use 
SHA-224 since it has the same compression function as SHA-256 (and only 
differs from it by the initialization vector and truncation in the end). 
Shouldn't one add similar language for SHA-384 vs. SHA-512?
- in Section 1.2.1, the bit security of Curve25519 and Curve448 is 
somewhat smaller than stated (126-bit and 223-bit) {although perhaps not 
that important a change}.
- in Section 3.2.2, I am somewhat puzzled by the suggested use of 
Curve448 with SHA512, since RFC8709 introduces Ed448 (which uses a 
4-isogenous curve Edwards448 to Curve448, but which uses SHAKE256/d=914 
internally). Why not align the underlying hash functions, so that 
implementations with this curve would be able to use a single hash 
function implementation?
- in Section 3.3, I am wondering about the underlying philosophy of 
still aiming for implementation of ordinary discrete log groups (Note: 
it is the only method with a MUST). Shouldn't one give a nudge towards 
implementing elliptic curve-based methods (which all have a MAY or 
SHOULD only). It seems more appropriate to switch this order and label 
DLP groups as MAY at most (if sufficiently large)?
- (not really in this document, but I thought to ask nevertheless) some 
representations, such as "mpint", do not seem to be such a smart choice 
any more, since variable-size encodings may leak info on secret 
parameters in crypto processing. Is there any reason this still, in 
2021, should be kept as is?

I do realize that not all these comments are directly fixable with this 
draft (e.g., the last one). However, it makes me wonder whether it may 
be time for a more general design update of ssh-related protocols? (in 
my mind, crypto agility should have a complement in general design 
agility... [even if one would just only get rid of mpint etc.])

Best regards, Rene

On 2021-02-10 11:59 a.m., The IESG wrote:
> The IESG has received a request from the CURves, Deprecating and a Little
> more Encryption WG (curdle) to consider the following document: - 'Key
> Exchange (KEX) Method Updates and Recommendations for Secure Shell
>     (SSH)'
>    <draft-ietf-curdle-ssh-kex-sha2-14.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-call@ietf.org mailing lists by 2021-02-24. Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document is intended to update the recommended set of key
>     exchange methods for use in the Secure Shell (SSH) protocol to meet
>     evolving needs for stronger security.  This document updates RFC
>     4250, RFC 4253, RFC 4432, and RFC 4462.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867