Hi Tero I've no issues per se with this, but as per our chat in London, most VPN consumers pick the group with the highest number (of course group24 is more secure than group21, 24 is bigger than 21 ...!)..
Maybe some words of warning around potential performance impact. I’m sure someone somewhere in the world will want this.. I feel for the poor vendors support desk "dear customer, I know you enabled group38 (RSA 16384) and now your 5000 device full mesh solution is not converging as quickly as it did before..".. cheers On 17/07/2018, 16:16, "IPsec on behalf of Tero Kivinen" <[email protected] on behalf of [email protected]> wrote: When we greated RFC3526 [1] in 2003 we included 1536, 2048, 3072, 4096, 6144, and 8192 bit modp groups. I did also create 12288 and 16384 bit modp groups [2], but we did not include those as we assumed they would be too slow for normal use. Now sometimes there is requirement to align all security parameters with AES-256 also (because AES-128 is not enough if someone gets quantum computers some day). SP800-57 part 1 rev 4 [3] has table 2 that says: Security Symmetric FCC IFC ECC Strength key (e.g. DSA, (e.g., (e.g., algorithms D-H) RSA) ECDSA) <=80 2TDEA L=1024, N=160 k=1024 f=160-233 112 3TDEA L=2048, N=224 k=2048 f=224-255 128 AES-128 L=3072, N=256 k=3072 f=256-383 192 AES-192 L=7680, N=384 k=7680 f=384-511 256 AES-256 L=15360, N=512 k=15360 f=512+ Meaning that we do not have any MODP groups with IANA numbers that would match AES-256. For vendor to add elliptic curve support to simply be able to mark that tick mark saying we do support AES-256 is bit much. Adding 16384 bit MODP group is much faster and easier, and nobody does not need to use it (I think the recommended group in NIST documents is still the 2048 bit group). NIST SP 800-56A Rev 3 [4] aligns with this and says that MODP-8192 is for less than 200 bits of security, i.e., not enough for AES-256. In the SP 800-56B rev2 draft [5], there is formula in Appendix D, which allows you to calculate the strength for different bit lengths and if you plug in the 15360 you get 264 bits. To get 256 bits of maximum strength the nBits needs to be between 14446-14993. 15000 would already give you 264, i.e., the same than 15360 gives. 15360 is of course 1024*15 so it is nice round number in binary. If you plug in 12288 to that formula you get strength of 240 and 16384 gives you 272. Checking old performance numbers I can see that in 2008 the speed of 6144 group was same as 16384 is with current machines, which most likely matched what 2048 or 3072 bit group speed was in 2003 (i.e. about half a second per full Diffie-Hellman). So my question is do other people think it would be useful to allocate IANA numbers for the 12288 and 16384 bit MODP groups? You can of course use private numbers, but I myself think it would be good idea to have IANA numbers for those groups too, just in case someone wants interoperability with them at some point. Also we do not yet know how quantum computers are going to do for different algorithms, i.e., whether P-521 is harder or easier than MODP 16384. [1] https://datatracker.ietf.org/doc/rfc3526/ [2] https://kivinen.iki.fi/primes/ [3] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf [4] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf [5] https://csrc.nist.gov/CSRC/media/Publications/sp/800-56b/rev-2/draft/documents/sp800-56Br2-draft.pdf -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
