Hi Rene,
I have tried to address all of your comments below.
Rene Struik <rstruik.ext@xxxxxxxxx> writes:
> 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?
MDB:
As the draft author, my original intention was to move all of the *-sha1
key exchanges to either deprecated or disallowed. In RFC keyword terms,
this is SHOULD NOT or MUST NOT. If you look at Table 6, the only one
that was missed was the former "MUST" algorithm
"diffie-hellman-group14-sha1" which has been moved from "MUST" by
RFC4253 to "MAY by this draft.
The WG consensus was that this "MAY" allows for a transition period to
the new "MUST", "SHOULD", and "MAY" guidelines for key exchange methods.
> - 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?
MDB:
I can add it if it is desired by the community. Or, I could remove any
mention of SHA-224 if that would make the community happier.
I will note that RFC5656 section 6.3 mandates that ecdh-sha2-nistp384
use SHA-384 which is why there is no similar language for that hashing
algorithm.
> - 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}.
MDB:
I do say 'approximately 128 bits' in the text. I could add the word
'approximately' to the table if that is needed for consistency.
Do you have an informative reference for Curve448 being at 223 bits of
security rather than 224 bits? If so, I could add it to the
informational references and update the table.
> - 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?
MDB:
I thought the section 3.2.2 text was clear that the key exchange method
names were those found in RFC8731.
Section 3.2.2 specifies curve25519-sha256 for two reasons:
a) it is a direct documentation of curve25519-sha256@xxxxxxxxxx which
is deployed in many SSH implementations and is documented in
RFC8731.
b) SHA-3 implementation were not as widely deployed as SHA-2 when the
curve25519-sha256@xxxxxxxxxx implementation was created.
If you have any suggestions for how to make section 3.2.2 clearer, I
have no pblems with updating the section with such a consideration to
help readers of the RFC.
> - 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).
MDB:
Yes, and it is only FFC group14 which already in fielded implementations
due to RFC4253 mandating it (for use with SHA-1). The only change was to
move from SHA-1 to SHA256. This was considered to be a simple code
change as compared to trying to add EC to implementations that do not
have it and are not interested in implementing it.
> 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)?
MDB:
The nudge I used was marking them as "SHOULD" ... I was unable to get
consensus on MUST for any of the EC key exchange methods.
That said, there are again two plausible reasons for this:
a) In a Post Quantum Cryptography (PQC) world (which I do not expect to
happen in my lifetime), it is easier to break EC than FFC because EC
uses fewer bits.
b) If you look at the archives, you will find a number of implementors
refuse to consider a move to EC key exchanges at all.
So, one reason is technical and one reason is mistrust of EC... or maybe
they are both anxious about PQC.
I feel happy I was able to make rsa1024-sha1 a MUST NOT as there are
still a lot of folks that enjoy using RSA. and I would have no problems
if rsa2048-sha256 were removed due to a lack of perfect forward
security.
> - (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?
MDB:
Given the key exchange method names are sent in the clear of the fixed
sized prime fields for FFC and curves for EC and key size for RSA, I am
unclear on your point. There is not really anything secret about the
sizes of these crypto variables.
If you are talking about mpint for other parts of the SSH protocol, then
that may be worth a larger discussion.
> 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.])
MDB:
At this time, the CURves, Deprecating and a Little more Encryption
(curdle) working group is winding down. I believe that the this draft is
the second to the last one for the WG. (The only one still waiting is
draft-kampanakis-curdle-pq-ssh-00)
I would suggest that the ietf SSH working group would need to be
restarted if there was going to be a design update to move from SSHv2 to
SSHv3. However, that is just my opinion.
> Best regards, Rene
>
I hope that my answers have addressed your questions and concerns and
look forward to any suggested textual changes to make the document
better.
...elided the rest of the message...
Be safe, stay healthy,
-- Mark
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
