[Swan-dev] how should a proposal (SA's crytpo suite) be selected

[Paul Wouters]

On Thu, 10 Dec 2015, Andrew Cagney wrote:

> Twice now I've found a discussion about replacing the proposal
> selection code ending up asking this question.
>
> So here's what the spec has to say:
>
>    Nothing
>
> well, technically, that isn't true.  What it actually says is:
>
>   3.3.6.  Attribute Negotiation

> However, I suspect the intent is that the initiator sends us proposals
> in preferred order and we should probably respect that.
>
> To that end, the new code (and I suspect the old code) currently:
>
>   - each initiator proposal is examined in order, the first that
> matches any of our responder proposals is selected
>   - within an initiator proposal, the types (transforms) are searched
> sequentially and the first to match is selected (it is not exhaustive)

For the KE payload, the client will probably pick the KE/modp group with
the highest chance of success. Which does not neccessarilly mean the
best it supports (which would be its preference)

For instance, in IKEv2 we startout with MODP2048 because that is
supported by most IKEv2's. But we will add MODP3072 soon, and we might
prefer that (at the cost of a round-trip). In that case, the responder
willing to do both, should signal INVALID_KE and suggest modp3072.

The real question is added security versus the penalty of one RTT. When
do we do that? Currently, we know that some clients (read: iOS, openswan)
do not properly implement INVALID_KE, so we have a stronger reason to
stick with the initiator's decision of MODP group, provided it is
acceptable to us. However, in the future we might want to revise that
when we see better implementations of third parties of INVALID_KE.

The next question is the proposals and orders....

> For instance, say we only have encryption and our poorly
> grouped/ordered acceptable proposals looked like:
>
>    #0 [ENCR] 3des des
>    #1 [ENCR] aes256 blowfish
>    #2 [ENCR] aes128
>
> If we receive (which we can interpret to mean that they prefer
> blowfish over aes256):
>
>    [ENCR] blowfish aes256

The way I read the specification is that since the initiator can send
multiple proposals, and the responder can only select one of those, it
is the responsibility of the responder to pick its favourite,
irrespective of the order of the initiator. This also assumes that if
there is no restriction in the spec, local policy trumps. However,
that does mean going through all initiator and responder proposals
and transforms (and we know strongswan sends way too many of those)

> So returning to the question that came up twice: what should we be doing?

I do feel that proposals are a numbered list of preference. I'm less
confident about the ordering of the encryption algorithms within one
proposal.

I just reread the parts of RFC 5996 and RFC 7296 and they indeed provide
no guidance.

Paul