Skip to main content

Early Review of draft-ietf-taps-arch-12

Request Review of draft-ietf-taps-arch-11
Requested revision 11 (document currently at 19)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2022-06-04
Requested 2021-07-30
Requested by Reese Enghardt
Authors Tommy Pauly , Brian Trammell , Anna Brunstrom , Gorry Fairhurst , Colin Perkins
I-D last updated 2022-05-30
Completed reviews Opsdir Telechat review of -18 by Dhruv Dhody (diff)
Intdir Telechat review of -18 by Bernie Volz (diff)
Secdir Early review of -12 by Watson Ladd (diff)
Artart Early review of -11 by Robert Sparks (diff)
Secdir Last Call review of -17 by Watson Ladd (diff)
Opsdir Last Call review of -17 by Dhruv Dhody (diff)
This document is highly related to draft-ietf-taps-interface, for which we also request review.
Both documents are held until draft-ietf-taps-impl is finished as well, and the three docs are aligned.
Assignment Reviewer Watson Ladd
State Completed
Request Early review on draft-ietf-taps-arch by Security Area Directorate Assigned
Posted at
Reviewed revision 12 (document currently at 19)
Result Has nits
Completed 2022-05-30
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.

Watson Ladd