Change:
We specifically left normative language for the security stuff.
From Watson Ladd: One minor nit in particular concerns the example of TLS fallback. It's not the case that one needs to carry out a fallback to TLS 1.2 if TLS 1.3 is available, and indeed that shouldn't be done. Ordinary TLS version negotiation should work just fine. A deeper nit concerns the way security is supposed to work in this system. It's true that e.g. both TLS and IKEv2 can use X509 certificates. It is not the case they use them the same way as they aren't authenticating the same thing. It is very much not the case that X509 validation involving trust verfication callbacks by the application works correctly, even conceptually or in most libraries, and the WebPKI will have very different additional requirements than other PKIs. It gets even more complicated when we consider how origin authority actually works in the web. I'm confused by the warnings on cross-protocol use of key material. For a PSK one really does want to link it to the protocol, but the same isn't true for X509 certificates across TLS and QUIC: you're supposed to use the same ones. I'm not sure how effective handling this all over to the application will be, or how the API will effectively make clear what connection the material will be used with in a racing environment.
These -arch sections contain normative language… didn't we try to get rid of all normative language in -arch?

Discussion:
Services implementation MUST NOT automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols.  A Transport Services implementation MAY allow <del> applications to explicitly specify that fallback to a specific other version of a protocol , e.g., to allow fallback to TLS 1.2 if TLS 1.3 is not available. </del> <ins> applications to explicitly specify which versions of a protocol ought to be permitted, e.g., to allow a minimum version of TLS 1.2 in case TLS 1.3 is not available. </ins> 3.4.

Applications need to ensure that they use security APIs appropriately.  In cases where applications use an interface to provide sensitive keying material, e.g., access to private keys or <del> copies of pre-shared keys (PSKs), key use needs to be validated.  For example, applications ought not to use PSK material created for the Encapsulating Security Protocol (ESP, part of IPsec) RFC4303 with QUIC, and applications ought not to use private keys intended for server authentication as keys for client authentication. </del> <ins> copies of pre-shared keys (PSKs), key use needs to be validated and scoped to the intended protocols and roles.  For example, if an application provides a certificate to only be used as client authentication for outbound TLS and QUIC connections, the Transport Services system MUST NOT use this automatically in other contexts (such as server authentication for inbound connections, or in other another security protocol handshake that is not equivalent to TLS). </ins> A Transport Services system must not automatically fall back from secure protocols to insecure protocols, or to weaker versions of secure protocols (see equivalence).  For example, if an application requests a specific version of TLS, but the desired version of TLS is <del> not available, its connection will fail.  Applications are thus responsible for implementing security protocol fallback or version fallback by creating multiple Connections, if so desired. Alternatively, the Transport Services API MAY allow applications to specify that fallback to a specific other version of a protocol is allowed by the Transport Services system. </del> <ins> not available, its connection will fail.  The Transport Services API MAY allow applications to specify minimum versions that are allowed to be used by the Transport Services system. </ins>