On 03/11/15 09:42, "Tero Kivinen" <kivi...@iki.fi> wrote:
>>- Section 3.2. says “When an AEAD algorithm (see Section 3.1) is >> used, no algorithm from this table needs to be used.” Shouldn’t this >> be “MUST NOT be used”. > >This document just states the fact, the actual MUST NOT is in the >RFC5282, and I do not think we should repeat that here. I.e. this text >just states the fact of life based on the RFC5282, but does not make >any requirements. Then you should probably remove the ‘MUST' in "Algorithms that are not AEAD MUST be used in conjunction with the integrity algorithms in Section 3.2.” >>- Section 3.1. I think AES_CCM_8 should somehow be restricted to >> IoT, as using 64 bit tags in IKE does not sound like general good >> advise. Also IoT implementations would probably just implement >> “ENCR_AES_CCM_8”, “PRF_HMAC_SHA2_256", and "256-bit random ECP >> group" and skip everything else. It seem to make more sense to >> specify an IoT profile in a separate section. > >The IoT devices talk to each other, but also to more general purpose >servers, i.e., in your home you might have some kind home area network >server, where all the IoT devices connect to. In that case those >bigger boxes do want to implement the same AES_CCM_8 just so that >those IoT devices which didn't implement anything else can talk to >them. > >I.e. I think it is good thing to require real systems to have SHOULD >for the AES_CCM_8. Of couse if your implementation is never expected >to talk to IoT devices, then that is good reason to go against the >SHOULD and leave the AES_CCM_8 implementation out. That sound reasonable, but shouldn’t the IoT devices have some guidelines (maybe just a sentence) on what they should implement? We know that they will not implement everything, and if they chose different subsets, they will not be able to talk to each other. >>- Section 3.4. The Diffie-Hellman group table diverges heavily from >> the rest with only 112-bit security as MUST, and no group offering >> 128-bit security as even SHOULD+. > >That depends how you calculate the securities of the Diffie-Hellman >groups. If you check RFC3526 that gives two strengh estimates for >2014-bit group, 110 and 160 bits. The 160 bit strength takes also >account the memory prices in the calculations, the 110 assumes memory >is free, and CPU cost is only thing that matters. There is also: - Lenstra (http://infoscience.epfl.ch/record/164539/files/NPDF-32.pdf) giving the estimate 95 bit strength - The IETF BCP (RFC3766) giving the estimate 103 bit strength - ECRYPT giving the estimate 103 bit strength So if anything, I would say the general consensus is that 2048 MODP may not even give 112 bits security… >>This may be ok, but I think the ipsecme group should try to fulfill >> general recommendations on security levels (NIST, ECRYPT) and have a >> plan on how to make 2048-bit MOPD a MUST NOT before 2030. > >I think we are going to replace this document several times before >2030. We actually should have replaced this already few years ago, so >this update is already bit late, but I would assume we might make new >version after we get those new EC groups now being defined to the >implementations. That sounds really good. It’s very important that both this and RFC7321 gets updated regularly. > On the other hand there are lots of people still >running IKEv1, so getting them to implementations might get time. But IKEv1 is not in scope for RFC4307 or RFC4307bis so what they implement or not should not be taken into consideration. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
