Forgot your password?
typodupeerror
The Internet Privacy Security

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

Posted by Soulskill
from the don't-hit-the-snooze-button dept.
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by Anonymous Coward
    Go ahead. NSA will destroy you [firstlook.org] if you do anything that actually secures the internet.
  • by bazmail (764941) on Saturday March 01, 2014 @05:03PM (#46377685)
    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.
    • by jonwil (467024) on Saturday March 01, 2014 @05:21PM (#46377783)

      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)

      • by mlyle (148697) on Saturday March 01, 2014 @05:25PM (#46377817)

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

        • by jonwil (467024) on Saturday March 01, 2014 @05:42PM (#46377901)

          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")

          • (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")

            Why do you have a problem with that? They should just let employees shuttle corporate trade secrets out of the company via a web browser because you feel like doing your personal banking on a work computer?

            Make the case for giving every employee unrestricted Internet access from a computer connected to t

          • How do you intend to stop IT departments reconfiguring computers they themselves purchased?

            I don't think you thought that one through. At all. It's not even a reasonable goal.

        • by AHuxley (892839) on Saturday March 01, 2014 @06:00PM (#46377995) Homepage Journal
          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... [wikipedia.org]
      • by WaffleMonster (969671) on Saturday March 01, 2014 @06:53PM (#46378259)

        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.

      • by manu0601 (2221348)

        We need to replace both SSL/TLS AND the broken CA cert model

        Here is a proposal: DNSSEC ensures DNS record integrity, so use it to publish domain-specific CA. If you need to connect to www.example.com, get example.com's CA from the DNS, and use it to validate www.example.com certificate.

  • by Anonymous Coward on Saturday March 01, 2014 @05:22PM (#46377797)

    And yet, despite the clear conflict of interest, an NSA employee remains in a position of trust in a cryptography standard [arstechnica.com]. 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.

    • by 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.

  • It's about time... There are many standards that the IETF has domain over that are weak and some that should be considered wholly insecure and not recommended or deprecated. These were developed when we were much more trusting of our neighbors on the Internet. Hopefully they'll start taking this to heart when it comes to new standards.

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

  • Article (Score:5, Interesting)

    by DaMattster (977781) on Saturday March 01, 2014 @05:36PM (#46377871)
    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 (Score:5, Interesting)

      by houghi (78078) on Saturday March 01, 2014 @05:53PM (#46377963)

      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.

      • 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,

  • by QuietLagoon (813062) on Saturday March 01, 2014 @05:41PM (#46377897)
    No, I Don't Trust You! -- One of the Most Alarming Internet Proposals I've Ever Seen [vortex.com]

    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.

    • Any Idiot can right a RFC-Draft, they don't even have to know anything about networking.

      • by Anonymous Coward

        Any Idiot can right a RFC-Draft, they don't even have to know anything about networking.

        I dunno about that. I'm pretty sure any idiot can write one, but I think they'd have to have some skill to right it if it's stupid.

    • by goddidit (988396)

      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.

    • by ale2011 (2486668)
      MITM proxies are among us, and there is nothing the IETF can do to stop corporate networks forcing their clients into such bad practice. The proxy sinthesizes a certificate for each https requests made by the client. The client has to trust the corporate CA, of course. There are various shortcomings with that model. For example, for opt-out to be occasionally possible, the client browser needs to know about the MITM proxy, rather than unwittingly trust the corporate CA. The "Explicit Trusted Proxy in H
  • In November IETH already almost promised that [slashdot.org]. Now we are holding our breath. Please hurry. Thank you.
    • by AHuxley (892839)
      So we get great changes to how packets move and their origins while moving. This would have made any city, state, federal or intergovernmental efforts for tracking not so easy in past years.
      The reason we seem to be getting all the good crypto news and 'fixes' might be that the vast illegal domestic spying programs have move on and are now ready for any such changes to the internet.
      The next step seems to be "NSA head floats idea: What if we only gathered terrorist communications?" Mar 1 2014
      http://arstec [arstechnica.com]
  • These guys work 24/7 with a budget beyond most corporations to ensure they are one step ahead of everyone and can access any piece of information they want to get to.

    Short of never connecting your computer to a public network (and even that might not cut it [slashgear.com]), You're fighting a losing battle against these guys. If there's any technology out there you could truly use to secure yourself against the NSA, they'll do everything to make sure it never sees the light of day.

    The only way to really combat this, is t

  • The IETF is deprecated, and can never be trusted. They have always been against security, as demonstrated by HTTP and HTML's lack of interaction with TLS/SSL.

    We already have HTTP-Auth using hash based proof of knowledge via HMAC with a server nonce. So, when deciding to add encryption to the Internet we could have just taken the output of the existing HTTP-Auth -- the proof of knowledge -- and key your symmetric stream ciphers with it instead of sending the proof back and forth in the clear. See?

    Yes, thi

"The Street finds its own uses for technology." -- William Gibson

Working...