Draft: draft-ietf-taps-arch

Commentary: We specifically left normative language for the security stuff . 
 From   : 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 should n'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 are n'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 is n'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 … did n't we try to get rid of all normative language in -arch ?
Paragraph (version B):
To ensure that security protocols are not incorrectly swapped, a
Transport Services implementation MUST only select Protocol Stacks
that meet application requirements (RFC8922).  A Transport Services
implementation SHOULD only race Protocol Stacks where the transport
security protocols within the stacks are identical.  A Transport
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
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.
Paragraph (version A):
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.
Paragraph (version A):
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
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.
Paragraph (version B):
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).