[cap-talk] End to end encryption (was: network level ...)

[Ian G]

Stephen J. Bevan wrote:
> Jed at Webstart writes:
>  > That was my understanding also.  Is there some general hope
>  > (e.g. particularly in the IPsec community) that IPsec will
>  > spread enough that ultimately (soon?) this will be true?
>  > Is there any particular reason for hope or dismay in that
>  > area?
> 
> As I noted with Microsoft including IPsec in Windows and Linux having
> IPsec natively (as opposed to a third-party patch) the situation is
> much better than it was 5 years ago.  However, there seems to be some
> level of disagreement on how to do end-to-end encryption with some
> arguing for IPsec while others instead create a xxxS or Sxxx version
> for every (TCP) protocol xxx (e.g. HTTPS, POP3, IMAPS, SSMTP,
> ... etc.).   Theoretically IPsec is the right way to do things

I would say that the IPsec community argues that
IPsec is the right way to do things, and in this
they are no different from the TLS community that
argues that TLS (your xxxS) is the right way to do
things, and no different to the USG which argues
that no crypto is the right way to do things...

All of them have failed to carry the day, although
one could argue that the TLS/xxxS group had some
fairly good hit rates.

The right way to do it IMO is to do end-to-end with
your own protocol, integrated into the app, with
your own security requirements.  (E.g., to be boring,
Skype and SSH.)  While this has some costs up front
in terms of cryptoprotocol design and coding, the
payback later is in a proper alignment of requirements,
something you just can't do if you use some other
crypto-protocol.

(One of the reasons this is so is because TLS fills
the space of "right way to do it" but most apps are
not aligned to its connection-based paridigm.  It's
curious - the only application that I know that
is fully connection-oriented is SSH because of its
Unix commandline requirement, and even that has its
"accident of history" elements.)

> but it
> was arguable too little to late e.g. SSL was easier to use/deploy
> especially when it comes to NAT and asymmetric authentication.  IKEv2
> fixes a lot of the issues with IKE but users will have to wait years
> for that to be (widely) deployed and so in the meantime the
> pragmatists carry on creating xxxS protocols.


Yep.  To cross over to capabilities, it would suggest
that any capabilities implementation should implement
its own.

iang