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

[Andrew Cagney]

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

> for example, the case where the initiator sends proposals numbered #1,
> #2, #4. Technically, we should reject everything. Your proposed solution
> would allow us to use #1.

Yea.

> I understood both views. I tempted to lean towards being okay to ignore
> and have unparsed parts of a proposal tree. But there is some security
> impact - for example it could allow an attack to insert arbitrary length
> data into the packet for some cryptographic attack. Limiting the
> proposals to only valid syntax would prevent that.
>
> So perhaps possibly the best solution is to confirm the proposal list as
> valid, but return the first mutually agreed match?

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

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

I believe that follows the intent of the RFC.

Andrew