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

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

On Tue, Jan 14, 2014 at 7:23 AM, Adrian Farrel <[e-mail]> wrote:

> > > >It helps against some attacks, but it doesn't help for others, right?
> > > >After all, if you are a US national, you might not trust that the
> > > >Chinese Telecom won't pass your traffic to the MSS.  (Or if you are a
> > > >German national, that AT&T won't decrypto your traffic and then pass
> > > >it off to the NSA...)
> > > yep. IPsec, under the control of a subscriber, offers more protection,
> > > in princple.
> >
> > Or put another way, MPLS-mediated encryption violates the end-to-end
> > principle.  It also allows ISP's to violate net neutrality principles
> > as well (i.e., by allowing them to do deep packet inspection and then
> > prioritizing some traffic over others).
>
> Two things here (probably wandering into a minefield, but that's my ball
> that
> rolled in):
>
> 1. "Allows" the ISP to do DPI? Nothing allows DPI apart from regulators,
> morals,
> or encryption of the pieces that might be deeply inspected.
> You might as well say that not shooting elephants allows ISPs to do DPI!
> So, I think what you are saying is that not doing IPsec on your (IP)
> traffic
> allows the ISP to do DPI.
> But doing MPLS encryption also stops transit nodes from doing DPI, but it
> does
> not stop edge (i.e., MPLS end) nodes from doing DPI.
> In some deployments (carrier's carrier, MPLS-based enterprise over ISP) the
> traffic may already be MPLS, and so MPLS encryption might be what is
> available.
>
> 2. I think the end-to-end principle may already have been somewhat diluted
> by
> the introduction of edges, and the deployment of tunnels. I am guessing
> that you
> mean that the responsibility for securing traffic lies with the
> originator/consumer of the traffic. And that is largely fine, but again
> runs
> into VPN type discussions.
>

People should read the end-to-end paper before they recite it as holy lore.

End to end is an argument about the consequences of where a design places
complexity. It only considers the end and the center of the network. The
edge is not really acknowledged as an option because it didn't exist when
the paper was written.

Mail has not been end-to-end for at least 20 years. It turned into an
end-to-edge-to-end protocol in the mid 90s and it has been an edge-to-edge
affair since SUBMIT and IMAP became the norm.

The end to end argument is useful but end-to-end ideology is positively
harmful.


End to end ideology in security is particularly harmful because there are
some security controls that are simply not compatible with end-to-end
approaches. You cannot protect against traffic or meta-data analysis
end-to-end.

Rather than contrast S/MIME and PGP being 'end-to-end' protocols against
STARTTLS being transport, it is rather more useful to recognize that S/MIME
and PGP are data level security rather than transport layer.

S/MIME provides end-to-end security but not metadata security. But people
seem to have largely missed the fact that S/MIME is actually capable of
providing data level security as a superset of end-to-end.

Why don't Word and Excel etc. just save all their documents in encrypted
CMS envelopes by default? Shouldn't this be a priority now we are moving to
the cloud?

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