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

[Andrew Cagney]

On 11 December 2015 at 13:22, Paul Wouters <paul at nohats.ca> wrote:
> On Thu, 10 Dec 2015, Andrew Cagney wrote:

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

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

Yes.  That wonderful word "intent"; the intent is that the ordering
should indicate preference.

The current code, has a bias towards the initiators intent - it
selects the earliest initiator proposal that matches.

The reverse bias might be better - select the earliest responder (our)
proposal that matches.  For instance, given the initiator (their)
proposals:

     #0: des
     #1: aesgcm-modp2000
     #2: aes
     #4: aesgcm-modp4000

then. if our responder proposals look like:

     #0: aesgcm-modp4000 aesgcm-modp2000
     #1: aes
     #2: des

then the selection would be either:

    initiator bias (existing code): des
    responder bias (perhaps better): aesgcm-modp2000

(remember first match, not best match, what ever that means and why I
just call this a bias) and similarly if we changed our responder
proposals to:

     #0: aesgcm-modp4000
     #1: aesgcm-modp2000
     #2: des
     #3: aes

we'd get:

    initiator bias: des
    responder bias: aesgcm-modp4000

That might be more intuitive.

I suspect, by using the current code and just continuing to search (if
a latter match has an earlier responder proposal then switch to that),
I can do this and avoid having to pre-load all the proposals; but I'm
still thinking about this.

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

Yea, I suspect that it is deliberate.   This e-mail thread illustrates why :-)

> Paul

Andrew