Re: [Taps] IETF last call comments on draft-ietf-taps-transport-security

["Philipp S. Tiesel" <[e-mail]>]

Hi,

as shepherd of the document and contributor to the WG, I am a little puzzled about the way this document got stalled after overall successful reviews. The major criticism I extracted from Eric's and Christian's reviews is neither new nor surprising, but maybe we should iterate them again to make the document more useful – especially for people that are generally skeptical towards TAPS' mission.
Here are my thoghts on the major points of criticism:

General skepticism towards TAPS:

De-coupling the API contract from the actual transport used is an ambitious project. It is easy to state that this is not going to happen and that we can not fight (protocol) ossification, but this does not remove the need to evolve, it just shifts the responsibility towards the application developers. In the security domain, De-coupling the API contract from the actual security protocol may look like a bad idea at first glance, as every bad choice can lead to an additional attack vector, but this is only true under the assumption that all application developers are security experts. Using a "TAPS autopilot" for your applications' secure transport can never be as secure as a complete security design, but is certainly better than copy&paste from Stack Overflow. This holds especially when looking at the software lifecycle. The TLS library example from 2017 might still be acceptable today, but won't be in 2023. The decision made in the TAPS system can be changed with an OS update – the application code won't. 
The question is whether we must make this argument again and again or accept that this form of general criticism can only prove right or wrong over time.

Security work outside of the Security area: 

This document is clearly in Security scope. We had not a real an alternative to writing this: 
	• Excluding security protocols from TAPS makes the whole approach useless. 
	• Asking the security area to write the document for us is not how the IETF works. 
As we have people with strong security background among the authors and in the group and asked for reviews from the Security area early on, I see not how we could have approached this need differently. 
What we can do is try to involve the Security area more than just asking for reviews: approach the Security area, have this presented in secdispatch, and ask for more input – Not sure if this will help.

Mixed bag of things:

This document is clearly two things: A survey of security protocols and a description of the security-related transport features they provide we need as input in the API and implementation documents.
As the document is still of an acceptable size, we had a WG consensus that this is acceptable. When reading EKR's review, I am not sure whether this was a good decision. Having a clear separation of a survey and MINSET-like feature document, like we did with RFC 8303 + 
RFC 8304 and MINSET, would make the survey much cleaner and the feature document better digestible, especially for people who are skeptical towards the general TAPS idea.

I think none of these are a reason to abandon the document, but things we should briefly discuss here and now. Afterwards, we should use the meeting in Singapore to coordinate the action items resulting from this discussion.

AVE!
   Philipp S. Tiesel

> On 24. Oct 2019, at 10:06, Magnus Westerlund <magnus.westerlund=[e-mail]> wrote:
> 
> Authors and WG,
> 
> Considering the IETF last call comments by Eric Rescorla and Christian Huitema I
> would like to see discussion on the points they bring up. I can understand that
> addressing this fully could be a very significant change to the document. 
> 
> I do see the point they are bringing up about the architectural view of how the
> protocols are used. I get the impression that TAPS does have a small set of
> viable security architectures and the choices do affect properties seen from the
> TAPS API level. Also there are details beyond the properties that gets affected
> by the layering of security and transport mechanisms and what implementation
> parts you have to trust for the security properties. So discussion of these
> aspects may be needed. 
> 
> So please discuss how these are addressed. 
> 
> Cheers
> 
> Magnus Westerlund 

--  
Philipp S. Tiesel
https://philipp.tiesel.net/