Re: [perpass] tcpcrypt applicability (Was: Re: Violating end-to-end principle: I-D Action: draft-farrelll-mpls-opportunistic-encrypt-00.txt)

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Jan 20, 2014 at 10:27 AM, Dave Crocker <[e-mail]> wrote:

> On 1/20/2014 7:19 AM, Stephen Farrell wrote:
>
>> I'd expect that if tcpcrypt were implemented in
>> some kernels then it'd be useful in places where you can't
>> feasibly use TLS.
>>
>
>
> what are some examples of when this could occur?
>
> as long as there is speculation about this as a legitimate alternative, it
> would help to have the speculation include plausible examples.


tcpcrypt looks more like an alternative to IPSEC than TLS to me.

Given that IPSEC has been a flop, working on an alternative twenty years
later seems fine to me.


The types of use case where I see problems with our current infrastructure
are for applications such as wireless networking where WiFi security is
still a usability disaster and remote access (aka dialup but we don't
dialup any more).

One major design limit in IPSEC and TLS is that both view the key exchange
as being integral to the security layer rather than a separate service. I
would like to separate out consideration of how chunks of data passing over
the net are tagged and bagged for encryption and authentication from the
question of key setup.

There is no logical reason why the key negotiation for TLS, IPSEC and
tcpcrypt cant be shared.


-- 
Website: http://hallambaker.com/