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

[Andrew Cagney]

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

   During Security Association negotiation initiators present offers to
   responders.  Responders MUST select a single complete set of
   parameters from the offers (or reject all offers if none are
   acceptable).  If there are multiple proposals, the responder MUST
   choose a single proposal.  If the selected proposal has multiple
   transforms with the same type, the responder MUST choose a single
   one.  Any attributes of a selected transform MUST be returned
   unmodified.  The initiator of an exchange MUST check that the
   accepted offer is consistent with one of its proposals, and if not
   MUST terminate the exchange.

i.e., we can pick a random acceptable proposal.  After all, being
unpredictable will keep the attacker on their toes, right :-)  It then
goes on ...

   Negotiating Diffie-Hellman groups presents some special challenges.
   SA offers include proposed attributes and a Diffie-Hellman public
   number (KE) in the same message.  If in the initial exchange the
   initiator offers to use one of several Diffie-Hellman groups, it
   SHOULD pick the one the responder is most likely to accept and
   include a KE corresponding to that group.  If the responder selects a
   proposal using a different Diffie-Hellman group (other than NONE),
   the responder will indicate the correct group in the response and the
   initiator SHOULD pick an element of that group for its KE value when
   retrying the first message.  It SHOULD, however, continue to propose
   its full supported set of groups in order to prevent a
   man-in-the-middle downgrade attack.  If one of the proposals offered
   is for the Diffie-Hellman group of NONE, and the responder selects
   that Diffie-Hellman group, then it MUST ignore the initiator's KE
   payload and omit the KE payload from the response.

i.e., we can initially send keying material for a random DH group,
perhaps from one of our proposals, right :-)

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 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

 then we'd accept blowfish because:

- #1 is the first responder proposal containing a match
- #1 within that responder proposal blowfish was searched for (and found) first

And for:

    [ENCR] blowfish aes128 des 3des

we'd accept des because:

- #0 is the first responder proposal containing a match
- #1 within that responder proposal des was searched for (and found) first

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

Well, I don't think we need to make this any more complicated (if the
remote end really prefers des, and we have it as acceptable then who
are we to argue!).
Similarly, while we could tweak things so that, instead of stopping at
the first transform match within a proposal, we try and pick our
earliest, we can just as easliy achieve that behaviour by splitting
proposals. (although, for this one, I don't care).

Andrew