[anonsec] should IPsec policies be partially ordered?

[Rafael Coninck Teigão]

> There are two issues here, which are seperable:
> 1) should there be abstracted profiles instead of concrete protocols.
>     I claim that applications should never do:
>           if(cipher_algo == AES128) {  /* trust user */ }
>           else { /* user is insecure */ }
>
>     http://www.sandelman.ca/SSW/ietf/ipsec/btns/ietf-btns-ipsec-apireq.html#anchor7

To quote section 7:
"Hard-coding algorithm names into applications should be actively
discouraged; there SHOULD be generic "weak" or "strong" indications
instead of specific algorithm identifiers."

It think hard-coding algorithms should be forbidden, and identifiers
should be mandatory. This adds a lot to configurability. We should
just define correctly the identifiers and add special cases for when
they are not defined (should we default to some algorithm? or return
an error?)

> 2) should there be a partial order.

Yes. We certainly may want to accept stronger algorithms when
available, but not always (e.g. when there's not enough processing
power for using a strong cypher).

[]'s,
Rafael.