Hi, Willi
Phillip, if you use B), you don't need A).
Consider email. If you and I were to use PGP or S/Mime encryption nobody can read the content of our messages. However, without transport-layer (or IP-layer. I’m an IPsec guy) encryption between the gmail server and the riseup.net server, anyone monitoring the traffic can know that I am sending you an email. Protecting SMTP with TLS makes the connection only expose that someone of gmail is sending a message to someone on riseup.net. And “someone on gmail” is close to being half the Internet. So you really still need A.
Of course we are still vulnerable to Google or riseup.net informing on us. Maybe we need some (E) about trustworthy intermediaries. And how do you want to prevent traffic analysis? In a telekcommunication system, where all actors are privat companies and act for the state institutions and with a star topology, you will never be able to prvent any form of traffic analysis.
Your writing is a little bit naive for me.
Well, TLS 1.3 and IPsec have some anti-traffic analysis feature, but there is little evidence of anyone using this effectively.
Yoav greetings, willi On 13/03/2017 20:13, Phillip Hallam-Baker wrote: I think this particular failure demonstrates the situation pretty well:
http://www.zdnet.com/article/leaked-us-military-files-exposed/
A) Without transport encryption, every network link is a potential point of
compromise via traffic analysis.
B) Without end-to-end data level encryption, every non endpoint device,
every hard drive or removable storage is a potential point of compromise
C) Without end point security, the end points are a potential point of
compromise.
D) Without trustworthy personnel, you are vulnerable to an insider threat.
The security controls you need depends on your information security assets
and your security concerns.
If you are a high level security target then you need A + B + C + D. They
are not alternatives, they are all requirements. It is really completely
unhelpful for people to suggest tackling these separable concerns
separately is 'useless'.
Just as I would not consider personnel or physical security at the same
time as end point security, I do not want to consider data level security
at the same time as end point.
To get back to the CIA leak, that 'hole you can drive a truck through' did
not actually exist when the AV package was connected to the Internet. What
we are seeing here is not a set of vulnerabilities, it is a set of research
notes being compiled by people searching for vulnerabilities that has
subsequently been exfiltrated, filtered to remove the good stuff and
dumped.
If you do end point security right, you can really be a 'PITA' to the
people trying to break these systems. So the idea that end point security
is futile is utterly misguided. If you use default deny approaches, end
point security can be very effective. But end point security really isn't
in scope for IETF unless we were to get into protocols for attestation of
trustworthy hardware or the like.
The reason I keep coming back to the data level security issue is that
1) It is in scope for IETF. Data level security protects data at rest and
in motion.
2) There have been recent expiries and are imminent pending expiries of key
IPR that makes a solution much easier.
3) It is one of the things we can fix that has the greatest security payoff.
|
Attachment:
signature.asc
Description: Message signed with OpenPGP