Hi Mark:
Brief feedback below..
Rene
On 2021-02-24 9:12 p.m., Mark D.
Baushke wrote:
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.
RS>> Please note that IACR awarded the "test of time" award
(see https://www.iacr.org/testoftime/) (after 15
years) to
From Crypto 2005: Finding collisions in the full
SHA-1 , by Xiaoyun Wang, Yiqun Lisa Yin and
Hongbo Yu For a breakthrough in
the cryptanalysis of hash functions.
If people after 15 years still need time, crypto agility seems to be a dead letter. Besides, RFCs are not laws: implementors always have the option to ignore/reject whatever IETF produces. By stipulating MUST NOT one at least forces implementers to justify themselves. {In my mind, most security flaws are caused by sloppy implementors, which gives everyone else also a bad name.}
<<RS
RS>> okay. <<RS- 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.
RS>> As already said, perhaps not that important. (bit-security is usually phrased as (1/2)*log2(n), rounded to an integer, where n is the order of the largest prime-order subgroup.) <<RS- 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.
RS>> I simply wanted to suggest that specifications should aim for lowering implementation cost, unless there are very strong reasons for not doing so. BTW - my comment was about different hash functions used with Curve448 and Ed448, not about curve25519. If one can write code for Ed448 (which enforces the use of SHAKE256/d=914), why can't the key exchange method do a call to that hash function with the key derivation function? It is somewhat disturbing that one simply copies what a single library does... <<RS- 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.
RS>> If this is indeed a "plausible" motivation, this should perhaps be mentioned in the draft. It is unclear, though, whether the "easier to break" statement actually holds, at least in common usage of FFC with a "safe" prime p=2q+1, where one uses a much shorter private key (of bit length similar to ECC bit length), e.g., prime p is 2048 bits and private key is 224 bits. To my knowledge, a careful analysis of quantum algorithms for this scenario have not been reported on in the literature, but this may very well turn out to be solvable with an adaptation of the "order finding problem". BTW - I do not expect it would be easy to entice researchers to work on this problem, since it is much easier to defend spending time on more prevalent algorithms. <<RS- 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.
RS>> Again, implementors are free to ignore what is written in
RFCs, but mistrust does not necessarily have to guide IETF
recommendations. Considering that "sha1" apparently still has to be
supported somewhat "to allow more time", wouldn't it be plausible
that people are simply resistant to any change, period? Personally,
I think the PQC argument is an argument of convenience, while
implementation attacks are a clear and present danger and quite easy
to carry out for FFC groups (but consistently ignored when drawing
up algorithm tables). Hence, my suggestion to still nudge people in
the (considered by most) right direction. <<RSI 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.
RS>> A concrete example of such an attack is a timing
attack, where one exploits that the hash function used for key
derivation may not run in constant time if the input size is not
fixed-size. This could potentially be the case when the shared key
K is encoded using mpint (where, e..g., if the leftmost bit of K
is one, one prepends an all-zero byte). For a simple attack in the
case of FFC groups (hence, my nudge remark), see, e.g.:
Side Channel Analysis - Raccoon Attack, Exploiting MSB-Oracles in TLS-DHE, hnp (Robert Merget, Marcus Brinkmann, Nimrod Aviram, Juraj Somorovsky, Johannes Mittmann, Jorg Schwenk, IACR ePrint 2020-1151)
https://eprint.iacr.org/2020/1151
<<RS
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, ReneI 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
-- 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
