Re: [Taps] Review of draft-ietf-taps-transport-security-10

[Kyle Rose <[e-mail]>]

On Sun, Dec 1, 2019 at 8:42 AM Eric Rescorla <[e-mail]> wrote:

> Document: draft-ietf-taps-transport-security-10.txt
>
> This document is much improved. I appreciate you removing all the fine
> detail of each transport protocol.
>

Noted. Just to be clear, the modifications to the most recent version of
the draft were made primarily to eliminate the impression that we were
trying to "race" security protocols under the assumption that they are
somehow equivalent or even abstractable, which we know isn't the case. The
main goal of incorporating security into TAPS is primarily to provide a
modern, consistent, portable interface to the extent possible, not to
provide a developer with the illusion of security simply by flipping a
switch.


> Part of this can be fixed by just
> saying something like this and including DTLS in a few other places
> in the doc, but in general, the world is just complicated and so
> taxonomies are difficult.
>

Agreed (a good example being the OSI layer abstraction, which we run into
here and which fails miserably in many common cases), but---under the
assumption that the problem TAPS is trying to solve is a useful one---a
simplified taxonomy motivating an interface that can accommodate the vast
majority of use cases for our target community is a prerequisite.


> S 3.3.5.
>    CurveCP [CurveCP] is a UDP-based transport security protocol from
>    Daniel J.  Bernstein.  Unlike other security protocols, it is based
>    entirely upon highly efficient public key algorithms.  This removes
>    many pitfalls associated with nonce reuse and key synchronization.
>
> This text is going to be confusing to people.  Not to say that CurveCP
> is bad, and the primitives it uses *are* fast, but they're not any
> faster than those used by TLS, QUIC, or tcpcrypt. I think the
> consensus here is that it's not currently practical to have a general
> purpose transport protocol that doesn't do key establishment and then
> use symmetric keys. (This is the same reason why we weren't able
> to use public key encryption for QUIC CID encryption).
>

Good point. We could discuss the tradeoff between performance and security
that DJB was trying to achieve, but that is probably out-of-scope for this
document, so we should stick to a value-free description (e.g., "based
entirely on public key algorithms") and let it go with that.


>    o  tcpcrypt
>
> This doesn't seem quite right, as tcpcrypt is run prior to the TCP
> reassembly algorithms.
>

If I'm reading you correctly, this is not right. For compatibility with
middleboxes, tcpcrypt runs within the TCP bytestream, just like TLS, and
requires reassembly before the tcpcrypt TLV record layer can be parsed.


> 5.1.  Pre-Connection Interfaces
>
>    Configuration interfaces are used to configure the security protocols
>    before a handshake begins or the keys are negotiated.
>
> This presentation seems pretty hard to follow, in that it's a lot of
> work to figure out which in the long list of protocols doesn't have
> this property. Maybe a summary table would help?
>
> Also, I'm not sure you want to omit tcpcrypt here, in that it does
> have a way to do external authentication by exporting a session ID.
>
...

> tcpcrypt (and I believe ZRTP) both have session caches.
>

Good call(s).

Kyle