On Tue, May 17, 2016 at 5:57 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
Hi Bert,
On 17/05/16 10:41, Bert Wijnen (IETF) wrote:
> Jari, would you have some more info (maybe popinters) about
>
> The IESG also got an update on “Cryptowars” situation from Jeff
> Schiller.
>
> When I look up "cryptowars" on google, I get many many hits on a wide
> variety of "cryptowars". So I'd like to know which specific ones
> were discussed or cause us specific worries.
No pointers to the talk, sorry - Jeff was kind enough to speak without
notes or slides, (which was great:-). He recounted the 1990's era
history of crypto export controls, the issues covered in their "keys
under doormats" report, [1] and some consideration of more recent
events such as the USG/Apple case and how similar issues might play
out in future. (My own not at all startling prediction: ongoing
tensions between law enforcement and all of us working to improve
security and privacy are sort of inevitable it seems.)
>From my POV this was a great way to bring ADs who don't follow
the minutiae up to speed on these topics, but didn't set out any
particularly new direction for work in the IETF.
(Thanks go to Jeff for the talk and to Kathleen who organised it.)
Cheers,
S.
[1] http://115.69.40.134/files/editorials/files/MIT-CSAIL-TR-2015-026.pdf
One thing we did in the 1990s which I now regret as a mistake was that we ended up developing security protocols where the first priority was to defeat government intercept rather than meet users needs.
Unlawful intercept is of course a very serious problem but it is not the only problem our users face nor is it the necessarily the most serious concern. Nor for that matter is targeted unlawful intercept the same problem as mass surveillance.
One consequence of treating Louis Freeh's FBI as the principal threat was that we ended up with a lot of security protocols that were perfectly secure but almost nobody deployed and even fewer used. end to end security is only good security when people use it.
Right now I am working on technology that makes end-to-end security practical and usable. Using off the shelf mail applications with the Mathematical Mesh is actually easier than using them without. But there are some features I have added to meet real end user needs that we would never have considered in the 1990s. In particular a key backup and recovery option that is turned on by default.
Why do real users need key recovery? Well without the ability to recover a lost key, a protocol that encrypts stored data becomes worse than ransomware. There isn't even the option of paying a criminal to get your data back.
Another mistake we made was to consider end to end security to be the be-all and end-all of security. I like end to end security. The Mesh is designed as an untrusted cloud precisely because I consider end-to-end security important. The Mesh cannot be breached because none of the data stored in the Mesh is confidential. The only places confidential data is not encrypted is at the endpoints.
But end to end security has serious costs. You can't have end to end security without a key infrastructure. And until the Mesh there hasn't really been a key infrastructure that was designed for use by non-expert users. And end to end security isn't the 'best' security, it is only one form of security. End to end doesn't provide protection against metadata or traffic analysis. The Mesh has end-to-end and transport layer security. The most critical operations even have a third layer of encryption. And I can give a security rationale for each.
Another critical security technology that we managed to allow ourselves to be persuaded was 'evil' is trustworthy computing. As a result the WebPKI and code signing infrastructures use private keys that are stored on the machine itself, in many cases in plaintext but with security through obscurity at best. But we have the technology that would allow us to bind those private keys to servers in such a way that they can be used but not extracted without physical access to the machine itself and a significant degree of technical effort.
So lets make sure we don't make the same mistake this time round. Transport layer security and key escrow have security liabilities as well as benefits. Trustworthy computing is a tool that we can and should be using to make our users secure.
What is popular and commonly agreed in computing isn't always the right thing. Security is allowing our users to control risk, not defeating the political objectives of Louis Freeh or the RIAA.