Early Review of draft-ietf-taps-arch-12
review-ietf-taps-arch-12-secdir-early-ladd-2022-05-30-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

In summary I think this document has nits.

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.

Sincerely,
Watson Ladd