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
> <[email protected]> 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/
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
