PHK: HTTP 2.0 Should Be Scrapped

Via the HTTP working group list comes a post from Poul-Henning Kamp proposing that HTTP 2.0 (as it exists now) never be released after the plan of adopting Google's SPDY protocol with minor changes revealed flaws that SPDY/HTTP 2.0 will not address. Quoting: "The WG took the prototype SPDY was, before even completing its previous assignment, and wasted a lot of time and effort trying to goldplate over the warts and mistakes in it. And rather than 'ohh, we get HTTP/2.0 almost for free', we found out that there are numerous hard problems that SPDY doesn't even get close to solving, and that we will need to make some simplifications in the evolved HTTP concept if we ever want to solve them. ... Wouldn't we get a better result from taking a much deeper look at the current cryptographic and privacy situation, rather than publish a protocol with a cryptographic band-aid which doesn't solve the problems and gets in the way in many applications ? ... Isn't publishing HTTP/2.0 as a 'place-holder' is just a waste of everybody's time, and a needless code churn, leading to increased risk of security exposures and failure for no significant gains ?"

Comments

Encryption

[neokushan]

I hope that whatever HTTP2.0 ends up being enforces encryption by default.

Re:Encryption

[Anonymous Coward]

No, you really don't. Encryption is good for Facebook, but enforcing it for your Internet-of-Everything lightbulb or temperature probe in the basement gains nothing other than more complex bugs and lower battery life.

Re:Encryption

[Anonymous Coward]

Nice try NSA.

Re:Encryption

[jmv]

Last I heard, it still supports unencrypted, but only if both the client and server ask for it. If either one asks for encryption, then the connection is encrypted, even if there's no authentication (i.e. certificate). With no certificate, it's still possible to pull an active(MitM) attack, which is much harder to pull off at a large scale without anyone noticing (i.e. you can just collect all data you see).

Re:Encryption

[Blaskowicz]

I fear that would train users to mass click through certificate warnings, or even to install shady "helpful" software that will "manage" the problem for them.

Re:Encryption

[gweihir]

That is stupid. First, encryption essentially belongs on a different layer, which means combining it with HTTP is always going to be a compromise that will not work out well in quite a number of situations. Hence at the very least you should be able to leave it out, and either do without or use a different mechanism on a different layer. SSL (well, actually TLS) would have worked if it had solved the trust-in-certificates problem, which it spectacularly failed at due to naive trust models, that I now suspect were actively encouraged by various Three Letter Agencies at that time. In fact, if you control the certificates on both ends, TLS works pretty well and does not actually need a replacement.

That said, putting security for specific, limited (but widely used) scenarios in can be beneficial, but always remember that it makes the protocol less flexible as it needs to do more things right. And there has to be a supporting infrastructure that actually works in establishing identity and trust. In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.

Re:Encryption

[gweihir]

Nonsense. Enforcing encryption does not make things more secure, unless that encryption and the authentication going with it is flawless. That is very unlikely to be the case against an attacker like the NSA.

Re:Encryption

[Anonymous Coward]

I regret IPv6 isn't built around the Tor concept.

Re:Encryption

[abhi_beckert]

Last I heard, it still supports unencrypted, but only if both the client and server ask for it. If either one asks for encryption, then the connection is encrypted, even if there's no authentication (i.e. certificate). With no certificate, it's still possible to pull an active(MitM) attack, which is much harder to pull off at a large scale without anyone noticing (i.e. you can just collect all data you see).

A server cannot ask for encryption.

Unless the client establishes a secure connection in the first place, the server has no way of knowing if the client is actually who they claim to be. If the client attempts to establish a secure connection and the server responds with "I can't give you a secure connection" then the client needs to assume there is a man in the middle attack going on and refuse to communicate with the server.

There is no way around it, security needs to be initiated on the client and the server cannot be allowed to refuse a secure connection.

HSTS is a partial solution for this problem (http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security)

Re:Encryption

[jmv]

A server cannot ask for encryption.

AFAIK, HTTP2 allows the server to encrypt even if the client didn't want to.

Unless the client establishes a secure connection in the first place, the server has no way of knowing if the client is actually who they claim to be. If the client attempts to establish a secure connection and the server responds with "I can't give you a secure connection" then the client needs to assume there is a man in the middle attack going on and refuse to communicate with the server.

If you're able to modify packets in transit (i.e. Man in the Middle), then you can also just decrypt with your key and re-encrypt with the client key. Without authentication, there's just nothing that's going to prevent a MitM attack. Despite that, being vulnerable to MitM is much better than being vulnerable to any sort of passive listening.

Re:Encryption

[viperidaenz]

You're confusing encryption with authentication.

Re:Encryption

[AuMatar]

It doesn't need to be perfect. If cracking it still takes some time, it lowers their resources. And it can still be unbreakable for attackers with fewer resources at their disposal.

Re:Encryption

[msauve]

"more secure" != "perfectly secure." I don't think the NSA is interested in screwing with your mood lighting, but script kiddies might be.

Re:Encryption

[jmv]

Nothing is NSA-proof, therefore we should just scrap TLS and transmit everything in plaintext, right? The whole point here is not to make the system undefeatable, just to increase the cost of breaking it, just like your door lock isn't perfect, but still useful. If HTTP was always encrypted, even with no authentication, it would require the NSA to man-in-the-middle every single connection if it wants to keep its pervasive monitoring. This would not only make the cost skyrocket, but also make it trivial to detect.

Re:Encryption

[fuzzyfuzzyfungus]

They do. Unfortunately, the 'shady software' is "basically all client software that does SSL/TLS and is designed with end users in mind". Because nobody really wants to bite the bullet and scare the users, all major OSes and browsers 'trust' a horrifying number of dubious CAs unless manually configured otherwise.

Given the (lack of) alternatives, it's hard to blame them for doing that rather than being abandoned by users; but it's pretty much the state of play right now.

Re:Encryption

[AK Marc]

I control my home with a phone app. No encryption needed, I'm either wired or going through an encrypted wireless (yeah, not NSA secure, but more than "good enough"). And none of my home stuff talks HTTP. It's all proprietary. If you are worried about bugs and battery life, you wouldn't use HTTP either. HTTPS is not any different.

Re:Encryption

[gweihir]

Unfortunately, breaking the crypto directly is _not_ what they are going to do. Protocol flaws usually allow very low cost attacks, it just takes some brain-power to figure them out. The NSA has a lot of that available.

Re:Encryption

[Anonymous Coward]

I control my home with a phone app. No encryption needed, I'm either wired or going through an encrypted wireless

So Genius ... how's that phone app transmit commands to the system controlling your home? Oh yeah. Through the internet. It's as if security still matters there huh?

Re:Encryption

[gweihir]

On the minus side, your mood lighting may be a lot more expensive if it suddenly needs a significant CPU power upgrade and far more complex software.

Re:Encryption

[gweihir]

You are confused. The modern crypto we have _is_ NSA proof (as the NSA made sure of that). The protocols using it are a very different matter. These have the unfortunate property that they are either secure or are cheap to attack (protocols do not have a lot of state and hence cannot put up a lot of resistance to brute-forcing). Hence getting the protocols right, and more importantly, designing them so that they have several effective layers of security and can be fixed if something is wrong is critical. Unfortunately, that involves making very conservative choices, while most IT folks are starry eyed suckers for the new and flashy.

Re:Encryption

[swillden]

In order for the security to have any benefit at all, it must be done right, must be free from fundamental flaws and must give the assurances it was designed to give. That is exceedingly hard to do and very unlikely to be done right on the first attempt.

SPDY's security component is TLS. SPDY is essentially just some minor restrictions (not changes) in the TLS negotiation protocol, plus a sophisticated HTTP acceleration protocol tunneled inside. So this really isn't a "first attempt", by any means. Not to mention the fact that Google has been using SPDY extensively for years now and has a great deal of real-world experience with it. Your argument might hold water when applied to QUIC, but not so much to SPDY.

It really helps to read the thread and get a sense of what the actual dispute is about. In a nutshell, Kamp is bothered less that HTTP/2 is complex than that it doesn't achieve enough. In particular, it doesn't address problems that HTTP/1.1 has with being used as a large file (multi-GB) transfer protocol, and it doesn't eliminate cookies. Not many committee members seem to agree that these are important problems for HTTP/2, though most do agree that it would be nice some day to address those issues, in some standard.

What many do agree on is that there is some dangerous complexity in one part of the proposal, a header compression algorithm called HPACK. The reason for using HPACK is the CRIME attack, which exploits Gzip compression of headers to deduce cookies and other sensitive header values. It does this even though the compressed data is encrypted. HPACK is designed to be resistant to this sort of attack, but it's complex. Several committee members are arguing that it would be reasonable to proceed without header compression at all, thus greatly simplifying the proposal. Others are arguing that they can specify HPACK, but make header compression negotiable and allow clients and servers to choose to use nothing rather than HPACK, if they prefer (or something better when it comes along).

Bottom line: What we have here is one committee member who has been annoyed that his wishes to deeply rethink HTTP have been ignored. He is therefore latching onto a real issue that the rest of the committee is grappling with and using it to argue that they should just throw the whole thing out and get to work on what he wanted to do. And he made his arguments with enough flair and eloquence to get attention beyond the committee. All in all, just normal standards committee politics which has (abnormally) escaped the committee mailing list and made it to the front page of /.

Re:Encryption

[AK Marc]

A server cannot ask for encryption.

So a request to HTTP://www.example.com can't be redirected to HTTPS://www.example.com? Because I would consider that the server asking for encryption.

There is no way around it, security needs to be initiated on the client and the server cannot be allowed to refuse a secure connection.

Great, so when we go to all secure, we don't need any more 500 series error messages, as the servers aren't "allowed" to refuse connections.

Re:Encryption

[Anonymous Coward]

Are you going to pay for SSL certificates and apply them to every appliance and light bulb in your house? Even if you get free 1 year certificates through somewhere like StartSSL you still have to issue and apply all of those certificates to all those devices.

Re:Encryption

[Anonymous Coward]

> Enforcing encryption does not make things more secure, unless that encryption and the authentication going with it is flawless

What a load of bullshit. Even without strong authentication encryption with ephemeral keying _absolutely prevents_ passive attacks. This means that there can be no undetectable pervasive surveillance. What would motivate you to suggest that we shouldn't take that improvement?

Of course, without strong auth it's not "secure", but an encrypt only link shouldn't and wouldn't be advertised to the user as secure. It would just look like http. To get the "secure" behavior you need to use https, which has mandatory authentication.

Re:Encryption

[AK Marc]

So Genius ... how's that phone app transmit commands to the system controlling your home? Oh yeah. Through the internet. It's as if security still matters there huh?

Not through HTTP. Oh, never mind. You are too dumb to know the difference between HTTP and The Internet.

Re:Encryption

[Anonymous Coward]

sounds like a plan - cost based encryption. Encryption that is not particularly state of the art but just so multi-layered and verbose as to be a real pain to decypher.

Or better yet, a protocol that is polymorphic by nature, so they wouldn't even get to focus on 1 protocol, but there would be many.

Re:Encryption

[Anonymous Coward]

They are absolutely breaking crypto directly. Snowden's leaks evidenced a strongly compartmentalized and highly secret department in the NSA which breaks public key cryptography. By compartmentalized, I don't mean the software ACL crapware that they use for most stuff, and by secret I mean almost nobody knows precisely what their capabilities are. It still sounds immensely costly for them, and they only use it on high-value targets. (Which could still include, however, large companies which don't rotate keys often enough.)

The NSA uses all the tools at its disposal. And, frankly, it's the low-tech stuff that permits wide-field surveillance that is troublesome to me. If the NSA can crack 1024-bit RSA keys then good for them, as long as its costly enough that they can't be indiscriminate and lazy about it, and it isn't secretly used to prosecute people.

Re:Encryption

[complete loony]

Sure you need to actively modify network packets, rather than just monitor them. But without some form of authentication, man-in-the-middle attacks are trivial.

Re:Encryption

[complete loony]

There's a simpler solution. Keep using GZip compression, but expose the sensitivity of strings to the compression layer. You could ensure that sensitive strings are transmitted as separate deflate blocks without any compression at all, and ignored for duplicate string elimination. All HTTP/2 would need to specify is the ordering of these values so that the compression can still be reasonably efficient for everything else.

Re:Encryption

[fractoid]

Even lower cost is simply subpoenaing one end of the transaction. There's no point bothering with a cryptographic or man-in-the-middle attack when you control the man-at-the-other-end.

Re:Encryption

[TechyImmigrant]

>To get the "secure" behavior you need to use https, which has mandatory authentication.

You are wrong on many levels. Please understand cryptography and secure protocol design before you post.

Re:Encryption

[Anonymous Coward]

Enforcing encryption does not make things more secure, unless that encryption and the authentication going with it is flawless.

Wrong. Trivial thought experiment. Currently a very small percentage of internet traffic is encrypted. If suddenly all internet traffic were encrypted, the CPU time to decrypt it all would skyrocket. In fact, given a sufficiently advancing encryption scheme that took into account the client/server and Moore's law, one can imagine further enlarging keys/iterations. Even presuming the keys were included, the actual CPU/GPU/whatever cost to decrypt it all would tend to grow exponentially on top of the already significant growth in actual traffic growth.

Of course all the above is incredibly moot on the point that the NSA can't programically process even the very limited set of data that relates to suspected terrorists (presuming they could even reduce their mountain of data to just that) because there's too much noise to signal. Worse, odds are good that the noise to signal is so bad that even people who are experts can't do the job. That's the real lie of the intelligence community, that there is anything approaching the clarity to actually catch terrorist suspects pre-attack. Hell, they do a pretty horrible finding people post-attack--unless you think that the long delay for bin Laden's "capture" was some sort of clever strategy.

Now, if you want to argue that enforcing encryption doesn't make people safer, then that's another point. But then to go that route would have to begin with people having the real sort of outrage of what the NSA, CIA, FBI, Congress, and President have done. It makes one really consider who the enemy is.

Re:Encryption

[Anonymous Coward]

Actually you're wrong. By making everything encrypted no one can simply focus on the encrypted parts that you're sending

Re:Encryption

[tepples]

I think what the AC was trying to say is that the "http" scheme would use TLS encryption with no authentication of the other party, while the "https" scheme would use TLS encryption with the present PKI for authentication. What makes encryption with no authentication worse than plaintext?

Re:Encryption

[WaffleMonster]

Nothing is NSA-proof,

NSA proof is possible unless NSA includes goons armed with $5 wrenches.

The whole point here is not to make the system undefeatable, just to increase the cost of breaking it, just like your door lock isn't perfect, but still useful.

If you can't view traffic then traffic is safe from you therefore it is not necessary to encrypt traffic.

If you can view traffic then you have everything necessary to own that traffic.. TCP initial sequence number and fast pipe is all you need... nobody is doing any of the filtering necessary to prevent source address spoofing so these attacks are trivial.

If your data is going through a "great firewall", CGN (everyone using a cellular network) or other bump in the wire there is no reason not to expect opportunistic encryption to be MITMd in realtime and in bulk.

it would require the NSA to man-in-the-middle every single connection if it wants to keep its pervasive monitoring.

So everyone in US is safe from NSA bulk collection of websites they visit except bulk collection of IP layer headers, certificate identities sent in the clear during TLS handshake and the zillions of US corporations engaged in cross site stalking compelled to hand over "any tangible thing".

What is the opportunity cost of an encryption solution which solves nothing? What resources and demand are no longer available to be applied to a solution with teeth?

How do you explain to the user well their data might be encrypted yet their data is not protected since it is not trusted? I can see the eyes rolling and roar of millions of swooshes... All people know is "encrypted" and this means "safe" ... I see nothing good coming from introduction of this technical doublespeak.

Does HTTP 2.0 implement any latching or fingerprinting that could be useful to retroactively detect compromise of security? Do they even try?

Re:Encryption

[Splab]

Lately PHK has become more and more derailed. If you ever follow him on his local Danish blogs, he has gone totally off the rail - claiming all sorts of weird things, from major conspiracies to some far fetched claims against the EU.

Re:Encryption

[Anonymous Coward]

> gains nothing
It ensures nobody except the recipient of my communication can listen to it, which is far from nothing.

> more complex bugs
To a programmer, this statement sounds like "reversing the polarity" to a physicist. Namely, nonsensical.

> and lower battery life
Encrypting all your regular web traffic would have negligible effects on power drain. Modern computers are so fast that the additional computing power would barely register for a few hundred MB of data per day. Large volume sources such as video streaming can disable encryption where it's useful to do so.

Re:Encryption

[Anonymous Coward]

Fuck you're an idiot.

Why would my lightbulb or temperature probe have HTTP?

No, it wouldn't, that's fucking stupid.

And it DOES need encryption, particularly if it operates wirelessly which presumably it would. Otherwise some prankster could mess with my lighting or fuck up my homebrew.

And encryption results in virtually no added power consumption as there are literally hundreds of embedded uCs with hardware encryption.

Re:Encryption

[Aethedor]

http://regmedia.co.uk/2014/05/... says it all. Thinking that encrypting everything makes the internet more secure is really naieve.

Re:Encryption

[Anonymous Coward]

Why would you expect useful encryption from a commitee? Remember how well it worked with IPv6?

Re:Encryption

[jmv]

How do you explain to the user well their data might be encrypted yet their data is not protected since it is not trusted?

I'm talking about http here, not https. The idea is that even with http -- where you don't pretend that anything is secure -- you still encrypt everything. It's far from perfect, but it beats plaintext because the attacker can't hide anymore -- it has to be an active attack. I don't pretend to know all about the pros and cons of http 2, but plaintext has to die.

Re:Encryption

[Idimmu Xul]

No, you really don't. Encryption is good for Facebook, but enforcing it for your Internet-of-Everything lightbulb or temperature probe in the basement gains nothing other than more complex bugs and lower battery life.

arent these the exact situations where encryption is necessary? i dont want someone sniffing the plain text credentials of my fridge as they fly through the air and then turning the temperature up to 40 ...

Re:Encryption

[Anonymous Coward]

None of the low-cost, low-power, small-size uC have encryption hardware. AES is rather simple in software, but you won't even have the flash and RAM space to properly fit a SHA or RSA algorithm in the smaller ones.
So yes, mandatory crypto in HTTP definitely would mean these devices won't be using it. However they probably would struggle to use TCP (not to mention full HTTP) in the first place and you'd go with at most UDP, so it might not matter.

Re:Encryption

[mwvdlee]

Except that you might not want either end to know you're listening in.

Re:Encryption

[gweihir]

I think the only thing we know is that they would like to be able to break modern crypto directly. There is no indication that they can. Of course, they can brute-force DES or 512 bit RSA keys, but that is not going to help them a lot and that capability does not scale to , say, 128 bit symmetrical or 2048 bit asymmetrical keys. There are also indications that they _may_ be able to break some non-compromised ECC crypto and they likely know of ways to compromise elliptic curves in a way that allows them to cheaply (!) attack some ECC crypto. All of which is not a problem when algorithm selection is done carefully.

Note that sabotaging crypto is not the same as breaking it. Breaking crypto means successfully attacking non-sabotaged crypto. (Crypto lingo deviates a bit from common use here.)

Re:Encryption

[gweihir]

Indeed. Crypto is only ever going to help against mass-surveillance, not against targeted attacks against a small number of people. But that is the idea here.

Re:Encryption

[gweihir]

In that case, break in physically and "bug" the end-systems. Or burn a higher-value zero day exploit for a remote compromise.

Re:Encryption

[gweihir]

No, it does not. It needs to stay present as an option for various scenarios, from low-power devices, secure connections, whether local or secured in another way, to data that has no protection needs to plain simple debugging.

On the minus side, if everything is encrypted, a lot of people will falsely assume they are protected, which will be very far from the truth. Encryption is just one small building block to actual security.

Re:Encryption

[Anonymous Coward]

If breaking encryption requires MITM, you cannot do wholesale bulk surveillance without getting caught. This is a significant advantage over plaintext.

Re:Encryption

[gweihir]

Wrong, unfortunately. First, ephemeral keying is not enough, after all a man-in-the-middle works still without problem as long as it is there from the beginning. An encrypted-only link is basically worth less than a non-encrypted one, as it does not offer more protection, but gives the appearance of doing so. Second, the NSA has already tried to sabotage key generation several times, like with Intel RDRAND or with Dual_EC_DRBG. One guess what that primarily is useful for. And third, https is broken because the certification system is broken. It does not look like it can be fixed.

Your view of things is far too simplistic.

Re:Encryption

[Anonymous Coward]

Nothing is NSA-proof, therefore we should just scrap TLS and transmit everything in plaintext, right?

Next time you will sound smarter if you use cleartext instead of plaintext to describe unencrypted data.

Re:Encryption

[gweihir]

Simple: With encryption without authentication, many people will assume they gain some security when they are not. That makes them likely to risk more when they should not. Also, it has higher overhead and higher implementation complexity, increasing cost both for the implementation and the platform it runs on (thing small embedded devices, e.g., that can do (very basic) http even on small 8 bit controllers, but forget about fitting any crypto on the.

Re:Encryption

[gweihir]

If all traffic is encrypted, but trivial to break (as a protocol or other flaw can easily make it), then the decryption effort is not an issue. It can be done by dedicated hardware. Just to give you an idea, a current CPU does maybe 100MB/s AES per core in software but something like 2GB/s in its hardware AES engine. For a modern multi-core CPU, the AES performance is in the order of the main memory bandwidth, and the AES engine is just a tiny addition to the chip. Dedicated hardware is a few orders of magnitude faster.

Re:Encryption

[pklinken]

http://xkcd.com/538/

Re:Encryption

[Anonymous Coward]

A lot of people already assume that email (sent in plaintext, with no encryption) is secure. Yes, they are wrong, but that doesn't seem to stop them, now does it?

Re:Encryption

[rioki]

It makes man in the middle attacks trivially possible and thus rendering the encryption useless. The problem with channel encryption is that you need the share some form of keying material and if you don't authenticate you can't trust the keying material. The only cases where encryption without authentication sort of works is when the keying material is previously shared and you can reasonably assume that it was not compromised. But in the case of the web, this is basically impossible.

Re:Encryption

[rioki]

Interestingly in the above case encryption is almost irrelevant. What are you doing with the information that he turned on the light bulb 23 and switched of his AC? The important bit here is authentication and that can be trivially don without channel encryption. You still need an "encryption" scheme like an HMAC for the authentication though.

Re:Encryption

[TheRaven64]

Within my house, I'd expect the certificates to be issued by the control system and I'd expect two-way validation: no one can talk to my lightbulbs unless they have a client certificate issued by my house control system CA. Oh, and I also wouldn't expect to use HTTP...

Re:Encryption

[rioki]

Despite that, being vulnerable to MitM is much better than being vulnerable to any sort of passive listening.

Although this was sort of my sentiment too, but it basically is false. Passive listening on WiFi connection may be foiled, to a certain degree. But the moment someone has access the the wires the game is over no matter how you play it. Passive listening that requires penetrating a device or inserting hardware, is basically MitM and as a result going from passive listening to active MitM attack is basally just upgrading the software.

Re:Encryption

[rioki]

Except that HTTP 500 is a proper and valid response when it comes to the HTTP. Following your oddball logic a 404 would also be "refused", what nonsense. The server accepted the connection, the request handler for that resource crapped it's pants and the server is dutifully informing you of that fact. What is "not accepting the connection", where? The fact that you got a 500 means the server accepted your connection. Even a 401 Unauthorized is technically an accepted connection, since the authorization is for the resource not the server.

Re:Encryption

[TheRaven64]

With encryption without authentication, many people will assume they gain some security when they are not

The do gain some security. They gain security against passive adversaries. They don't gain security against adversaries who are able to intercept and modify their traffic. The question is whether the first threat model is a sensible one to care about. Given that we now know that there is at least one global passive adversary (and likely others who didn't have a Snowden), it seems sensible to me.

Also, it has higher overhead and higher implementation complexity, increasing cost both for the implementation and the platform it runs on (thing small embedded devices, e.g., that can do (very basic) http even on small 8 bit controllers, but forget about fitting any crypto on the

Most IoT platforms are looking at using the ARM Cortex-M0 (or M0+) as the client devices. At the data rates required for IoT tasks, this can easily keep up with the demands of modern crypto. If it can't, then an accelerator is only a few thousand extra transistors for your SoC.

Re:Encryption

[msauve]

You don't know how technology advances or how amortization works, do you?

Re:Encryption

[neokushan]

You've confused encryption with authentication. It doesn't need to be authenticated, the idea is to stop drive-by starbucks script kiddies, mass surveillance. Targeted attacks will always be an issue, even with strong, well auth'd encryption.

Re:Encryption

[neokushan]

With encryption without authentication, many people will assume they gain some security when they are not.

Not at all. It would appear to the user like any non-TLS site does today - standard address bar, no padlock, nothing. What goes on in the background doesn't matter as far as the user is concerned. In fact, I'd be surprised if many users have even considered that their data is being sent plaintext on the majority of sites. Changing the background to be encrypted would be a good way to block a lot of passive surveillance without making users feel as though their entire online doings are protected without the padlock.

Re:Encryption

[printman]

RFC 2817 defines how a server (or a client) can require TLS. It is widely deployed for printers but less so on the Internet due to proxies not supporting it.

Re:Encryption

[Anonymous Coward]

[citation needed] Please compare the cost of harvesting unencrypted email on the open internet with your low cost attack on encrypted protocols

Re:Encryption

[Antique Geekmeister]

> Nothing is NSA-proof, therefore we should just scrap TLS and transmit everything in plaintext, right?

I'm afraid that this is a common approach. I've seen numerous system designers refuse to enable encryption on their internal websites or unternal softwre on the basis that "if they're inside our networks, we'e got much bigger problems". It's one of the mantras of bad engineers, much like "there's no point to documentation, just read the code".

Re:Encryption

[Anonymous Coward]

This is rubbish.

Encryption without any sort of PKI can ensure that multiple sessions connect to the same entity over time. Thus even without PKI and only encryption your man-in-the-middle would have to be there on all connections, regardless of the network you are operating on.

If properly implemented, the man-in-the-middle MUST intercept the first connection between you and your bank or between you and the lightbulb.

You clearly do not fully understand what PKI-less encryption can do.

Re:Encryption

[Chrisq]

No, you really don't. Encryption is good for Facebook, but enforcing it for your Internet-of-Everything lightbulb or temperature probe in the basement gains nothing other than more complex bugs and lower battery life.

By default is not the same as being mandatory. I don't see anything wrong in principle in having the endpoints explicitly agree to use an unencrypted connection. In practice I'd only want if it it did not add a significant overhead or make it more difficult to set up a server without certificates.

Re:Encryption

[Anonymous Coward]

I hope that whatever HTTP2.0 ends up being enforces encryption by default.

...which will happen right after the watchers take control of every CA out there.

....which ironically may already be in place.

Re:Encryption

[geekmux]

No, you really don't. Encryption is good for Facebook, but enforcing it for your Internet-of-Everything lightbulb or temperature probe in the basement gains nothing other than more complex bugs and lower battery life.

While you tried to make a good point here, your example was horrible.

Being concerned about Facebook encryption is like gift-wrapping an elephant with a piece of string.

Your password is about the only damn thing not shared or sold on that site, so I'm not sure what the hell anyone is trying to hide or secure.

Re:Encryption

[Anonymous Coward]

This is why we should just use HTTP Auth, or update it so that we can. I mean, we already have pre-shared secrets with all the places we need secure.

Client sends: UserName, Nonce1
Server sends: Nonce2

Both perform: Auth1 = HMAC( Passhash, Nonce1 + Nonce2 ); Where + is concatenation and Passhash is PBKDF2 or keystretching, etc. of the user password. The server can store the hashed version. Hash because: Fuck length and special chars limits.

There are a few different ways to do the HMAC, maybe including the domain, etc. That's already in your Digest Authentication protocal and working for password protected resources. The browser brings up a PW dialog (which it can also remember & autofill) -- No more bullshit like when google breaks FF password remember by hiding the account field. Not autofilled? You're probably at the wrong site (or on a new device), cuts down on spoofage.

OK, typically we just get our proof of knowledge and send it to the server. Then the server knows you have the same password without exposing your password. But that's fucking retarded, come the fuck on IETF how evil are you? Take the Auth1 proof of knowledge and KEY THE MOTHER FUCKING STREAM CIPHER WITH IT. There, now you have end to end encryption that no MITM can fuck with (besides DoS). Even if they intercept it, the connection is encrypted at that point. They couldn't have set up a connection in the middle because they don't have your passhash, so the MITM wouldn't be able to generate Auth1 and send/receive any data, they can just pass it through.

This would give you actual security. You could go to your bank and set up a password. You could exchange passphrases with friends in person and encrypt to them without fear of MITM. Currently the CA system inserts a potential MITM in every connection, and we know that VeriSign was doing just that.

Now, if you don't exchange the key out of band, then just use a Diffie Hellman key exchange, or network perspective to set up the initial connection and exchange the PW. Immediately drop that connection and reconnect using the HTTP Auth to Keyed Stream Cipher method. No more Public Key Crypto required when you have a shared key. You can even ditch PKI / CA system and use network perspective to detect the self-signed cert or current public DH key part.

Also note: once you have one or more pre-shared keys with any enpoints you could use them as a proxy just to get the certs or DH key when you're creating a new account. They can be your 3rd party trust to help defeat MITM -- They'd have to actively MITM everyones routes all the time to keep it up. This also allows you to choose who you trust, instead of having to trust the CA that the site trusts.

Anyhow, the main thing is to drop the certs ASAP (after account creation) and proceed to stream cipher since anyone with the cert could MITM the connection -- It's a single point of failure. Better to use the DB full of individual PWs.

Now, the server could hand a SessionID cookie to the client and inside it could be encrypted versions of a timestamp, UserName, and Auth1, and a hash for integrity. Only the server has the secret key to decrypt that cookie. This way they don't have to keep looking up in the database. Each new connection the client just sends the SessionID and the encrypted payload, the server can get the Auth1 and key up the connection. The sessionID cookie should be standardized and part of TLS, not HTTP. The auth protocol needs to be higher than HTTP, or we'll be using a non encrypted HTTP header to send just the sessionID and then upgrade the connection to encrypted TLS after that header. Either way, we'll be passing some of the functionality of HTTP into TLS / SSL: Keyed Ciphers.

The reason we want SessionID apart form regular cookies is so that it's only ever sent on requests for resources on the same domain -- Never 3rd party, ever. That prevents it from being used as a 3rd party cookie, and

Re:Encryption

[gbjbaanb]

Makes no diference. If I stuck wireshark on your network, I'd see all the packets being sent and could read them quite happily.

If you haven't encrypted them, I'd be able to read them without any problem whatsoever. The difference between HTTP and Custom protocol in this case - no whatsoever.

All http gives you is a standard set of knowledge, routing, software and devices that know how to handle it. That's pretty useful, given that you're not anymore secure than if you used it. So you might as well use http.

Re:Encryption

[gbjbaanb]

DNSSEC gives you assurance that the domain you're connecting to is the server that says its hosting that domain. So you have no MitM attacks with un-authenticated encryption.

So splitting auth from encryption is a good thing, and can be done properly. You can have both, but at the moment you can only have both or none. None, is obviously not good.

Re:Encryption

[rioki]

To quote myself:

The only cases where encryption without authentication sort of works is when the keying material is previously shared and you can reasonably assume that it was not compromised

Reading comprehension much?

Re:Encryption

[AmiMoJo]

At least subpoenaing has some judicial oversight and is visible to the target. I know, the USA got rid of all that with National Security Letters and similar bullshit, but in principal forcing judicial oversight at the protocol level is a good thing and gives us something to work with.

Re:Encryption

[AmiMoJo]

There are already low power wifi chips that support WPA2. Crypto is slowly becoming a standard peripheral on low cost microcontrollers and radios (e.g. a â1 Atmel XMEGA supports AES in hardware). I have implemented protocol level encryption with user selectable keys over an 868MHz ultra low power (5+ years life from two AA cells) network for my job, so it definitely is possible.

Personally I wouldn't buy an internet connected device that didn't support encryption. Luckily even the cheapest, crappiest ARM system-on-chip with built-in wifi can do HTTPS.

Re:Encryption

[Anonymous Coward]

I wouldn't use RSA and I don't need SHA (though your assertion that SHA is difficult to fit in a uC is absurd). And like I said I don't need or want HTTP in my light sockets.

Having said that there are fucktons of uC that implement AES in hardware, particularly ones that integrate 802.15.4 PHYs which is exactly the sort of thing you would use in a wireless light or telethermometer.

For example, ok so 9x9mm is not exactly tiny, but there aren't many uCs smaller than that implementing radio PHYs. It has hardware AES, an 802.15.4 PHY, 128kb of program flash and 16kb of ram, plenty enough to implement an Edwards curve ECC scheme like Ed25519, or even RSA if you wanted to. I don't know why you would use RSA when it is slower, less secure and requires more memory than Elliptic curve crypto. It's also important to remember that you only need to compute a digital signature once for each association of the mote with the aggregator. Once you have agreed on an AES key for the association, you only need to use the hardware's AES instructions and compute a UMAC digest (fast) for each message. I would definitely use UDP. TCP is complex and not robust even when implemented correctly.

but you won't even have the flash and RAM space to properly fit a SHA or RSA algorithm in the smaller ones.

Oh really?

Recently a lot of authors studied the efficiency of elliptic curve cryptosystems on microcontrollers which are used in wireless sensor motes. They focus on the TI MSP430 and the ATmega128 developed by Atmel. Gura et al. first reported the efficiency of elliptic curve cryptosystems defined over prime fields on the ATmega128 in [16]. They used curves published in the recommendations of SEC[8]. The execution time of one ECDSA signature generation is 810 ms at 8MHz. Work by Uhsadel and Scott [22,26] further improves speed results on the ATmega128.

In this paper we will study the efficiency of optimal extension fields, prime fields as well as binary fields for the ATmega128. We will show, that the run times for a multiplication in GF(2^167) takes less than 1ms, if the memory accesses are decreased as much as possible. Furthermore we will take side channel attacks into account and measure the run times of elliptic curve scalar multiplication resistant to simple side channel attacks for several finite fields of different characteristic. It turns out, that binary fields are the optimal choice for elliptic curve cryptography if the Montgomery-Ladder can be used.

captcha: provoked

Re:Encryption

[DrXym]

Your Internet-of-everything lightbulb runs off batteries?

Re:Encryption

[Anonymous Coward]

Annual global IP traffic will pass the zettabyte threshold by the end of 2015 ...

So, at the end of 2015 it'll take ~17432 hardware AES engines just to decrypt the traffic*, ignore all the possible overhead of hashing, public/private key computation, etc. So, perhaps you're right on that front. Realistically, I don't see them actually managing anything close to 2GB/s sustained as once you start including any actual storage for that sort of data, the I/O delays are so substantial.

*This benchmark implies closer to 6GB/s in software/hardware, but it's hard to know from a benchmark how the real world results would be given how many times sha hashing or other steps might need to be taken. In fact the results imply that the first step would be to involve much more hashing into the protocol (with several iterations, several recomputations steps midstream, etc) That's one reason I included the caveat of scaling the problem to counter Murphy's Law as a protocol with a static iteration count that used an "effiicient" amount of CPU time for a 1994 computer * the world population's traffic is much less of an insurmountable obstacle today. If the protocol encouraged scaling the problem up, then at least the problem could be made several hundred times harder to crack, although I'll admit that eventually the new protocol would be done in hardware and eliminate most/all the gains. It's more of a rat race than a final solution. :/

Re:Encryption

[swillden]

Interesting suggestion. I don't think it's workable, though, because it would require web app developers to properly indicate which of their headers are sensitive. More of them would get it wrong than right.

Re:Encryption

[kodomo]

Server can force you to https, by redirecting your browser.

Re:Encryption

[swillden]

most IT folks are starry eyed suckers for the new and flashy.

New and flashy... like TLS?

Re:Encryption

[LordLimecat]

If you can passively listen, you can almost certainly insert stuff into the stream.

Re:Encryption

[LordLimecat]

I dont think you need to be deeply familiar with the issue to recognize his complaints as rubbish. Hes basically saying "what we have now isnt perfect, so we should go back to committee for about 15 years before issuing a new spec rather than using what we have that works right now."

Yea, thats a great idea. Is this guy a career bureaucrat?

Re:Encryption

[WaffleMonster]

This is why we should just use HTTP Auth, or update it so that we can. I mean, we already have pre-shared secrets with all the places we need secure.

Client sends: UserName, Nonce1
Server sends: Nonce2

Both perform: Auth1 = HMAC( Passhash, Nonce1 + Nonce2 ); Where + is concatenation and Passhash is PBKDF2 or keystretching, etc. of the user password. The server can store the hashed version. Hash because: Fuck length and special chars limits.

All of these crappy schemes are vulnerable to offline dictionary attack. We need to step away from our addiction to the CHAP garbage and move to zero-knowledge systems.

This shit really isn't rocket science folks. The truth is that the IETF is a bunch of morons or malicious bastards. Take your pick. Either way they've actively worked to make sure no connection on the web can be trusted not to have a potential MITM via CA system. Anything is better than that. The window for PW exchange is so small and if the MITM missed it or erased that, or the PW was exchanged out of band then they couldn't ever MITM your connection.

Last I checked the IETF isn't the one refusing to apply TLS-SRP patches sitting in their ticket systems. They did their job in 2007 (RFC5054)

It is the browser vendors sleeping on their feet. Support is included in most mainstream TLS toolkits, Apache and CURL already support it.

Re:Encryption

[krups gusto]

But that involves courts.  Or at least the appearence of judicial oversight.

Re:Encryption

[phorm]

If cracking it lowers resources, then processing it also consumes resources. Not something you want when you're using low-power or battery-driven devices.

Re:Encryption

[gweihir]

It indeed its a rat race, and if you make one real mistake, all other things become worthless. The way this is done is not to everything. The way is to determine in real-time what to store and what not. If that can be done with metadata, you do not even need to decrypt real-time, but if you want, say, keywords, then you have to. That goes into RAM and then what matches goes into more permanent storage. Not that hard to do and do not forget the routers this is usually being done on are expensive enough that this capability does not make that much of a price difference.

As to speed, while not all traffic is monitored, said 17432 hardware AES engines (speed was from an AMD CPU, others may be faster), may cost less than 1 million on pure hardware. The keyword-matching is done in a streaming fashion on FPGAs, BTW. But yes, it will cost more. But even if it is 1 billion, the NSA has that type of budget.

Re:Encryption

[psyclone]

How is the Auth1 scheme described above susceptible to offline dictionary attacks?

I'm assuming both client and server then exchange the Auth1 value to know if they can trust the other side: server would check for correct password, client would check for non-MITM server.

The supposed MITM would attempt to offline brute force the Passhash as they now know the inputs to the HMAC, and they know the correct Auth1 value?

Re:Encryption

[AK Marc]

Great, and if you could did so, you could control the volume of my stereo and turn my hot water heater off.

So you might as well use http.

HTTP has greater overheads. SNMP walk is similar to a GET, so why do most networking devices support SNMP for monitoring, and not an HTTP interface? SNMP is simpler, requiring fewer resources for the same functions. That you don't understand says plenty about your perspective.

Re:Encryption

[gbjbaanb]

and there are plenty of protocols that are lighter than SNMP - so if you're using a custom protocol, make it a good one that's efficient at doing exactly what you need. If it doesn't need to be efficient, then pick one that has the best tooling.

SNMP is a good interface for devices, but hey - the OP says he had a custom protocol, not SNMP.

Re:Encryption

[AK Marc]

Yup. It was an example. I know it doesn't use SNMP (I've sniffed the packets myself), but going into the specifics of a protocol I don't know is harder than making a substitution for a more common protocol. The point still stands, as you noted.

Re:Encryption

[WaffleMonster]

How is the Auth1 scheme described above susceptible to offline dictionary attacks?

The supposed MITM would attempt to offline brute force the Passhash as they now know the inputs to the HMAC, and they know the correct Auth1 value?

Yes, Nonce1 + Nonce2 are pulled off wire by attacker.

Attacker keeps trying HMAC(bruteforce,Nonce1 + Nonce2) until it can successfully decode the "mother fucking stream cipher"

These CHAP digest schemes all have the same problem no matter what algorithm you use or how you jiggle parameters. Zero knowledge proof of possession is the future of password authentication.

Re:Encryption

[OdinOdin_]

What is the problem with the CRIME attack and header compression ?

Just add an XOR string to the Cookie header, that is applied against the other data fields. This XOR itself can change each time a Cookie header is emitted. Now you have a non-repeating, pseudo random input for the compressor to work on. But the other party can apply a transform to the Cookie header to get back original data.

For good measure also add an additional Random-Nonce-Field-1="random-length-data" which is simply ignored and discarded by the other end. Now you can perterb the compressor in both directions, by applying a completely useless to the attacher the same data (allow it to compress) but also a Random-Nonce-Field-2 which might be different for each header, like the XOR but completely useless and to be ignored data.

Now it is upto the researches to use these tools (added to a Cookie spec change) to come up the most CPU cost efficient way to utilize them to make CRIME and other such attacks not viable.

Or maybe I am missing something glaring here ?

Re:Encryption

[Anonymous Coward]

And your devices are going to "auto find" this control system and blindly trust it? Unless you plan teach people how to manage their own CAs, expect encryption to be all but useless in any home network that needs to work out of the box.

Re:Encryption

[WuphonsReach]

It doesn't need to be perfect. If cracking it still takes some time, it lowers their resources. And it can still be unbreakable for attackers with fewer resources at their disposal.

Encryption is the easy part. Managing those encryption keys is the really really hard part. And if you screw up managing those encryption keys, the attackers don't need to spend those resources to crack your encryption.

Plus, encryption is no silver-bullet. There's still traffic analysis that can give the game away.

Re:Encryption

[Anonymous Coward]

You think that's bad, a company that I will not name, needed to send us their public key so we could add it for client authentication, so they sent us their CA signed private+public key pair over email. We promptly deleted their private key and told them not to send us their private key. A few weeks later something came up that prompted them to send us their public key again, which again they included their private key.

This was from an online company that lives and dies by the Internet. They had no idea how to handle certificates.

Another large Information System provider decided to go to "the cloud" and was migrating their services to online. Mind you, their systems stored SSNs, names, address, birthdates, and all kinds of fun data. The only way the supported getting information out of their system was to use a web interface that upload the data to FTP, encrypted in any form....... Was like this for almost 2 years, even though we pointed out that they clearly were breaking FERPA.

We were constantly pushing out customers to complain to these people for not supporting SFTP or at least encrypting the data in some fashion.

Eventually we told them that our company policy had a 6 month hard stop before to completely killed FTP support and we were making no exceptions. This was only a year ago.

Re:Encryption

[TheRaven64]

Near-field communication: wave the things you've bought against the control box before you install them. Or have a wand (or wand app in your phone) that you wave at them to activate them. If they haven't been tagged like this, they refuse to accept any connections. Seriously, not all UI problems are impossible to solve.

Re:Encryption

[Anonymous Coward]

Such devices don't do encryption in software, they have hardware that allows them to do it with negligible speed overhead and very little extra cost (both financial and energy). At least that is the case for the chips that I design with. It should be noted though that the current standard for such things is to use pre-shared keys and AES only, so that simplifies things a lot compared to PKI-based solutions.

Re:Encryption

[rioki]

Except that with DNSSEC you have authentication, just not bundled around the HTTP protocol. How you solve the encryption and authentication does not change the situation, that when communication with parties that you wish to exchange session keys with, you need to authenticate them. You could also use a previously shared key for that, but that would not be feasible for the web.

Re:Encryption

[Anonymous Coward]

Depends on your definition of "accepted". If by "accepted", you mean "Access Denied", then you could claim the same thing about logging into an SFTP site. "It accepted my user name and password, but it I couldn't log in because the user and pass were wrong".

Re:Encryption

[Anonymous Coward]

If you plan on randomizing the header to make it non-compressible, why not just skip the compression all together? Sounds like your way to "fix" allowing compression is to make the compression useless.

Re:Encryption

[Anonymous Coward]

Encryption without authentication can be made indistinguishable from encryption with authentication. This means that if you snoop on traffic you only believe is unauthenticated there's a nonzero risk that red lights will start flashing somewhere. How is this not "sort of works"?

Re:Encryption

[Anonymous Coward]

I violently disagree! "Enforcing encryption does not make things more secure, unless that encryption and the authentication going with it is flawless." What planet are you living on??

There is no perfect security. Not now, not ever. Security is always a relative term in spite of it frequently being used as an absolute term.

Therefore more secure is more secure. And encryption adds security. Even a very simple security system has value so long as the data you are protecting also has low value. If I lock my front door and keep a key under the doormat, it still discourages idle testing of the doorknob. More security is of course needed if you want more protection.

This whole, "if you can't fix every problem perfectly, then nothing can be done" attitude discourages forward progress. We need to discourage idle snooping, first. For more sensitive data, like financial, medical, and intimate personal data, we need stronger protections. All this will cost the NSA and that will discourage their, ah, recent predilections to be an organization Peeping Tom.

Now what if a Three Letter Agency really decides you are a problem? Then they are going to get you, regardless of your computer security measures. So let's not pretend that the TLA's cannot do their jobs. They had all the power and authority they needed to do their jobs 20+ years ago.

Re:Encryption

[psyclone]

Right, we need password-authenticated key agreements to become more common place, which are based on a zero-knowledge password proof. There are even IEEE and RFC standards.

What is the hold up here? Implementation is harder than simple password comparison?

Re:Encryption

[OdinOdin_]

Because the point of the compression is to compress the Content Body Payload transparently (and potentially the HTTP header names and keywords) at the TLS streaming level.

It only makes compression useless for the "Cookie" header which is exactly what is needed to defeat CRIME.
All security sensitive data like this should be able to be trivially fuzzed. Maybe a better scheme would be to implement:

Fuzz-XOR-Key: 0123456789abcdefxyz/+===
Fuzz-Cookie: $version=1; $foobar="123"; $random-nonce-1="192jsk232"; SESSIONID="0123456789secretXOREDresultHER"; $random-nonce-99="982kmn323"; $fuzzed="SESSIONID";

NOTE: Its been a while since I looked at a Cookie header directly, there are probably some major syntax mistakes in the above example.

Now you can extend it to any other kind of header using a common key and transformation technique, by prefixing headers with Fuzz-* and writing an RFC/IETF document on how the key is applied to which parts and when of the header value data.

Your suggestion of disabling compression in SSL/TLS support is already implemented.

His previous comments are much better

[Anonymous Coward]

Why HTTP/2.0 does not seem interesting

Good point, except...

[Anonymous Coward]

...the entire idea is to cripple security and the ability to provide for privacy. In the end, National Security agencies take the view that digital networks are a primary source of intelligence. Thus, being able to bug and break into systems is a national security priority. The group are dominated by companies that rely on government contracts, so they do their bidding and weaken the specs.

Ultimately, you live in an Oligarchy, not a democracy, so no one cares about your opinion or that of anyone else, unless you happen to have lots of cash. If you did have lots of cash, then you too would be trying to undermine security and privacy to ensure no one takes it from you.

Deal with it.

Re:Good point, except...

[jackspenn]

From reading the HTTP/2.0 thread, it seems like some of us "normal" users should respond to the working group last comment call and point out that encryption alone is not enough. That privacy and anonymity are at least equal to encryption, if not more important.

Was tempted to post as an Anonymous Coward for effect.

Re:Good point, except...

[Anonymous Coward]

On paper we technically live in a Republic.

http://www.wimp.com/thegovernm...

Re:Good point, except...

[Anonymous Coward]

Sort of the same Republic as presented in Star Wars...

Re:Good point, except...

[MassacrE]

It is a technical discussion. Unless you are prepared to provide feedback on how to make a more private/anonymous protocol which can serve as a drop-in replacement for HTTP 1.1, "normal users" will just serve as background noise.

PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).

Re:Good point, except...

[philip.paradis]

PHK's biggest issue IMHO is that HTTP/2 will break his software (Varnish), by requiring things his internal architecture can't really deal with (TLS).

Varnish was never intended to support TLS, nor do the majority of Varnish users (myself included) want it to. The core issues being discussed have little to do with Varnish, aside from the fact that PHK has an excellent understanding of HTTP and high performance content delivery. Having written an HTTP proxy of my own to perform certain other tasks, I understand and largely agree with his sentiments.

That said, it should be noted that many people who need to support TLS connections already use separate software in front of Varnish for cases where high performance intermediate HTTP caching is desirable. This is really a separate topic from discussion of HTTP/2 and/or SPDY, but implementation of a SPDY to HTTP proxy could handle cases where an administrator wishes to run software that only speaks HTTP, albeit with the drawback that SPDY-specific features would be unavailable.

For many use cases, the ability to support 30,000 concurrent HTTP connections with a single VM outweighs the value proposition of encrypting the content in transit, especially for cases where the content in transit isn't remotely sensitive in nature. While "encryption doesn't add much overhead, Google said so" is a commonly parroted idea these days, if you take the opportunity to test various deployment scenarios you'll quickly find that assertion is false for many of those use cases.

Re:Good point, except...

[philip.paradis]

On an entirely separate note, it seems Slashdot still has not renewed their own certificate.

Re:Good point, except...

[phantomfive]

That privacy and anonymity are at least equal to encryption, if not more important.

I'm really interested on your plan to enforce privacy and anonymity in the HTTP protocol. Because I don't see how you can do that......

Re:Good point, except...

[dave420]

A democracy can be a republic, or not. A dictatorship can be a republic, or not. You don't seem to know what "democracy" or "republic" mean, which is troubling.

Re:If you are a programmer and have a Wikipedia pa

[Anonymous Coward]

Dang, I'm sad Linus Torvalds, John Carmack, et. al. are "too self important" because someone else made a wikipedia page about them. Or maybe programming, especially concerning the next standard for what most of the internet would ideally run, is too important for fucking hipsters to get involved.

Convincing

[gweihir]

There is also the other thing that there is no urgent need to replace HTTP/1.1, despite of what people claim. Sure, it has problems, but the applications it does not support so well are things that there is not urgent need for, hence there is no urgent need for a protocol replacement. It would be far better to carefully consider what to put into the successor and what not. And KISS should the the overriding concern, anything else causes a lot more problems and wastes a lot more resources than having the successor a few years later.

Re:Convincing

[Anonymous Coward]

Agreed. Additionally, SPDY already exists as an unofficial stopgap for those that want it. Most will stick to HTTP/1.1, but Google is using SPDY because it suits their needs and that's just fine.

Re:Convincing

[gweihir]

Indeed. And getting a bit more experience with it to be able to judge its merits and problems (unfortunately Google has been both short-sighted and too specific for their own needs in the past) would be a good thing too, as it provides the opportunity to learn some lessons before setting anything in stone.

Re:Convincing

[Anonymous Coward]

exactly this! HTTP/1.1 is just about moving data across, it shouldn't have anything to do with encryption. HTTP spec is not the place for an encryption layer.

Re:If you are a programmer and have a Wikipedia pa

[l0ungeb0y]

And why shouldn't have a moratorium and review ESPECIALLY in regards to what has come to light about how fucked the internet is in just the last year?

Why proceed blindly with a protocol that comes from Google, who gladly works hand in hand with the NSA and is a Corporation whose core focus to track and monitor every single person and thing online?

What? Just proceed with something that addresses NONE of the present mass surveillance issues, and possibly could make us less secure than we are now just because we don't have a fall back lined up?

Or how about we take this time to step back and reevaluate what HTTP2.0 needs to be -- such as changing to a focus on security and privacy.

next up ipv6

[Anonymous Coward]

can we scrap ipv6 yet ? the most unintuitive address system invented so far

Re:next up ipv6

[am 2k]

Globally unique addresses are really unintuitive. What is this, the phone system? /s

Google wants control of the world.

[Anonymous Coward]

Isn't publishing HTTP/2.0 as a 'place-holder' is just a waste of everybody's time, and a needless code churn, leading to increased risk of security exposures and failure for no significant gains ?

Not to mention, who gets control of it and passes ouit all the back doors.

Idealism in computing?

[Anonymous Coward]

This guy has never heard of version numbers or something? He thinks it's a better idea to design something that is perfect instead of using something that is useful for what it's designed for but less than ideal for a small percentage of use cases.

Moving goal posts

[abhi_beckert]

I don't think HTTP has any problems with security. All the real world problems with HTTP security are caused by:

  * dismally slow roll out of dnssec. It should have been finished years ago, but it has barely even started.
  * the high price of acquiring an SSL certificate (it's just bits!).
  * slow rollout of IPv6 (SSL certificates generally require a unique IP and we don't have enough to give every domain name a unique IP).
  * arguments in the industry about how to revoke a compromised SSL certificate, which has lead to revocation being almost useless.
  * SSL doesn't really work when there are thousands of certificate authorities, so some changes are needed to cope with the current situation (eg: dsnssec could be used to prevent two certificate authorities from signing the same domain name)

Re:Moving goal posts

[Anonymous Coward]

So HTTP doesn't have any problems with security... it just has numerous problems with security that aren't adequately covered by the myriad of fixes thrown at it?

Re:Moving goal posts

[fuzzyfuzzyfungus]

The trouble is that SSL is really playing two roles that aren't trivial to separate, because of the 'well-just-MiTM-with-a-self-signed-cert' problem; but which are substantially at odds with one another in other respects.

You've got identification, which you only really want in a subset of cases (your bank, say); but which is actually slightly expensive to do properly and then you've got encryption, which you want in basically all cases (would you ever not at least want it?) which is cheap; but requires the certificate. Arguably, what we really need is some mechanism for measuring (presumably by consulting some number of 3rd parties, ideally widely distributed) certificate stability and certificate duration.

There are some certificates where you would actually want somebody to have done some thorough checking that the entity on the cert is who they say they are. However, much of the time your main concern is that the certificate isn't an MiTM, and that you are talking to the same person or entity you were talking to previously. You don't actually need to know their Real Official Name or anything; but you want to be sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs, and you want to be sure that the certificate didn't change suddenly for mysterious reasons.

Re:Moving goal posts

[Anonymous Coward]

DNSSEC is an abomination. One of the primary reasons it's rolling out slow is because a lot of smart (but perhaps less vocal and financially-interested than their opponents) people really don't *want* DNSSEC to be widely adopted. DNSSEC raises all sorts of new, difficult security issues. It's a great example of total process failure: a committee protocol over a decade in the making that makes security worse in the net.

The unique IPs problem isn't really relevant, it's not a practical barrier.

All the rest of your stuff boils down to the problems of trust that are exhibited by any public key infrastructure and how they were solved (or not!) by browser vendors. This problem is somewhat orthogonal to everything else about the security and privacy of the protocol itself.

Re:Moving goal posts

[ras]

I don't think HTTP has any problems with security.

I disagree. We live in a world where phishing attacks are common, and the PKI system is fragile. Fragile as in when Iran compromised DigiNotar and people most likely died as a result.

The root cause of both problems is the current implementation of the web insists we use the PKI infrastructure every time we visit the bank, store or whatever. Its a fundamental flaw. You should never rely on Trent (the trusted third party, the CA's in this case) when you don't have to. Any security implementation does the insist you do when you don't have to is broken. Ergo HTTP is broken.

It's not like it isn't fixable. You could insist that on the first visit the site sends you a cert which is used to secure all future connections, and that cert was used only when the user clicked on a bookmark created when the cert was sent. That would fix the "Iran" problem, and it would also allow the web sites to train the users to use the bookmark instead of clicking on random URL's.

So given HTTP security has caused deaths and it's is fixable, I'd say it has HTTP huge problems with security. Given HTTP/2.0 not attempting to fix it is a major fail IMHO.

Re:Moving goal posts

[Kjella]

Well you can always do it the TOR way, basically the onion address is a fingerprint of the public key. You'd still need DNS to tell you that "435143a1b5fc8bb70a3aa9b10f6673a8.pubkey" can be found at ip 1.2.3.4 or ipv6 abcd:abcd:abcd:abcd:abcd:abcd:abcd:abcd) so you could always suffer denial of service, though the "pubkey" DNS server should refuse requests to redirect that aren't signed by that public key but nobody else would have the correct key for a MITM. The obvious downsides:

1. The domain would never be easy to read or have meaning, it's for linking or copy-pasting or QR codes. But you could have an "easy" URL that redirects to your secure site for bookmarking, that way returning visitors coming from bookmarks aren't vulnerable.
2. If the server is compromised, you lose the "domain". This can somewhat be mitigated by having it signed by a "root" key (self-signed!) kept offline and safe, using the root key to revoke it and once revoked DNS servers will never let it be unrevoked. Possibly also a revoke/redirect to say the new server is now at 70a3aa9b10f6673a8435143a1b5fc8bb.pubkey. That does somewhat rely on the DNS system, but if the server is compromised all bets are off and this only lets you recover once (and if...) you find out it's compromised.
3. If you fuck it up and lose the key and all backups, there's no recovery and the domain is forever lost.

Anything more complicated than that will probably die the way 99.999% don't use PGP's web of trust, the sorta maybe we're changing keys for some good reason or maybe we're really compromised doesn't work, people want straight answers is this the same site or not.

Re:Moving goal posts

[complete loony]

DNSSEC should give you confidence that the person who currently "owns" the domain name is the same person who "owns" the server you're talking to. That should be enough for most casual connections. But it also puts all of your security in one basket. Take over the domain entry and you control everything.

So the next obvious step is to get multiple independent authorities to verify your identity, sign your key and provide that information via DNS and / or at connection establishment time. Then we should raise the bar for displaying a "This connection is secure and verified" in the browser to some minimum number of highly reputable signatures.

Re:Moving goal posts

[goddidit]

Currently TLS CA model tries to accomplish, identification, encryption, and trustworthiness assessment all at once. Encryption you can get with the self signed certs, domain based identification with something like DANE, and I suppose that CA model could scale to the sites requiring the trustworthiness assessment, e.g. banks and some large websites, which need to secure the binding with their real world presence.

Re:Moving goal posts

[Anonymous Coward]

the high price of acquiring an SSL certificate (it's just bits!).

The bits are of course easy. Meningful validation of the authenticity of the requester is a bit harrier. Exacerbated by the fact that we should be extra careful with CAsince the model has zero sense of scoping, so one loosely secured trusted CA can be used to sign for any and all sites on the internet.

SSL certificates generally require a unique IP

SNI solves that. I want to see more IPv6, but the TLS problem is solved by another technology that is more widely deployed than IPv6.

The problems remain that CAs have unbounded scope and cert revocation is not well done (CRLs require explicit action, browsers allow timeouts on OCSP to be silently ignored). DNSEC somewhat mitigates the large number of open-ended CAs, but there still isn't a rock solid solution from a practical standpoint.

In any event, HTTP/2 doesn't really fix any of this anyway.

Death by Committee

[bill_mcgonigle]

HTTP/1.1 is roughly seventeen years old now - technically HTTP/1.0 came out seven years before that, but in terms of mass adoption, NSFNet fizzled in '94 and then people really started to pay attention to the web - I had my first webpage about six months before that (at College) and there were maybe a dozen in the whole school who had heard of it previously. Argue for seven years if you'd like, but I'll say that HTTP/1.0 got seriously revised after three years of significant broad usage. SSLv3, still considered almost usable today, was released the year before. TLSv1.2, considered good, has been a standard for over five years and still it's poorly supported though now critically necessary for some security surfaces.

After this burst of innovation, somebody dreamt up the W3C and we got various levels of baroque standards, all while everybody else solved the same problems over and over again. IETF used to be pretty efficient, but it seems like they're at the same point now.

I won't argue for SPDY becoming HTTP/2.0 but I will admire it as an effort to freaking do something. Some guys at Google said, "look, screw you guys, we're going to try to fix this mess," and they did something. While imperfect, they still did enough that the HTTP/2.0 committee looked at it and said (paraphrasing), "hrm, since we haven't done anything useful for 15 years, let's take SPDY and tweak it and call it a day's work well done."

The part Google got most right was the "screw you guys" part - central-planning the web is not working.. I'm not positive what the right organization structure looks like, but it's not W3C and IETF. We need to figure out what went right back in the mid 90's and do that again, but now with more experience under our belts. This talk of "one protocol to rule them all for 20 years" is undeniably a toxic approach. HTTP/1. 1 should have been deprecated by 2005 and we should be on to the third iteration beyond it by now. Yeah, more core stuff for the devs to do - used to be we had people who could start a company and write a whole new web browser in a year - half the time it takes to change the color of tabs these days.

And don't start with this "but this old browser on ... " crap either - we rapidly iterated before and can do it again. Are there people who fear change? Sure - and nobody is going to stop HTTP/1.1 from working 50 years from now, but by golly nobody should want to use it by then either.

Re:Death by Committee

[fuzzyfuzzyfungus]

I'd be inclined to suspect that the stagnation of the W3C and IETF is more a symptom than a cause: they might be 'central planners' in the sense that they get a bunch of technocrats together and try to hammer out the Glorious 3rd Five Year Plan; but they lack essentially all power that a real central planner would have(either to expropriate anyone who sneaks a patent into an IETF standard, or to crush somebody who just wanders off and does his own thing).

Trouble is, if you just wander off and do your own thing, you swiftly learn that the internet of today, unlike the early internet, is huge, heavily populated by people and companies who see it as a necessary evil rather than having any active desire to deal with it, and a certain amount of perverse cat-and-mouse caused by 'security'(why does so much stuff use, or look like, HTTP over port 80, even if it probably isn't the best solution? Because anything that doesn't won't be visible to cube drones slacking off or people on really shit ISPs...)

Given that it takes time for hardware and software to age out and be replaced, it's obviously a bad thing that the people who should be working on future standards, to guide the implementation of what replaces the stuff aging out, have absorbed the inertia of the larger internet (Even if it won't actually be in the field until everybody's old shit drops dead, it'll never reach production if it isn't hammered out and ready to be baked in to the replacements when that does happen); but I'd be very, very, surprised if the standards bodies actually manage to impose stagnation, rather than drawing their membership heavily(but somewhat unavoidably) from entities in the grips of stagnation themselves.

It's probably not for nothing that it was Google, rather than somebody smaller, who came up with that proposal: in terms of engineering resources a substantially smaller company could have done it; but they wouldn't be able to say "Yeah, here's our HTTP replacement. We think it's pretty neat, and will probably use it when the millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."

If you are very big, or a lot of your product line is very insular, there is still nothing preventing you from Just Doing It and assuming that things will work out(because, in your case, they very well might). If you are not one of those things, the pond in which you are a small fish is vastly larger than it used to be...

Re:Death by Committee

[jandrese]

My impression is that the IETF was doing a pretty good job until the businesses started taking the internet seriously and instead of being a group of engineers trying to make the best protocols it became a bunch of business interests trying to push their preferred solution because it gives them an advantage in the market. Get a few of those in the same room and deadlock is the result.

Re:Death by Committee

[MatthiasF]

Bullshit. BULLSHIT!

Google has derailed so much of the web's evolution in an attempt to control it that they do not have the right for them or any Google lover to suggest they get to the web's standards from committees. From the "development" trees in Chrome, to WebRT and WebM, they have splintered the internet numerous times with no advantage to the greater good.

The committee was strong armed into considering SPDY simply because they knew Google could force it down everyone's throats with their monopoly powers across numerous industries (search, advertising, email, hosting, android, etc.). HTTP/1.1 has worked well for the web. The internet has not had any issues in the last 22 years except when assholes like Google and Microsoft decided to deviate from a centralized standard.

There is no way we should let Google set ANY standard after the numerous abuses they have done over the last 8 years, nor should any shills like you be allowed to suggest they should be the one calling the shots.

So, kindly go to hell.

Re:Death by Committee

[thsths]

I completely agree. W3C seems to be always behind reality, trying to describe it, but not define it. IETF did a lot of very useful work, but they have been branching out into rather obscure protocols recently. Where is HTTP/1.2? Surely HTTP/1.1 is not perfect?

And Google did what Google does: they threw together a prototype and checked how it would work. And it seems it is working very well for them, but maybe not so much for others.

I would also advocate to separate some of the concerns. Transmitting huge amount of bulk data is a problem that is (mostly) solved with HTTP/1.1. Encryption less so, session tracking is a bit of a pain, and server push is really ugly in HTTP/1.1.

PS: Concerning the original submission, there is nothing wrong with encrypting cookies. Instead it is the proper thing to do if you do not trust the client, which you should never do.

Re:Death by Committee

[Archibald Buttle]

We rapidly iterated before when the web was niche. When we had, comparatively speaking, very few users. Before there was a mass adoption in business.

Back then the disruption of rapid iteration and accompanying obsolescence was not a big problem. Now it's a massive problem.

Sure, one can argue that institutions stuck using IE6 (or even IE8) should get with the times and update, but the reality is that is a very costly exercise. One can't simply blindly update a few thousand machines in a company when the end result could be a few thousand people unable to work. Upgrading often has knock-on effects, so a browser upgrade may require an OS upgrade too, and every other piece of business-critical software needs to be thoroughly tested. Some software will also provide to be incompatible too, and sourcing replacements (either new licenses for new versions, or rewrites for custom software) can be prohibitively expensive.

It's those people who fear change. The IT managers that are dealing with managing thousands of machines. A failed upgrade not only has the potential to cost them their jobs but also to put a company out of business. Major change for them is terrifying.

You are right though. We can rapidly iterate now, like we did before. But we need to be careful about how we do that, and not forget those that can't come along for the ride.

Re:Death by Committee

[Anonymous Coward]

We need to figure out what went right back in the mid 90's and do that again,

What 'went right' was that things didn't work, and a relatively small community made it work without a lot of people to nitpick each iteration to death. The 'problem' after that is that it worked fine thereafter. The bigger problem was that rather than selecting the appropriate protocol for the task at hand, companies decided that HTTP wa the only networking protocol. Despite that very bizarre state of affairs, HTTP/1.1 has held up well and no one wants to risk screwing the pooch by changing something that isn't too terribly broken.

central-planning the web is not working

How is it not working?

This talk of "one protocol to rule them all for 20 years" is undeniably a toxic approach

I agree that a single protocol is a mistake (using *http* for everything), I think you are suggesting that having http/1.1 not undergoing constant change is 'toxic'. What would be toxic is an ever shifting sea of fundamental protocol changes driving needless churn in software for dubious gain. What would be healthier is for people to get over their fixation that 'http' must be the one true protocol and use other protocols *as suggested by the applicaiton*.

Re:Death by Committee

[swillden]

Yeah, here's our HTTP replacement. We think it's pretty neat, and have been using it it when the hundreds of millions of users of our browser and/or operating system contact our tens to hundreds of thousands of servers, which is often. If you guys like it, you can use it too; but even if you don't, we don't really care."

FTFY.

Your point is a really good one, though. It's the first thing that occurred to me when I started talking to people in Google about SPDY and QUIC. At this point making big changes in fundamental infrastructure like HTTP almost requires a single party that controls all the major moving parts to design, implement and test it.

Summary

[Anonymous Coward]

Let's keep the crappy thing we have now and not deploy the less crappy thing we've already implemented so we can focus our effort on building something perfect from scratch. Good luck with that.

Re:If you are a programmer and have a Wikipedia pa

[Anonymous Coward]

Yeah, what DOES he know? He's just the author of Varnish and a core FreeBSD developer, I bet you understand HTTP a lot more than he does.

Too much.

[bussdriver]

It's better they chuck some of it and stick with a few good bits. The encryption can be trashed as far as I care; that can be another group's problem. We need proxy caching and you can't do it with encryption and be secure.

The reason we can't move like before isn't the committee, it's that we now have a global system built around it and a great deal of investment in it. In the 90s it was all new; low risk, low impact. Today, there is a vast territory claimed and set; when you make new things you can't destroy all you've gained and unless you have a killer app (like the web was) people will not be motivated to make drastic changes.

DNSSEC is a great example of not having much motivation to do the pain in the ass it creates; furthermore, it doesn't completely solve a problem we all are that worried about. They may have made it quickly but people are not using it. IPv6 is long past due and here we sit... (at least we don't have a huge movement of IPv4 deniers saying it's not full and if it is, it wasn't our fault.)

cost of SSL certificates

[SuperBanana]

The cost of SSL certificates is not in the bits. It's in the security of the private key, some validation in extended verification certs, and the administration work involved in signing your key with the CA's key. "It's just bits" is like looking at a computer chip and saying "it's just sand."

Re:cost of SSL certificates

[WaffleMonster]

The cost of SSL certificates is not in the bits.

Back in the day you actually had to pick up the phone, speak with someone and provide corporate documentation. Now you purchase certs from a computer in an 100% automated process. Completely "just bits" worthless.

It's in the security of the private key, some validation in extended verification certs

Extended verification is a foolish scam to enrich CAs. Users hardly understand what the padlock icon means in URL bar after being intentionally inundated with fake padlock gifs and "we're secure" believe what we say assertions littering every online commerce and banking site on the planet.

Re:cost of SSL certificates

[Anonymous Coward]

It's not the security of the private key, these take virtually no CPU time to generate.

The cost is *supposed* to cover the cost of auditing and verifying that you are who you claim to be and that you represent the domain that you are attempting to register a certificate for. Unfortunately there are very many disreputable CAs who do a less than quality job of verifying their clients are who they claim to be.

And then there are the CAs who are mandated to issue fake certificates by national security letters.

Arguing about other peoples arguments

[WaffleMonster]

I think following demonstrates reality participants in standards organizations are constrained by the market and while they do yield some power it must be exercised with extreme care and creativity to have any effect past L7.

As much as many people would like to get rid of Cookies -- something
you've proposed many times -- doing it in this effort would be counter-productive.

Counter-productive for *who* Mark ?

Counter-productive for FaceBook, Google, Microsoft, NSA and the other mastodons who use cookies and other mistakes in HTTP
(ie: user-agent) to deconstruct our personal identities, across the entire web ?

Even with "SSL/TLS everywhere", all those small blue 'f' icons will still tell FaceBook all about what websites you have visited.

The "don't track" fiasco has shown conclusively, that there is never going to be a good-faith attempt by these mastodons to improve personal privacy: It's against their business model.

And because this WG is 100% beholden to the privacy abusers and gives not a single shit for the privacy abused, fixing the problems would be "counter-productive".

If we cared about human rights, and privacy, being "counter-productive" for the privacy-abusing mastodons would be one of our primary goals.

It is impossible for me to disagree with this. Have several dozen tracking/market intelligence/stat gathering firms blackholed in DNS where creative use of DNS to implement tracking cookies do not work. I count on the fact they are all much too lazy to care about a few people screwing with DNS or operating browser privacy plugins.

I'm personally creeped out by hoards of stalkers following me everywhere I go...yet I see the same mistakes play out again and again... people looking to solve problems without consideration of second order effects of their solutions.

You could technically do something about those army of stalker creeps ... yet this may just force them underground, pulling same data thru backchannels established directly with site - rather than a cut and paste javascript job it would likely turn into module loaded into backend stack with no visibility to the end user or ability to control.

While this would certainly work wonders for site performance and bandwidth usage... those limited feedback channels we did have for the stalked to watch the stalker are denied. On flipside of the ledger not collecting direct proof of access could disrupt some stalker creeps business models.

I think emotional half-assed reaction to NSA with established ability to "QUANTUM INSERT" ultimately encourages locally optimal solution having effect of affording no actual safety or privacy to anyone.

Not only does opportunistic encryption provide a false sense of security to the vast majority of people who simply do not understand relationship between encryption and trust such deceptions effectively work to relieve pressure on need for a real solution.. which I assume looks more like DANE and associated implosion of SSL CA market.

My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.

Re:Arguing about other peoples arguments

[TechyImmigrant]

>My own opinion HTTP 2.0 is only a marginal improvement with no particular pressing need... I think they should think hard and add something cool to it.. make me want to care...as is I'm not impressed.

Alright, lets propose some stuff

(1) HTTP runs over TCP, This is stupid. An unbracketed stream protocol for serving blobs of data and protocol messages is wrong and has promoted abhorrent things like REST. Lets go use a reliable datagram transport with a persistent session that can be bound 1:1 with the security session. Then both ends can keep per-session state and the life of programmers gets easier.
(2) HTTP over TLS is stupid. TLS is a machine to machine protocol, not a web client to web server protocol. Lets use a security protocol that is designed to secure the datagram-HTTP mentioned in (1). Then perhaps, the server would know which cert to cough up for which web site, which today it does not, because TLS only authenticates the server not the (virtual) web site.
(3) MITM is a primary problem. Authenticate both ends. If x509+PKI+TLS isn't working (it isn't) lets do something else. How about everything defaults to self signed and we build an certification/attestation layer on top to declare which of the self signed certs correspond to which entities. You could even do it web-of-trust style to limit the single-point-of-failure issues with conventional PKI.

Re:Arguing about other peoples arguments

[snadrus]

I agree completely that you've hit the nail on the head with exactly what needs to be looked at.
As for (1) I believe that QUIC is the protocol being investigated now (you can enable it in Chrome).
(2) Anyone who sets-up a virtual website is shocked to learn that one. But an SSL extension where the client indicates what name it seeks should do.
(3) This. Exactly this is needed & I don't know that anyone's trying. Signed certs are dead-simple to make & is how Git is done nowadays, so extending that model to http just makes sense. Since this 1 PC has signed-in to all my regular services, they all would be able to vouch for that cert being me (and should ask challenge questions at sign-in for any machine that doesn't coorespond).

Thanks.

Re:Arguing about other peoples arguments

[Anonymous Coward]

*Nothing* should continue to rely on client side resources except for HTML and CSS page redendering. All cookies, all scripting should be run server side. Of course "they" will have excuses, but the origin of the blame starts with Netscape Communications for introducing cookies, and then later LiveScript that evolved into JavaScript.

Re:Arguing about other peoples arguments

[TechyImmigrant]

>QUIC
QUIC. Thank you. I had forgotten the name and was too lazy to look it up.

>But an SSL extension where the client indicates what name it seeks should do.
It would function for web servers, but there's a more general problem and this falls under it. We use TLS for everything. To protect privacy, credit card transactions, instruction authenticity "sell all my stocks!" and any number of other things that are presumed to be secure because they are over TLS.
I want to see a transition to lots of little, simple, easy to implement security protocols, one for each purpose. A web page security protocol. A payment security protocol. A timed assertion protocol etc. So we don't have to trust in the one true PKI for everything. We can shrink the trust boundary to just the interacting entities.

Something of a pipe dream, but the "Nuke TLS from Orbit" crowd is getting some traction these days.

(3) I'll get coding :)

Re:Arguing about other peoples arguments

[LordLimecat]

It is impossible for me to disagree with this. Have several dozen tracking/market intelligence/stat gathering firms blackholed in DNS where creative use of DNS to implement tracking cookies do not work.

Let me get this straight: You think it a good idea to attempt to subvert a standard to make it incredibly difficult for the biggest users of said standard to use it?

Yea, let me know how that turns out.

people looking to solve problems without consideration of second order effects of their solutions.

Attempting to solve the so called "privacy issue" when A) the primary users of the standards will reject your solution; B) the primary consumers do not care; and C) this is a political, not a technical, problem; all demonstrates pretty neatly the issue you describe. You're going to end up with another massive failure like the "Do Not Track" fiasco, that just about everyone with a clue predicted would fail from the moment there was a clamor to make it on-by-default.

I'm personally creeped out by hoards of stalkers following me everywhere I go

If you're visiting websites with trackers, and youre upset that they are tracking you, I have bad news: Nothing will change the fact that the webhost has logs of your visit, and no standard can fix that. If you dont trust the webhost not to track you, stop visiting them.

Re:Arguing about other peoples arguments

[WaffleMonster]

Let me get this straight: You think it a good idea to attempt to subvert a standard to make it incredibly difficult for the biggest users of said standard to use it?

I agree only with the sentiment current state of affairs sucks. Although not stated earlier I personally disagree with idea of removing cookies.

Reread what I said in context. I am not arguing for or against ... only the reality that very little power rests in the hands of protocol designers.

B) the primary consumers do not care

Do they have any idea what is going on? Are they properly informed?

If you're visiting websites with trackers, and youre upset that they are tracking you, I have bad news: Nothing will change the fact that the webhost has logs of your visit, and no standard can fix that.

Personally I assume every site I visit to log information about my visit the same way every person I interact with in public remembers conversations or observes me walking down the street. I have no problem with this.

Bumping into someone in public is quite a different matter from following them around everywhere they go. Stalking is illegal in the united states and most countries.

I consider third parties which sit in the middle and collect track, aggregate and sell data on virtually every site I visit online to be fundamentally no different than stalking. I find this unacceptable and refuse to accept this behavior as legitimate or legal and have taken measures to deny these firms the capability to track me.

Re:Arguing about other peoples arguments

[LordLimecat]

Do they have any idea what is going on? Are they properly informed?

That is far, far, far out of scope for a standards discussion. That is an issue for activists to take up, not for the HTTP 2.0 discussion. As of right now, the consumers do not care, and the developers this is targetted at would not want privacy controls. You would be forcing the metaphorical grandma across the street and generally pissing everyone off in the process. Thats not how you write a successful standard.

None of what you describe is really an issue for HTTP to be solving. You could argue that cookies have to go, but they fulfill functions today (logon persistence) and there are already methods for minimizing their abuse (disabling third / first party cookies, deleting them, private browsing). I really dont get how a discussion on a transport protocol is the proper place for political or content discussions.

Re:Arguing about other peoples arguments

[WaffleMonster]

That is far, far, far out of scope for a standards discussion. That is an issue for activists to take up, not for the HTTP 2.0 discussion.

Your the one who brought up the idea consumers "do not care" as reason B) for dismissal of PHK's privacy concern.

 

None of what you describe is really an issue for HTTP to be solving. You could argue that cookies have to go, but they fulfill functions today

How many times do I have to repeat myself specifically re-stating my position with regards to cookies before this strawman factory is shuttered?

I really dont get how a discussion on a transport protocol is the proper place for political or content discussions

While formatting of bits have no political implications use of opportunistic encryption is entirely a political matter as is the nature of information exchanged between parties.

Protocols not designed to account for realities of political, social and financial realms are likely to either be harmful or worthless in the real world they are deployed into. Any yahoo can design a state machine and protocol fields.... it requires much thoughtfulness and skill to design something that benefits everyone.

Re:If you are a programmer and have a Wikipedia pa

[Anonymous Coward]

How "fucked" is the internet, exactly?

It's acquiring new users at an astonishing rate - on average, over ten million people per day. Number of searches, online spending, advertising profits - these metrics are increasing at a compound rate of double-digit percent. More industries should be so fucked.

There's a problem with spying and privacy? Duh, and how much is that worth at the bottom line? Hasn't stopped the growth, hasn't even dented it so's you'd notice. Ask Google.

The internet isn't fucked. Its users may be - particularly those who wanted it to remain a free, anarchic playground - but the internet itself is thriving beyond any reasonable expectation.

MITM from day one breaks key continuity management

[tepples]

However, much of the time your main concern is that the certificate isn't an MiTM, and that you are talking to the same person or entity you were talking to previously.

That's called the "key continuity management" paradigm. But KCM breaks down if the first time you talk to someone happens to be through a man in the middle. If your Internet connection is through a MITM proxy, as seen in bug 460374 and in many corporate networks, then "the same person or entity you were talking to previously" would be the MITM. For this reason, even though SSH is most often used in KCM mode, the "Please answer yes or no" prompt urges the user to confirm the server's key fingerprint out of band.

Run your own CA

[tepples]

Or just run your own CA and install its root certificate on the devices on your private network.

Re:Run your own CA

[gmhowell]

Reasonable idea, but I suspect GE, Samsung, Whirlpool, and all the other manufacturers of Internet connected widgets will force you to buy a certificate from their app store. Hacking your light bulb to install your own certificate will be a federal crime, punishable by PMITA prison or worse.

Re:Run your own CA

[Anonymous Coward]

The correct reply to those companies is "pound sand". Unless they really, really want to undermine the doctrine of first sale, there will be no consequences to using your own certificate for anything.

Also, "air gap".

FOADIAF, big brother.

HTTP-only proxy

[tepples]

If you're behind a firewall that shunts all traffic to a proxy that allows only outgoing HTTP connections, then HTTP is The Internet.

Re:HTTP-only proxy

[AK Marc]

I'm not. Are you?

Re:HTTP-only proxy

[tepples]

If you're behind a firewall that shunts all traffic to a proxy that allows only outgoing HTTP connections

I'm not. Are you?

At one time, I was. I imagine many still are, especially in workplaces and on IPv4 address-poor continents.

Re:HTTP-only proxy

[AK Marc]

So you aren't on one. I'm not on one. But you find it relevant? NAT doesn't require a proxy, and I've only worked one place that used a proxy. And aside from that one place, I've only seen them commonly used at schools, as it's common for people who misunderstand CIPA to think one is required. Though CIPA allows for all other protocols, so an HTTP proxy with all other ports wide open. Some places do that. All HTTP goes through proxy, but nothing else filtered happens some times as well.

But the real reason the false equivalence is made is that it's anti-American. The Americans invented the Internet and TCP-IP, but CERN invented the World Wide Web, which *IS* the Internet (or, just one of many protocols that run over the Internet). Thus, the more "important" HTTP is, the less important the USA is.

Re:HTTP-only proxy

[Anonymous Coward]

But the real reason the false equivalence is made is that it's anti-American. The Americans invented the Internet and TCP-IP, but CERN invented the World Wide Web, which *IS* the Internet (or, just one of many protocols that run over the Internet). Thus, the more "important" HTTP is, the less important the USA is.

Huh? WTF are you talking about? That not only makes no sense, it attempts to create (poorly, I might add) some sort of straw man making protocol development equivalent to political prestige.

You usually have reasonable things to say AK Marc, but this time you're talking out of your ass and it smells that way.

Posting Anon to preserve my mods on this thread.

Re:HTTP-only proxy

[AK Marc]

Having worked tech around the world, I've heard lots of anti-American sentiment towards the involvement in the Internet. I've heard people pushing for "The Web" over "The Internet", and explain that "The Web" was created without American influence at CERN, and The Web should be independent of US control, even if the US built The Internet and TCP/IP, those are irrelevant to the modern The Web.

There's a lot of subtle anti-American sentiment in the world. I haven't worked in the UK, so I don't know if it holds there. Those in the US don't get the anti-American sentiment, especially after revelations that the NSA is tapping everything world-wide. People don't like the US iron grip on the Internet, and that's one of the ways I've seen people try to diminish the US involvement.

Mixing insensitive and sensitive content

[tepples]

For many use cases, the ability to support 30,000 concurrent HTTP connections with a single VM outweighs the value proposition of encrypting the content in transit, especially for cases where the content in transit isn't remotely sensitive in nature.

It isn't necessarily that the work that you're trying to serve is "remotely sensitive in nature". It's that other parts of the same page may be "sensitive in nature", and browsers throw up pop-up windows about "mixed content" when a secure document transcludes an insecure resource. For example, the logged-in user's session cookie is "sensitive in nature" because an attacker can view it and replay it to impersonate the user. But because ad networks have a history of not supporting HTTPS, many sites have had to remain vulnerable to Firesheep in order to serve ads to logged-in users. (Only in September of last year did Google's AdSense add HTTPS support.)

Re:Mixing insensitive and sensitive content

[philip.paradis]

I'm keenly aware of the many issues surrounding mixed content. I'm not referencing any use cases where that would be an issue; far from it, I'm referencing cases where a single entity controls the serving of non-sensitive content, and I'm certainly not suggesting serving session cookies over plaintext under any circumstances. You might be interested to learn that I spend a considerable amount of time every week educating people on issues far more complex than the limited fundamentals you've referenced here, and in any event we appear to be discussing completely different use cases.

Re:Mixing insensitive and sensitive content

[tepples]

I'm referring to Slashdot itself, which sends session IDs in plaintext unless you're a subscriber.

Re:Mixing insensitive and sensitive content

[philip.paradis]

I'm explicitly not referring to Slashdot. As much as I may disagree with said practices (and Slashdot has a seemingly ever-increasing pile of bad practices following the last buyout), poor practices on the part of a particular site operator bear no relation to responsible use cases.

Re:Mixing insensitive and sensitive content

[philip.paradis]

To add to the heap of bad practices in relation to the current conversation, I'll repeat my earlier comment that Slashdot has still not renewed their certificate, and thus even subscribers are in a bit of a pickle with regard to TLS unless they happen to have previously noted the key fingerprint of the now-expired certificate and place rather high trust in the internal integrity of Slashdot operations. Given the circumstances, I could not in good professional conscience recommend such trust.

Re:Mixing insensitive and sensitive content

[philip.paradis]

I'll add one more bit of fuel to the fire of Slashdot irresponsibility. It appears slashdot.org uses Apache 2.2.3 on CentOS to serve its content, and while this could be due to an obfuscated host response header, the issuance date for their wildcard SSL certificate (which really shouldn't be used in this case anyhow) was April 20, 2013. Unless Slashdot went to the trouble of avoiding OpenSSL all this time, this means the private key for their wildcard certificate was vulnerable to the Heartbleed vulnerability widely reported just a short while back (heavily discussed on Slashdot, ironically enough), but their management couldn't be bothered to revoke and reissue the certificate. I'm sure I don't need to elaborate on the information security implications in this case.

Re:Mixing insensitive and sensitive content

[tepples]

So what's a better practice for an ad-supported website that allows users to log in?

How does WebM splinter the Internet?

[tepples]

From the "development" trees in Chrome, to WebRT and WebM, they have splintered the internet numerous times with no advantage to the greater good.

VP8 is a royalty-free video codec whose rate/distortion performance is in the same league as the royalty-bearing MPEG-4 AVC. WebM is VP8 video and Vorbis audio in a Matroska container. Did Xiph likewise "splinter[] the Internet" by introducing Vorbis as a royalty-free competitor to the royalty-bearing MP3 and AAC audio codecs? If so, how? If not, then how did Google's On2 division "splinter[] the Internet" by introducing WebM as a competitor to MPEG-4?

Re:How does WebM splinter the Internet?

[Anonymous Coward]

Forget VP8 and go to VP9 and there is clear benefit using it over others.

Re:How does WebM splinter the Internet?

[Anonymous Coward]

Forget VP9 use Dalaa -- its the codec of the future

Re:How does WebM splinter the Internet?

[Anonymous Coward]

The very fact that they introduced another video codec, when they knew h264 was the dominant one, is proof enough. After all they said "ah, but we'll stop using h264 in a while and remove it from Chrome" to placate those concerns, only to reneg on that idea and leave TWO codecs in Chrome, forcing others to scramble and implement h264 support.

That said, Google wasn't forcing anyone. If anything, they could have put their feet down and said "no, h264 or bust" instead of trying to meet everyone halfway with WebM, only to turn around and go "Nah, we've changed our minds" a bit later.

Re:How does WebM splinter the Internet?

[PhrostyMcByte]

VP8 is a royalty-free video codec whose rate/distortion performance is in the same league as the royalty-bearing MPEG-4 AVC.

VP8 is not in the same league as AVC. Technologically it is largely a subset of AVC with quality somewhere between ASP and AVC. It is royalty-free now, but it wasn't always. When Google announced VP8 as a grand royalty-free codec, it was actually very obviously encumbered by patents that Google had no rights to and unfortunately thus offered literally no benefits.

It was only a year ago that Google and MPEG LA settled the issue, with Google getting a full license to those patents and the ability to sub-license to anyone they want.

What you have is Google very targetedly marketing VP8 to web devs as a Free/Open/Next-Gen to have them jump on a bandwagon to "splinter the internet". It was only thanks to Google's mammoth weight being able to negotiate with MPEG LA that all the traction it gained wasn't for naught.

Re:How does WebM splinter the Internet?

[tepples]

VP8 is not in the same league as AVC.

I thought it was roughly comparable to AVC baseline, though I admit not AVC main.

Do you disagree with Google's course of action? If so, what should Google have done instead to keep webmasters from having to pay royalties on the videos they show to users of desktop computers and Android mobile devices?

Re:How does WebM splinter the Internet?

[PhrostyMcByte]

I thought it was roughly comparable to AVC baseline, though I admit not AVC main.

You're right, I'm not sure why I said ASP. The difference in quality between AVC Baseline and High is still pretty immense though -- lack of proper B-frames is pretty significant just by itself

Do you disagree with Google's course of action? If so, what should Google have done instead to keep webmasters from having to pay royalties on the videos they show to users of desktop computers and Android mobile devices?

As someone who loves technology, I'd have loved to see us come to some understanding with MPEG LA to just license their stuff for all HTML5 use. VP8 is going to result in either a lot more bandwidth usage (at YouTube levels, quite an impressive lot more) or a lot less quality.

As someone who loves freedom and creativity, I'm happy that we have anything and I'm thankful for Google doing whatever undisclosed thing they did to release VP8 from patent shackles. I do disagree very much with their methods of stirring up so much support with flat out lies -- if they hadn't gone through with licensing it, there'd have been a lot of wasted work and potentially even people in legal trouble for using the format. It was very shady.

One worry I have is that the internet will become a bit like American broadcast TV. We're still sending the hugely inefficient MPEG2 over the air. A sort of "moving standard" agreement with MPEG LA would be pretty awesome -- do we want to still be using VP9 as anything but a legacy-supported format in ten years? twenty? The moment we want to jump on a new codec, or say we just continue to develop VP9 into VP10, It's all but guaranteed some of the next-gen techniques will already have been patented.

Re:How does WebM splinter the Internet?

[tepples]

I thought [VP8] was roughly comparable to AVC baseline

You're right, I'm not sure why I said ASP.

You might have been thinking of Theora, which as I understand it is comparable to ASP.

It's all but guaranteed some of the next-gen techniques will already have been patented.

I've got a feeling that that's part of why Red Hat has been having Monty make the Daala demo pages, as a sort of defensive publication to make the techniques part of the public record.

One worry I have is that the internet will become a bit like American broadcast TV.

Before Flash gained AVC support, that's sort of what the Internet already was. There were sites that used QuickTime video with Sorenson Video 3 codec, which was reportedly a prototype of H.264. There were sites that used Flash video with FLV1, which is Sorenson's H.263 codec. And there were sites that used DivX, a brand name for an ASP encoder, where ASP is a couple extensions to H.263.

SPDY doesn't solve the real issues

[Aethedor]

The biggest problem with SPDY is that it's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit from it. In my free time, I'm writing an open source webserver and by doing so, I've encountered several bad things in the HTTP and CGI standard. Things can be made really more easy and thus faster if we, for example, agree to let go of this rediculous pathinfo, agree that requests within the same connection are always for the same host and make the CGI headers work better with HTTP.

You want things to be faster? Start by making things more simple. Just take a look at all the modules for Apache. The amount of crap many web developers want to put into their website can't be fixed by a new HTTP protocol.

We don't need HTTP/2.0. HTTP/1.3 with some things removed, fixed or at least have some vague things be specified more clearly, would be more than enough for 95% of all the websites.

Re:SPDY doesn't solve the real issues

[phorm]

agree that requests within the same connection are always for the same host

I've worked in situations that involve a lot of load-balanced hosts, and routing of traffic is dependant on the URL. Requests within the same connection are definitely NOT always for the same host.

Re:If you are a programmer and have a Wikipedia pa

[YA_Python_dev]

Ah, the irony of using "security and privacy" to argue in favour of old unencrypted HTTP/1.1 and against always-encrypted SPDY (which HTTP/2.0 is based on).

Get back to HTML 1.0

[Anonymous Coward]

What I would like to see, is to scrap the whole HTML since HTML 1.0 and get back to basic text-only sites in most parts without most fanciest CSS/JS/PHP etc scripting.

Add just the basic features like what is the font and its style (bold, underline, color) and basic formatting (alignment, width, space between lines and paragraphs) and then way to get few pictures between or side of the text.

And every URL would need to be in the text itself and no image or specific area can be used to trigger anything or as URL.

Basically more like what Wikipedia is today, in more simpler manner even from it.

Then the commenting should be moved back behind NNTP.

There is nothing wrong with HTTP itself, but the pages sizes, elements etc are just blowed out to proportions where sites don't anymore serve the original idea of the WWW and purpose of the Internet.

Re:Get back to HTML 1.0

[Anonymous Coward]

You can browse the web with lynx if you like. The rest of us like our CSS. PHP is server-side so it makes no difference on what the client sees, so obviously you have no clue what you're talking about. > Add just the basic features like what is the font and its style (bold, underline, color) and basic formatting (alignment, width, space between lines and paragraphs) Oh, so you DO want CSS. > And every URL would need to be in the text itself Why? With the many (free) url-shortener services available, the creators of the website can easily obscure the actual urls from you, if they so desire. Unless you suggest removing http-redirect? And why would I want all these ugly urls in my text? Your browser can show where a link goes. And why would we ever want to go back to NNTP? Fucking luddite.

Tunnelling

[msobkow]

Maybe if we weren't trying to tunnel every god damned protocol and transport known to mankind through HTTP it wouldn't be such a massive problem to re-engineer and fix.

Seriously: The idea of TCP was to have multiple protocol ports, not to tunnel everything over :80.

Re:Tunnelling

[Aethedor]

Yeah, tell that to the firewall administrator who thinks that opening an extra port is far more insecure than to tunnel that extra connection via HTTP. The IT world is defined by a mass amount of incompetent administrators and developers.

Re:MITM from day one breaks key continuity managem

[fuzzyfuzzyfungus]

Those certainly are plausible (and unfortunately common) issues. That's why I was thinking of the "you want to make sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs" consideration. Annoyingly, that's the one that would require some sort of distributed observation system that you could talk to, rather than being comparatively trivial to do in software on your own system (as of right now, browsers don't usually provide a handy 'remember this domain's certificate and freak out?' button; but that's extension-level stuff to add). The thinking being that, short of the MiTM either compromising the observation system, or controlling so much of the network that their certificate looks like the trustworthy one, it would be impossible for a given attacker to present a false certificate to a numerous people in different parts of the world and connected to different parts of the internet.

Of course, the details of how to actually implement such a system, along with actually doing so, are a great deal trickier than just checking key continuity on the client...

Mixing insensitive and sensitive content

[Anonymous Coward]

Not everything served over HTTP served to a "web browser", nor is every payload a "page". Machine-to-machine communications, digitally-signed XML, single-user personal area networks, all come to mind.

Re:MITM from day one breaks key continuity managem

[NotInHere]

With certs you also want to have the property that everyone sees the same. The Bitcoin blockchain solves a similar problem: to prevent double spend the blockchain has to be the same for all parties. There is even a project trying to achieve that with the blockchain: Namecoin.

The disadvantage is that clients either have to download the whole blockchain and ask as many parties as possible whether there were any updates, to be sure they have the longest branch of the blockchain, or they have to trust some server that has done that for them.

Re:If you are a programmer and have a Wikipedia pa

[Anonymous Coward]

HTTP is a transport spec, not an encryption spec. Mixing the two will only lead to trouble.

Idealism in computing?

[Anonymous Coward]

This guy has never heard of version numbers or something? He thinks it's a better idea to design something that is perfect instead of using something that is useful for what it's designed for but less than ideal for a small percentage of use cases.

The problem is that when you write a new HTTP standard, that now becomes permanent. Just because HTTP 1.1 came out, that doesn't mean that you can simply abandon all HTTP 1.0 code. HTTP 1.0 code now lives on in perpetuity because it was an official standard, and there are still servers out there using it. Likewise, if we throw 2.0 out there with reckless abandon, we must now support 2.0 for all of eternity, no matter how flawed it may be.

The goal should be to get it right, not to throw new versions out every couple of months.

So was it a bad idea to introduce PNG beside GIF?

[tepples]

The very fact that they introduced another video codec, when they knew h264 was the dominant one, is proof enough.

"The very fact that Google introduced another touch-screen smartphone operating system, when they knew iOS was the dominant one, is proof enough."

After all they said "ah, but we'll stop using h264 in a while and remove it from Chrome" to placate those concerns, only to reneg on that idea and leave TWO codecs in Chrome, forcing others to scramble and implement h264 support.

You have one codec for people who also plan to serve to iOS and Flash Player (namely H.264) and one codec for people who plan to avoid paying royalties to MPEG-LA (namely VP8). It's the same reason that browsers added PNG alongside GIF: to allow webmasters to avoid paying royalties to Unisys.

First they came for the Commies, then...

[tepples]

So you aren't on one. I'm not on one. But you find it relevant?

I do, and so would anyone who appreciates Martin Niemöller's reasoning might:

First they came for the Communists, and never having voted for a Communist candidate, I STFU.
Then they came for people behind work, school, or public library proxies, and not being currently behind such a proxy, I STFU.
Then they came for members of the Jewish faith, and not being Jewish, I STFU.
And then they came for me.

Re:First they came for the Commies, then...

[AK Marc]

So, once we all have proxies, they'll kill the Jews. I don't think I agree with your logic.

Re:First they came for the Commies, then...

[tepples]

Then let me express it more prosaically: Even though I'm not a member of a particular group, I can still advocate for it. In this case, the group is people whose only readily available Internet connection is outgoing HTTP through a proxy.

Re:First they came for the Commies, then...

[AK Marc]

Yes, but they had to actually exist and actually be persecuted for your analogy to work.

I can still advocate for it. In this case, the group is people whose only readily available Internet connection is outgoing HTTP through a proxy.

Mattered more before I could get The Internet on my phone, easily bypassing any proxy in place. I've even tethered on a work PC while at work to bypass any work tracking, though I could get there, I couldn't do so without showing up in some logs somewhere. "people whose only readily available Internet connection is outgoing HTTP through a proxy" don't exist anymore.

!Insightful

[Anonymous Coward]

The committee member is simply pointing out that new standards that do not provide any new functionality do not get used, while standards that provide something useful get adopted much quicker. He also points out useful things that the new standard could/should address but isn't.

You make it sound like this guy is just throwing a hissy fit which is just bad form.

Re:!Insightful

[swillden]

The committee member is simply pointing out that new standards that do not provide any new functionality do not get used

But HTTP/2 does provide valuable new functionality, mostly around performance, with some security benefits as well. It just doesn't provide what he wants. Also, if you read the thread and notice who's involved you'll see there's not much question about it getting used. Mozilla, Opera, Apple and Microsoft are all involved and actively implementing on the browser side, and Apache and Microsoft are implementing on the server side. Google, of course, has had both sides in production for years.

He also points out useful things that the new standard could/should address but isn't.

Could address if the work in progress were thrown away and the committee went back to the drawing board.

You make it sound like this guy is just throwing a hissy fit which is just bad form.

I quite agree that "hissy fit" is a reasonable, if a bit overstated, characterization of his comments, and that said fit is bad form.

Perspectives

[tepples]

That's why I was thinking of the "you want to make sure that you aren't suddenly being fed a different certificate than people in other parts of the world, or on different ISPs" consideration. Annoyingly, that's the one that would require some sort of distributed observation system that you could talk to

I use a Firefox extension that does this, called Perspectives. The biggest hole in Perspectives is when the MITM is on the server's only upstream connection.

as of right now, browsers don't usually provide a handy 'remember this domain's certificate and freak out?' button; but that's extension-level stuff to add

Yes they do. If I visit an HTTPS site whose certificate doesn't chain to a trusted root CA, the browser gives me a warning, and I can remember the certificate. Perhaps the fear is that if browser makers improve the KCM user experience, people trying to visit a financial site (Chase, Ally, PayPal, etc.) might get suckered into using the KCM flow.

Again, what makes plaintext better?

[tepples]

What makes encryption with no authentication worse than plaintext?

It makes man in the middle attacks trivially possible and thus rendering the encryption useless.

This applies equally to plaintext and to encryption with no authentication. So what makes plaintext better?

Re:If you are a programmer and have a Wikipedia pa

[swillden]

Google, who gladly works hand in hand with the NSA

I have to call bullshit on this rather common but unsupported and unsupportable claim.

There is no evidence that Google had cooperated with the NSA in any way other than actually required by law, and there they claim to be sticklers in demanding that the government dot the i's and cross the t's, including refusing any requests that are overly broad. We can't see what they actually do, of course, because the law makes it illegal for them to say... however Google was the company that first started publishing transparency reports and took the initiative to negotiate permission to publish aggregate statistics about the requests they're legally prevented from publishing. Those published numbers make it clear that Google is not providing information about large numbers of users.

There is evidence that the NSA had an extensive operation in place tapping Google's internal network. When this was revealed, Google immediately accelerated plans to encrypt all of those links to foil the snooping.

Beyond that, look at Google's Internet security track record. Google was the first major webmail provider to switch to HTTPS. Google is still the only major web search engine that requires HTTPS. For logged-in uses, all Google services are all-encrypted, all the time, and for most services even users that aren't logged in get HTTPS by default. Yes, Google designed SPDY, and designed it without an unencrypted mode. The HTTP/2 committee may have added support for unencrypted operation, but Google didn't design it in. Google's next-gen protocol, QUIC, not only doesn't have an unencrypted mode, security is baked so deeply into it that it's basically impossible to remove or disable.

FWIW, I'm a Google engineer, and until recently my job was to work on part of the internal communications security infrastructure. It's vanishingly unlikely that Google could have had any kind of sanctioned NSA tap in place without it being visible to me, and I saw no hint of any such thing.

I happen to personally know several of the people involved with SPDY and there's no way any of them would be party to any attempt to deliberately weaken the protocol.

Beyond that, I can tell you that the internal response to the Snowden revelations about NSA access into Google was one of fury, and a deep and abiding commitment to make sure it can't happen again. Google wants to ensure that the only way the government can get data about Google's users is to come in through the front door, with appropriate court documentation.

[Google] is a Corporation whose core focus to track and monitor every single person and thing online?

This is also simply untrue. Google's core focus is in its mission statement, which you can search for. 90% of its revenue comes from targeted advertising, and Google does collect information to do that ad targeting... but only with user approval. If you don't want Google to track you, Google provides tools you can use to ensure you're not tracked. In the process you'll have to give up some (not all, but some) use of Google's services, because the targeted advertising is the fee you pay for those services. Google hopes you'll like that deal and be happy with it. But if you're not, Google wants to ensure you can opt out. See http://google.com/privacy/tool...

(Disclaimer: The above is not an official company statement. In fact, company policy encourages me not to make it (though policy doesn't prohibit me). It is, however, my firm personal view.)

Why is the web slow?

[gantry]

When a web page is slow to load, it is often because of all the data that must be loaded from 3rd-party sites - Google Analytics is one of the worst, but there is also Facebook, Twitter, etc (probably for 3rd-party logins). SPDY is not going to fix that. If Google wants to speed up the web, it should start by reducing the latency of its own services.

Re:If you are a programmer and have a Wikipedia pa

[jackd]

Blast. Out of mod points. But parent is one of the more insightful and balanced posts I've read on here in quite a while.

Re:So was it a bad idea to introduce PNG beside GI

[MatthiasF]

PNG was created for the greater good by committee and approved as a standard by the IETF, so no, it is nothing like WebM.

PNG was designed as patent free so there was never any treat of being sued if you used it.

Meanwhile, Google holds all of the patents for WebM and WebRTC. They have not released them to the public domain, so it is a power play and not a standard meant to improve the overall situation.

There is a huge difference between "royalty free" and "patent free". The former just means the guy with the club isn't demanding a toll today, while the latter means no one will ever get clubbed period.

Google licenses its WebM patents liberally

[tepples]

Google holds all of the patents for WebM and WebRTC. They have not released them to the public domain

Nor is Linux "released [...] to the public domain". It is copyrighted and distributed under GPLv2, a member of a class of copyright licenses known as "copyleft". What objection do you have to the way Google licenses its WebM-related patents?

Re:If you are a programmer and have a Wikipedia pa

[chefmonkey]

If you don't want Google to track you, Google provides tools you can use to ensure you're not tracked. In the process you'll have to give up some (not all, but some) use of Google's services, because the targeted advertising is the fee you pay for those services.

Ob "trading up privacy for services": http://www.smbc-comics.com/?id... ;-)

Re:If you are a programmer and have a Wikipedia pa

[swillden]

Can't argue with that. It is an issue. OTOH, I think social media is a much more serious issue in that respect than targeted advertising.

Cellular involves a recurring fee

[tepples]

Yes, but they had to actually exist and actually be persecuted for your analogy to work.

We already agreed that they "actually exist". I used to attend such a school, and you used to work for such an employer. If non-HTTP protocols were more widely deployed, then yes, people behind HTTP-only proxies would "actually be persecuted".

Mattered more before I could get The Internet on my phone, easily bypassing any proxy in place.

So your answer is to add a recurring fee, payable to a cellular carrier, of an estimated $500 per person per year plus $10 per GB overages. Besides, all it buys you is non-HTTP outgoing connections because cellular ISPs deploy carrier-grade NAT and thus their subscribers can't receive incoming connections.

PHK

[Anonymous Coward]

glad i clicked on the headline and read the summary. i was thinking PHK stood for 'Pointy Haired Kaiser'