[Swan-dev] how should a proposal (SA's crytpo suite) be selected
andrew.cagney at gmail.com
Fri Dec 11 19:06:43 UTC 2015
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
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)
then. if our responder proposals look like:
#0: aesgcm-modp4000 aesgcm-modp2000
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
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 :-)
More information about the Swan-dev