Downgrade avoidance

[mwelzl]

12.1. Considerations for Candidate Gathering

Implementations should avoid downgrade attacks that allow network
interference to cause the implementation to select less secure, or
entirely insecure, combinations of paths and protocols.

12.2. Considerations for Candidate Racing

Implementations should ensure that all options have equivalent
security properties to avoid incentivizing attacks.

For 12.1, of course implementations should use all "downgrade
avoidance" techniques that are specified for each protocol in the
protocol's standards. But more thought needs to be done about the
situation where the application specifies allowing a set of protocols
which, taken as a whole, has a downgrade problem. There are only two
solutions: (1) TAPS allows the application to specify a group of
protocols with unequal security properties; in which case, the
application shouldn't expect to get more security than the least
secure protocol in the group. (2) TAPS forbids the application to
specify a group of protocols with unequal security properties and
enforces that condition. Which obtains depends on the API definition,
but the implementation has no leeway in either case, and this document
ought to state the situation clearly.

---

From the review by Dale Worley: https://mailarchive.ietf.org/arch/msg/last-call/bpBk8QxZMLksr3ZuROtf2_BXYdI/
Note that indentation was lost by copy+pasting here - look at the edited version or the version at the URL to get a clearer view of what is being quoted.

[tfpauly]

Maybe we just need a reference to Architecture to point to how it already prohibits unequal security properties.