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

[Andrew Cagney]

BTW, at the very start of SA proposal section of the RFC there's this:

An SA payload MAY contain multiple proposals.  If there is more than
one, they MUST be ordered from most preferred to least preferred.

but, again, there's nothing to indicate that we need to honour that
preference in any way.


On 11 December 2015 at 14:32, Paul Wouters <paul at nohats.ca> wrote:
> On Fri, 11 Dec 2015, Andrew Cagney wrote:
>
>> On 11 December 2015 at 13:27, Paul Wouters <paul at nohats.ca> wrote:
>>>
>>>
>>> Note Hugh had one comment regarding the "stop reading when you found
>>> an acceptable proposal to return". It could be that the unread remainder
>>> of the proposal/transforms are badly formed. It could be argued that
>>> we should return NO_PROPOSAL_CHOSEN or INVALID_SYNTAX.
>>
>>
>> How liberal should we be in what we accept :-)
>
>
> liberal does apply to cryptography :)
>
>> We need to be careful.  I been wondering if the current code, which
>> does parse the entire set of proposals, is rejecting things it should
>> have skipped.
>>
>> How about I parse everything and:
>>
>> - if packet.[hc] returns an error then I'll bail

the code logs this as "corrupt".

>> - however, if the contents are messed up (zero or missing keylen for
>> aes; AEAD with AUTH; unknown type; ...), I'll skip and continue

This is really do cases:

- an unknown payload (presumably something new we don't yet know about)

- an invalid payload (for instance, a missing keylen)

but which ever.

>> I believe that follows the intent of the RFC.

> That sounds perfect.

With a bit of 'good enough'.  If an unknown transform is followed by a
corrupt transform then, for now at least, I'm only detect the first.

BTW, how should these two be logged?  The existing code isn't too
consistent, using either loglog or libreswan_log.

> Paul