On Oct 26, 2012, at 10:32 PM, Black, David wrote: > Paul Hoffman wrote: >>> You may be overstating that "many people" agree that it is worth doing, >>> but it is certainly worth discussing. > > I'm definitely interested in that discussion, as I'm in the midst of > an update to the IPsec requirements for iSCSI.
Me too (interested in that discussion, not updating an iSCSI document) > David McGrew wrote: >> The issue is that 3DES has a 64-bit block instead of a 128-bit block; >> please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In >> retrospect, there should have been a citation in the draft.) > > That suggests that an explanation of the birthday bound concern > along with a discussion of transmission rate and rekeying concerns > would be appropriate for the ESP and AH requirements draft, as > opposed to a blanket "SHOULD NOT" statement for 3DES. > > A 1 Gbit/sec link running encrypted at line rate can get to the 4 > Gigabyte birthday bound stated in the cfrg draft fairly quickly, but > a much slower throughput rate may take much longer before rekeying > becomes necessary, if ever (e.g., a remote access session's entire > traffic may be measured in 10s of Megabytes or less). > > Aside - there may be a math error in the draft. > For a block size (w) of 64 (i.e., 2^6): > > - w * 2^(w/2) bits = 2^6 * 2^32 bits = 2^38 bits > - 2^38 bits is 2^35 bytes (byte contains 8=2^3 bits) > - 2^35 bytes is 2^5 gigabytes (gigabyte contains 2^30 bits). > > That would be 32 gigabytes, but this aside doesn't change the > above discussion, as a 1 Gbit/sec rate will get there in a few > minutes, and a 10 Gbit/sec rate will get there in under a minute. > Moreover the draft warns (with good reason) that getting close > to the birthday bound is not a good idea. The minutes figure is enough to not warrant a SHOULD NOT. Any machine that's capable of sustained 1 Gb/s IPsec should also be capable of rekeying child SAs every minute. In fact, our QA people regularly run a load like that with 1-minute lifetimes for a week just to check if anything bad happens. So it might be appropriate to say how often you need to rekey with the various algorithms, and it may be correct to say that for extreme cases (a single SA that carries 10 Gb/s sustained rate) 3DES is not appropriate, but this is a far cry from a blanket SHOULD NOT. I have another issue with this recommendation. It leaves only AES variants as MUST and SHOULD. I would like to have some other algorithm widely implemented, so that if we get some really bad (or good - depends on your perspective) cryptographic result against AES, there is something interoperable to fall back on. As long as we don't have a new algorithm, I'd rather see 3DES remain a SHOULD. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
