Hi Rene, Picking just a couple points... On Thu, Feb 25, 2021 at 10:39:24AM -0500, Rene Struik wrote: > > On 2021-02-24 9:12 p.m., Mark D. Baushke wrote: > > > > 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<https://doi.org/10.1007/11535218_2>, 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/ The "transition period" is not about time per se, as much as transitioning an algorithm from "MUST implement" to "MUST NOT implement", with no algorithms guaranteed to be available in "old" implementations that would interoperate with "new" implementations. Yes, we should have published a document to deprecate the SHA-1 algorithms many years ago; we didn't. As far as I can tell the best path forward is to publish something like this now and come back in a year or two to finish the transition to "MUST NOT". Recall that continuing to debate will leave SHA-1 as "MUST implement"! > >> - 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>> 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 Note that curve448-sha512 was already specified in RFC 8731, so it is too late to change anything about it. I'll echo others' thanks for the feedback; the extra review is appreciated. -Ben -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
