[Swan-dev] symmetry vs Robustness Principle

Paul Wouters paul at nohats.ca
Thu May 22 21:31:36 EEST 2014


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


More information about the Swan-dev mailing list