Paul Wouters writes: > >> If we assume rfc7431bis can be used with manual keys too, we need to add > >> some more text saying these ciphers cannot be used with manual keys. > > >> Anyways, I think it should be time to mark manual keys as SHOULD NOT. > > While I agree, I don't think 7321bis should do that. > > How about a new section between section 2 and 3: > > Manual Keying > > Manual Keying should not be used as it is inherently dangerous. Without > any keying protocol, it does not offer Perfect Forward Secrecy > protection. Deployments tend to never be reconfigured with fresh session > keys. It also fails to scale and keeping SPI's unique amongst many servers > is impractical. This document was written for deploying ESP/AH using IKE > (RFC7298) and assumes that keying happens using IKEv2. > > If manual keying is used anyway, ENCR_AES_CBC MUST be used, and > ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT > be used as these algorithms require IKE.
I think that kind of addition the rfc7321bis would be in order. Can you add that text and resubmit? > [note the first "should not" is in lower case in purpose, so we don't > actually need to update 4301] Perhaps not using word "should" is better. Something like "Manual Keying is not to be used as ...". Then we do not need to explain why it is not uppercase SHOULD... > >> Perhaps we should add note to the rfc7431bis that manual keys SHOULD NOT > >> be used, and mark it as updating RFC4301? > >> > >> Or should we have separate RFC stating that? > > draft-ietf-thisallmust-diedieidie-manualkeying-transportmode-ipcomp :) > > Seriously though, I don't think writing a document like that will change > anything. And at least on Linux, the ip xfrm command allows for manual > keying and therefor assist with testing, but the IKE daemons (libreswan, > strongswan and openswan) do not support manual keying anymore. Now seeing that there is things that require manual keys and which might be in use, I agree that we do not want to delay rfc7321bis because of this, and I think adding just the not above is correct solution. Then we might start new draft like you proposed and make that to update RFC4301, and that draft can then provide more text how to fix those protocols using manual keying... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
