back to article Idea to encrypt stuff on the web at rest hits the IETF's Standard Track

Amid the rise of HTTPS, there are still many spots where content shifted encrypted across the web is ultimately stored in wide-open plain text, so a Mozilla engineer wants to close one of those gaps. In an Internet Engineering Task Force RFC published this month, a proposal by Martin Thomson (also a member of the Internet …

  1. Your alien overlord - fear me

    Won't this annoy the Five Eyes?

    1. Anonymous Coward
      Anonymous Coward

      That may be their intention.

    2. Voland's right hand Silver badge

      It's at rest - it will annoy the hell out of anyone trying to riffle through the web cache on your machine to see what did you browse. Police, Best Buy's bounty hunters, etc.

    3. Anonymous Coward
      Anonymous Coward

      it is absolutely vital and fundamentally needed to authenticate content

      otherwise, the Daily Fail page that I am reading might be differently sourced/presented to the Daily Fail page that Maybotities/Corbynettes are reading, and they in their bubbles could see different pages/content. That way lies madness & chaos. All solved by a quick hash & confirm. Sir Tim, get on it!

      Five Eyes TLA have a job to do , and they could still do it when all webpages are authenticated, but it might stop the online bandits with even less morals

  2. John Smith 19 Gold badge
    Unhappy

    Essentially it's a move toward untrusted hosting, which sounds like any cloud server to me

    But how good is the security with HTTPS?

    The real challenge for effective privacy with TCP/IP will be the routing data.

    How the f**k do you encrypt routing data (IE The headers) but still make them usable?

    1. Anonymous Coward
      Anonymous Coward

      Re: Essentially it's a move toward untrusted hosting, which sounds like any cloud server to me

      Does not Onion do this to some extent? It would be slower, but you could add key/route for each hop, where only each hop knows 1 thing (or close to) and not everything.

      1. Anonymous Coward
        Anonymous Coward

        Re: Essentially it's a move toward untrusted hosting, which sounds like any cloud server to me

        Toss up between trust and major inefficiency...

        Do I need my tinfoil hat on all the time?

        1. Doctor Syntax Silver badge

          Re: Essentially it's a move toward untrusted hosting, which sounds like any cloud server to me

          "Toss up between trust and major inefficiency."

          You sound surprised that implementing something, in this case trust, should have a computational cost greater than not implementing it.

          1. Anonymous Coward
            Anonymous Coward

            Re: Essentially it's a move toward untrusted hosting, which sounds like any cloud server to me

            It's a network traffic cost, not a computational cost. The former is vastly more expensive.

    2. John Smith 19 Gold badge
      Unhappy

      "The real challenge for effective privacy with TCP/IP will be the routing data."

      The best I can come up with was some kind of token which is compared when the packet gets to its destination (matching token == destination) and a return token that indicates a "direction" in which the packets needs to "diffuse" in order to get it nearer to its destination, rather than an actual path to follow.

      Sadly I have no idea how you'd encode that idea of "direction" or wheather that "token" should be the same for all packet streams going to or from the same end point, or different ones for each different session with that end point, or how you stop MIM attacks by token spoofing etc. Not to mention sizing this so it can accommodate the size of the internet, as well as allowing for future growth.

      Basically I'm just not smart enough to figure out how to solve this problem.

      But I really hope someone can....

  3. Anonymous Coward
    Anonymous Coward

    "Using this content coding requires knowledge of a key. How this key is acquired is not defined in this document."

    So, a particular client can PUT an encrypted file or GET an encrypted file, but this is only useful if the symmetric key has been previously agreed with the server or content owner.

    It would probably be simpler to use an application/pgp MIME type.

    The advantage of the mechanism in this RFC is that some limited random access to the encrypted content is possible.

    1. Anonymous Coward
      Anonymous Coward

      Sharing a key via impossible to crack methods (that is snoop) is getting trivial. Look up shared public keys etc.

  4. Mark 65

    AES 128

    Rather, Thomson's RFC suggests using AES 128 in Galois/Counter Mode.

    By choosing AES 128, and given the amount of time this may take to come to fruition, are we not MD5/SHA1-ing ourselves here? It's just possible by the time this gets implemented AES 128 is not as safe as it used to be. Given the amount of processor power available in just about any chip these days, especially when you can have embedded AES circuitry, should we not be shooting for AES 256 just to be on the safe side?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon