On Thu, 22 May 2014, D. Hugh Redelmeier wrote:
The Robustness Principle from RFC 1122: "Be liberal in what you accept, and conservative in what you send"Here's a tricky case. Apparently, when the ipsec.conf specifies "aes", for example, we take it to mean: propose AES 128 (bug: 256 for ESP) but accept AES 128, 192, or 256 That sure looks as if it is an application of the robustness principle. I'll try to show that it isn't. Consider a case where the other side can only do AES 128 (probably due to configuration). They can successfully initiate with our side. But then when, for some reason (perhaps rekeying), we wish to initiate, we will fail. It would be better to fail to interoperate the first time because that will be less mysterious. It would be better to fail reliably because that will be easier to debug. So: I think that, by default, all policies should be symmetric. In particular, a notation for cyphers suites should cause libreswan to propose and accept the same set of cyphers.
I would like the policies to be symmetric. We have seen how badly this works out when it is assymetric with the pfs= and compress= options, which we made symmetric to avoid rekey problems when initiator and responder roles switch. But as per RFC 1122, and for customer satisfaction, I would also like to not break existing deployments so that upgrades will be seamless.
There are two ways to fix the "aes" case. 1. change libreswan so that "aes" means "aes at all supported keylengths" in both proposal and acceptance.
That is what we currently do (or at least meant), although we don't advertise this properly during IKE.
2. change libreswan so that "aes" means "aes at the single default keylength" in both proposal and acceptance.
This would break existing configurations - I would like to avoid it.
2b. change libreswan so that "aes" is no longer accepted. The key size must be specified, and will not be defaulted. This way admins are forced to upgrade ipsec.conf and there is no silent change.
This would break existing configurations - I would like to avoid it. The situation is actually a little more complex. If we encounter one of the "current" libreswan's that has not been fixed to send the key length for IKE, or all openswan versions that have this problem, than we need to make a decision on what key length to assume. We could reject this connection as being in violation of RFcs (like 4309 and 3686), but that would not be in the spirit of RFC 1122. I think the cipher without numeration should include all of them, eg aes means aes128 or aes192 or aes256. On the responder, if we did not receive OAKLEY_KEY_LENGTH (ike) or KEY_LENGTH (esp) than we assume 128, which is the only key size that is mandatory to implement. This is the same for other ciphers, such as camillia. Note that the IKEv2 proposals would not explode in size, but the IKEv1 one would. This could cause problems if people use X.509 and this policy change would push them over the MTU limit. So that is a reason for only adding one AES proposal. But what key size to use? For ESP we would need to use 256 as that's what we currently do, but that's not according to the mandatory to implement set. So I would be tempted to include both and risk hitting the MTU. As people are moving towards SHA256 and bigger RSA keys, one would assume this problem would hit those people sooner than later anyway. Doing it this way also means we do not need to change any code for the responder, and we only need to change code for the initiator. Some of that was already started by me, but might need changing to comply to the above scheme. I need to verify whether we can send multiple key lengths in a single proposal or not, or whether we would need to add a new proposal to the set. Paul _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
