Snowden's NSA Leaks Gave IETF a Needed Security Wake-up Call

alphadogg writes "Security and how to protect users from pervasive monitoring will dominate the proceedings when members of Internet Engineering Task Force meet in London starting Sunday. For an organization that develops the standards we all depend on for the Internet to work, the continued revelations made by NSA whistleblower Edward Snowden have had wide-ranging repercussions. 'It wasn't a surprise that some activities like this are going on. I think that the scale and some of the tactics surprised the community a little bit. ... You could also argue that maybe we needed the wake-up call,' said IETF Chairman Jari Arkko. Part of that work will also be to make security features easier to use and for the standards organization to think of security from day one when developing new protocols."

Comments

They will destroy your reputation

[Anonymous Coward]

Go ahead. NSA will destroy you if you do anything that actually secures the internet.

two words: trusted proxy

[bazmail]

they still suggest things that hep the spy agencies like utterly retarded "trusted proxy" garbage. they are either still asleep or part of the spying apparatus.

Re:two words: trusted proxy

[jonwil]

We need to replace both SSL/TLS AND the broken CA cert model with a new security system specifically designed so its NOT possible to build such a "trusted proxy" or otherwise MITM the connection even if you control the client (i.e. all those corporate solutions that require a special root certificate on the client and then use that to proxy SSL in a way that users generally wont notice unless they start looking at the certificate details)

Re:two words: trusted proxy

[mlyle]

Uh.. secure communications for the client even if the adversary controls the client? Good luck with that.

Re:two words: trusted proxy

[jonwil]

What I meant was more along the lines of preventing someone like, say, an IT shop at a big company from being able to install a "trusted client certificate" from one of those SSL proxy server things (websense etc) and MITM SSL that way.

(cue IT guys saying "but we have to do that because xyz stupid law requires we monitor everything going in and out and if we cant monitor SSL traffic, we would have to block it and break half the internet")

Re: two words: trusted proxy

[Anonymous Coward]

I'll give you a hint. If it involves a premise of "trusted" it can't be.

Re:two words: trusted proxy

[AHuxley]

Yes your back to one time pad and number station, your family, village, tribe, faith, cult, community, country vs the Tempora http://en.wikipedia.org/wiki/T...

Re:two words: trusted proxy

[WaffleMonster]

We need to replace both SSL/TLS AND the broken CA cert model with a new security system

I think care is needed in understanding the difference between failures of technology vs. failure in implementation.

For example the technology to enable PKI may be sound however deploying SSL CA's in the manner they have with hundreds of redundant, global, overlapping CAs may prove to be unreasonably difficult to secure or trust.

specifically designed so its NOT possible to build such a "trusted proxy" or otherwise MITM the connection even if you control the client

Every possible security protocol which will ever exist requires a useful source of trust as the basis for useful operation. Without trust security is ALWAYS a useless illusion.

If an untrustworthy source controls all the inputs and all the outputs there is no trust in that system, no sophisticated cryptographic concept or any amount of wishful thinking will ever change this.

If it is not an untrusted cert it will be manipulation of the browsers security stack or rendering system. About as pointless as implementing RFC 3514.

oh really.. what about a but of a clean up first?

[Anonymous Coward]

And yet, despite the clear conflict of interest, an NSA employee remains in a position of trust in a cryptography standard. No accusation against the guy since don't know him. However, if you or I got caught trying to damage the standard we were working in, we'd get sued. If he got caught he'd just be told to be more careful next time. It is totally inappropriate and the IETF should act.

Damn! Ghostery blocked 13 tracking scripts

[evanh]

And that's with scripting disabled even. NetworkWorld is a whore.

Re:oh really.. what about a but of a clean up firs

[Anonymous Coward]

just to answer the bullshit "the co-chair can't influence the standard he's working on line"; remember, if he works for the NSA, he already knows where the problem in the standard is. If he notices someone working in that direction, all he has to do is ask a few extra favors and they won't have time to spot the problem.

Article

[DaMattster]

This article is an example of poor technology journalism. The article offered a pathetic excuse as to why security has not been implemented: it's too complex and difficult. No one ever bothered to write a good user interface for the security mechanisms. Most of the security tools are written to be used by engineers. Why not make a user interface that glues together these tools so that every Tom, Dick, and Harry can use them? It isn't necessary to use such complex tetminology either. I'm not saying dumb it down completely but make some tools for the less computer savvy.

Re:Article

[houghi]

I was also looking at the ease of use part. How many people do encrypt their email? And I mean because of reason, not because they are geeks.
I am talking about the CEO sending messages that should stay secure.

I think the reason they do not encrypt their email is because it is not implemented in the email client as a standard and doing so is not easy enough.

"But there is XYZ that they ciould use/do." Well, they don't and that is a serious problem.

Re:Article

[IamTheRealMike]

Er, it is implemented in the client! S/MIME has been implemented by all non-webmail clients for years. When used correctly it's more or less transparent: every email is signed (you get an smime.p7s attachment), and if you receive a signed mail and have S/MIME configured too, your client can/will automatically encrypt the response.

But there are reasons it's not widely used: in the consumer space, most people don't bother getting an email address cert (even though Comodo and StartSSL give them away for free, it takes 2 minutes). And in the corporate space, often you don't actually want employees using end to end encryption, because you need the ability to do things like have internal messaging archives that are searchable, you need the ability to do document discovery when you get sued, employees suck at key management and keep losing them, etc.

Encrypted asynchronous messaging is just a tremendously hard problem. Look at agl's Pond project to get a flavor for what doing it seriously takes.

I don't think the IETF woke up at all...

[QuietLagoon]

No, I Don't Trust You! -- One of the Most Alarming Internet Proposals I've Ever Seen

If you care about Internet security, especially what we call "end-to-end" security free from easy snooping by ISPs, carriers, or other intermediaries, heads up! You'll want to pay attention to this.

You'd think that with so many concerns these days about whether the likes of AT&T, Verizon, and other telecom companies can be trusted not to turn our data over to third parties whom we haven't authorized, that a plan to formalize a mechanism for ISP and other "man-in-the-middle" snooping would be laughed off the Net.

But apparently the authors of IETF (Internet Engineering Task Force) Internet-Draft "Explicit Trusted Proxy in HTTP/2.0" (14 Feb 2014) haven't gotten the message.

What they propose for the new HTTP/2.0 protocol is nothing short of officially sanctioned snooping.

Re:I don't think the IETF woke up at all...

[goddidit]

From what I understand from the RFC, the proposal is actually trying to protect from local eavesdropping when accessing http-resources. I.e. you define a trusted proxy, and use HTTP2 with TLS to access insecure HTTP resources through it. This does not offer end-to-end security, but offers protection for the user against local adversaries, such as their ISP.