On 11 December 2015 at 13:27, Paul Wouters <[email protected]> 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 _______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
