Subject: Re: [Taps] TAPS relationship with security (was: Re: Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT))

From: Brian Trammell <[email-masked]>
Date: Wed, 2 Jul 2014 13:34:27 +0200

(Catching up on the various threads a bit here...)

On 27 Jun 2014, at 01:37, Barry Leiba <[email-masked]> wrote:

>> So, just to try to keep things straight ... the theory is that no matter how
>> one Lego-assembles one's transport, one could use TLS or DTLS above that
>> transport, if one is relying on the aspects of security those mechanisms
>> provide? Does TAPS need to go beyond that?
> 
> I think it should.  I think that encryption, TLS-style server
> authentication, and the like are just as much transport services as
> are congestion control and in-order delivery.  The whole point here is
> to remove the specification of what services are needed from the
> specifics of the transport protocols that provide them.
> 
> And TLS as we know it today requires TCP.  In a TAPS world, it would,
> itself (if it were not part of the transport layer), have to specify
> what transport services it requires.

DTLS removes the requirement to run on top of TCP. Of course, it's still essentially a backport of the TLS protocol to a different set of assumptions about what it's running on top of, so your point stands.

> I would like to see "transport layer security" become a true part of
> the transport layer, not in name only.

+ many. The point here -- and how I'd rephrase Stephen's comment -- is that security characteristics of a transport (whether it provides confidentiality, integrity, message/endpoint authenticity) are "first class" characteristics of a transport protocol, just like reliability, or multihoming, and must be considered as such. 

(And TCPINC, just chartered, is working on a new transport protocol, and there needs to be interchange between the two groups to make sure that (1) TCPINC isn't gratuitously TAPS-unfriendly, whatever that means and that (2) TAPS can accomodate the protocol that comes out of TCPINC. This is less a security-specific issue than a maybe-we-should-talk-to-each-other issue. :) )

Cheers,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Jul 2014 12:41:43 +0100

Hi Brian,

On 02/07/14 12:34, Brian Trammell wrote:
> + many. The point here -- and how I'd rephrase Stephen's comment
> -- is that security characteristics of a transport (whether it
> provides confidentiality, integrity, message/endpoint authenticity)
> are "first class" characteristics of a transport protocol, just
> like reliability, or multihoming, and must be considered as such.
> 
> (And TCPINC, just chartered, is working on a new transport
> protocol, and there needs to be interchange between the two groups
> to make sure that (1) TCPINC isn't gratuitously TAPS-unfriendly,
> whatever that means and that (2) TAPS can accomodate the protocol
> that comes out of TCPINC. This is less a security-specific issue
> than a maybe-we-should-talk-to-each-other issue. :) )

Nicely put. That's what I'm after.

S.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 2 Jul 2014 08:54:16 -0400

> Nicely put. That's what I'm after.

Et moi aussi.

Barry

---

From: Aaron Falk <[email-masked]>
Date: Thu, 3 Jul 2014 12:21:01 -0400

>> Nicely put. That's what I'm after.
I agree as well.  I am a little worried that (as Lloyd suggested) security
discussions may dominate the working group or, worse, there will be
insufficient security 'clue' to do a good job.

--aaron

---

From: Brian Trammell <[email-masked]>
Date: Mon, 7 Jul 2014 08:25:44 +0200

hi Aaron,

On 03 Jul 2014, at 18:21, Aaron Falk <[email-masked]> wrote:

> I agree as well.  I am a little worried that (as Lloyd suggested) security discussions may dominate the working group or, worse, there will be insufficient security 'clue' to do a good job.

As a first step, treating TCPINC as exactly the kind of new transport protocol development TAPS is meant to foster, and TCPINC considering TAPS as the framework-in-development for new transport protocol deployment, should be sufficient for security 'clue' -- i.e., the security-specific bits of the discussion will happen largely in TCPINC, and if there's not sufficient security clue in *that* room then we've got bigger problems.

Note that this interaction cuts both ways: these security services are important, but they're not snowflake-special: you need switches to turn them on and off, guidelines on when to do that and how, and additional interface support to push additional configuration (i.e. keys) down and pull additional status (e.g., "transport not authenticated") up.

As for avoiding unproductive ratholing on tangentially- or un-related arguments about security... well, that's why working groups have chairs. :)

Cheers,

Brian