Re: [Taps] Secdir early review of draft-ietf-taps-arch-12

Hi Watson,

Thanks for the review!

I’ve captured your review in an issue:
https://github.com/ietf-tapswg/api-drafts/issues/1041

And proposed some changes in this PR:
https://github.com/ietf-tapswg/api-drafts/pull/1042

Respones inline:

> On May 30, 2022, at 10:33 PM, Watson Ladd via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Watson Ladd
> Review result: Has Nits
> 
> 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.

Yeah, this text was confusing. I’ve updated it to be more clear that really this is about the system respecting the minimum version requirements an application might have. Essentially, this is about APIs like this: https://developer.apple.com/documentation/security/3180218-sec_protocol_options_set_min_tls

> 
> 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.

There’s no intention of trying to use certificates across TLS and IKE! That certainly doesn’t make sense. I don’t think the text implied that anywhere, but I’ve tried to make that more explicit in the PR.

> 
> 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.

Overall, I think the requirement is that the security options need to be very explicit in what protocol you’re setting specific material for — and certainly, setting a common cert between QUIC and TLS/TCP is a standard feature.

Best,
Tommy
> 
> Sincerely,
> Watson Ladd
> 
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps