Paul Wouters writes: > > AES-CCM: Why a MUST? I don’t have any interest in implementing it. > > That came in via the MUST for ESP in RFC7321. I don't particularly want > it.
I think AES-CCM is useful to have as SHOULD, as it is useful in certain environments, but I do not want to mark it as MUST, as it is not used in other environments. On the other hand I assume that in practice those IoT implementations are going to ignore this completely, and only implement the ciphers they use, and they will not be implementing all mandatory to implement ciphers, as they do not have space for them. > > SHA-512: I assume you mean HMAC-SHA-512 as PRF and integrity > > algorithm. Do we need it? The future seems to be AEAD algorithms, > > so do we really need PRF_HMAC_SHA2_512 ? Perhaps something SHA-3 > > based is going to be the future? > > For non-AEAD I'm a little nervous to only have HMAC-SHA-256. I think > we might want to have HMAC-SHA-512 as a temporary stopgap in the > future, although once we have SHA-3 we could again drop it for a > SHA-3 version. I think having HMAC-SHA2-256 now, and adding longer SHA3 based PRF in future might be better. > > "Can we add a recommendation to use integ == prf for non-AEAD > > algorithms?” - I don’t thin we can in this document. That would be > > changing IKE, no? > > Well, our algo/cipher changes also modifies IKE (7296) doesn't it? No this document does not change RFC 7296. The RFC 7296 does not specify mandatory to implement algorithms just for this reason. I.e. they are left out from the IKEv2 rfc, and moved to this separate RFC. > I don't think 7296 makes any recommendations. (also I did put in > "updates 7296" in my text :) The reason I'm asking was that we ran > into this because libreswan only supports specifing PRF for AEAD and > otherwise picks the INTEG as PRF. This caused us to fail a TAHI > test. I had to argue about that failure, and I'd rather have some > RFC text to do the arguing for me. I think adding text that would say INTEG == PRF in this document would be changing the IKEv2, and would make several implementations non-complient with the this RFC, or at least go against SHOULD in here if they do allow INTEG != PRF. Also there is no need that INTEG would need to be same as PRF. Even if the AUTH_AES_XCBC_96 is fine for the integrity algorithm, I am much more happy to use HMAC_SHA2 as PRF, than to use the AES128_CBC as PRF (there are some concerns about how good PRF it really is). Oh, btw we need to fix the name of the PRF_AES128_CBC, it should be called PRF_AES128_XCBC. It is XCBC not CBC (the title of RFC4434 says AES-XCBC-PRF-128). And we could make IANA action in this draft to fix the name in iana registry too. > > Group 18 (8192 bits) - IMO this is so slow that I don’t like > > making it a SHOULD. > > hmm, okay. I would like something non-ECC that's larger than 2048 > though. We are writing mandatory to implement algorithms list, you are free to implement longer groups. If you have implemented 2048-bit group, adding longer groups is not an issue. On the other hand if we want to make any other group as SHOULD, we should stick to the 3072 or 4096 bit groups, which provide more than enough security when you take in to account of memory required to crack those groups. > > "Can we recommend that the initial exchanges and create child sa use > > the same MODP group? and that we recommend PFS for create_child_sa.” > > The former is a sensible recommendation, but it belongs in 7296, not here. > > Same as above. I would be good to have it somewhere, because I've had > this discussion a few times as well. Why not here, where we talk about > IKE crypto recommendations specifically. It seems the right place to me. Actually I can see that people might want to use long Diffie-Hellman for the IKEv2 SA, just to get maximal protection for all traffic, and then do fast Diffie-Hellman every few minutes when they rekey their traffic keys. So I do not think such recommendation would be good. > > As for recommending PFS, I’m not sure. This is not the same as > > TLS. PFS in TLS prevents exposing encryption keys with the future > > exposure of a long-term secret - the private key. In IKE the IPsec > > encryption key depends not on the long term secret, but on another > > ephemeral value - the SK_d. This is far less problematic, so I’m > > not sure such a recommendation is worth the cost. > > Then we wasn't it dropped from CREATE_CHILD_SA? What we have now is that > different implementations with different defaults cause interop issues > on CREATE_CHILD_SA. (which is nasty when problems only show up at rekey > time) If one end has unsecure policy which you do not want to accept, the right fix is to either allow that policy which you consider unsecure, or fix the configuration of the other end. Yes, there can still be misconfigurations with IKEv2 too... > > "Can we recommend that a default proposal set should have at least > > one MUST algorithm for each type?” I didn’t understand this. What > > is a default proposal set? > > The defaults in the configuration. If the administrator sets no explicit > proposals or proposal elements. So if the software starts negotiating > the admin forcing the algorithms, there is guaranteed to be a proposal > that will work because it only uses MUST's. Again, this is to enhance > interoperability. We do not have default configuration. Also nothing we write here does not affect anybody USING ciphers. We only specify what must be implemented, we do not specify what will be used. It seems you would like to write profile document describing default configuration for IKEv2? I do not think such profile belongs to this document, but you can write new UI Suite document and define your default cipher settings, and other configuration parameter settings. Then you can refer to that... :-) And yes, we might want to specify new UI suites especially for the CHACHA20_POLY1305... > > "Can we recommend not to apply these recommendations for IKEv1 because > > that will cause more interop problems (see my draft for text)” > > > > I think we should just ignore IKEv1 at this point. You definitely > > should not use AES-GCM with IKEv1. > > Again, as implementor/vendor it really helps me to have RFC text somewhere > that makes this clear so I don't have to argue with customers on why we > don't support GCM for IKEv1. You should argue, that as IKEv1 was obsoleted 10 years ago, it needs to be obsoleted from the implementations too... Or at least it should be disabled by default for all configurations, and it can only be enabled in the configuration by explitly adding the value of "Pre-Shared key for the Internet Protocol" in configuration file, and if you do not know the key listed in that draft, there is no way to enable ikev1... :-) -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
