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@xxxxxxxx mailing lists by 2021-02-24. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
--
email: rstruik.ext@xxxxxxxxx | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
