The IESG has formally approved the HTTP/2 and HPACK specifications, and they’re on their way to the RFC Editor, where they’ll soon be assigned RFC numbers, go through some editorial processes, and be published.
The IESG has formally approved the HTTP/2 and HPACK specifications, and they’re on their way to the RFC Editor, where they’ll soon be assigned RFC numbers, go through some editorial processes, and be published.
http://http2.github.io/faq/
Edited 2015-02-18 13:53 UTC
no mandatory encryption
I wonder why…
Long political story.
Doesn’t matter though, none of the major browser vendors will support http/2 without TSL – that’s already confirmed.
The problem with mandating encryption is that it infects the design, rendering it useless when it gets exploited. Encryption should be proposed separately to allow easy replacement and updating.
Yep, no conspiracy theory needed here.
mandating encryption is not the same as mandating a specific cipher
Then why is it even necessary to mandate it? That’s like mandating that it needs to be transmitted over copper or fibre optics or wireless.
I don’t get people.
Some are upset when encryption isn’t required, because of privacy concerns. Some are upset when encryption is required because it often means that certificate authorities are involved and the minimal fees associated with that.
I have the issue with the Certification process. Just because you pay money, it somehow makes you more legit then someone who doesn’t. Back in them olden days, to get a Cert you really needed to prove who you are.
This.
The problem with encryption nowadays is not with encryption itself, the problem is with the CAs. They suck. They simply do not do what they were supposed to do (namely act as a trusted source of identity verification).
Yes, it is infinitely cheaper now to get a cert than it used to be. It is so cheap and easy that there is no longer any point. There are tons of CAs that simply cannot be trusted (most of them?), because they issue certificates without doing any real identity verification. The process has been watered down so much there is no point anymore.
The only real “verification” that is done meaningfully anymore is domain ownership (some CAs even f*ck that up ). We don’t need CAs for that, we can just use DANE (as others have mentioned).
Of course CA’s should check if you really are who you say you are. And of course it is clear that they do a bad job at that.
But yes, in general if you have to pay for something, even a bit, that makes you more legit than if you don’t have to pay anything. There is a reason that SPAM greatly reduces if you charge 1 cent per mail. Certs should be cheap, but having a small fee is actually a big barrier. Not a barrier that will keep everything safe, but a big barrier anyway
avgalen,
Yes it’s true that CA’s have been getting worse in a race to the bottom. There is still merit for some websites to use the real CAs to identify WHO the operator is. If I go to citibank.com, it’s good to know that CitiGroup Inc is behind it.
But for many other kinds of websites we don’t care about the identity of the entity behind the website. Who is the legal entity behind osnews.com? I don’t know and don’t really care, I only care that the traffic isn’t being intercepted/manipulated by third parties outside of osnews.com.
My preferred solution is something like DANE, where the owners of osnews.com can generate their own certificates directly without depending on any 3rd parties to do it for them. 3rd parties who are not in control of the domain can generate false certificates all day long, but they won’t be able to attach those fraudulent certificates to the domain.
The “domain verification” certificates in the CA model don’t have this property. Others have criticized the CA model based on modest costs, however I’d like point out that it’s actually less secure than DANE because there is nothing technically stopping them from generating bad certificates (intentionally or accidentally) without the owner’s authorization. The CA model forces us to trust *all* CAs, even those we don’t have any business relationship with.
I’ve noticed one more thing I find troubling, some CAs charge to revoke “free” certificates. I understand they don’t want to provide everything for free, but it’s another advantage for DANE, which entitles all domain owners to manage certificates on their own.
http://www.startssl.com/?app=25
I recently set up DANE on my own domain* and discovered that it unfortunately does not look like it is ever going to become widespread. Mozilla has it as a low-priority TODO ( https://bugzilla.mozilla.org/show_bug.cgi?id=672600 ); it looks like they might accept a patch if someone wrote it, but I don’t know their codebase and certainly don’t feel comfortable adding security-critical code to it. Worse, Google has the bug marked as WontFix ( https://code.google.com/p/chromium/issues/detail?id=50874 ) in favor of HTTP Public Key Pinning.
I sorta just ended up writing an anti-HTTP Public Key Pinning rant, which in favor of not posting a wall of text here will probably become a blog post. The summary is that HTTP Public Key Pinning has troubles with revoking a key in an emergency that DANE does not suffer from due to needing to pin keys for a long time (months) in order for the security guarantees to be meaningful.
*I also wrote a blog post on how I did it without running my own DNS server: https://aweirdimagination.net/2015/02/19/dnssec-on-hosted-dns/ .
AnyoneEB,
Great points, the responsibility lies with browser makers to kick-start the industry. So it’s very sad that the browser makers who are absolutely essential for DANE to succeed are ignoring the need for it. I think it would be immensely popular by website operators assuming it was widely supported by clients (Thom: any input?)
I agree with you about Pinning, it’s clearly not a substitute for either CAs or DANE. While it can be used to detect when those certificates change, that can cause confusion even when there’s absolutely nothing wrong. An end user is in absolutely in no position to know if a change is legitimate or not (without a CA or DANE).
Ok, then try getting geohost to issue a cert for google.com.
If, as you say,
If you just had encryption without identification… well that doesn’t really help. You need both for secure transmission. Which is why we have the system we currently have, and why the browsers freak out with self signed certs.
I understand that the identification of foo.com doesn’t mean that foo.com is a trust worthy site that won’t post your social security number to pastebin. It just means that its foo.com.
The extended validation cert, is supposed to provide more proof that you are trustworthy as a company as well.
Its not a perfect system we have. But it just seems crazy that people want to make it less perfect. But, then again, there are tons of people that don’t understand even more basic security stuff, so I think I just need to adjust my expectations.
Bill Shooter of Bul,
Yep. Encryption is good, but it shouldn’t be dependent upon 3rd party CAs. I don’t believe in 3rd party CA’s for a number of reasons, and I don’t think it’s reasonable to mandate encryption until our web standards also mandate support for self-signed certificates that eliminate 3rd party control over web encryption. DANE, as mentioned by evert, accomplishes this:
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Enti…
Edited 2015-02-18 19:32 UTC
Because encryption is not needed every time. When you host a blog you want as many people to read as possible, encryption serves no purpose. The content is public anyway. However, encryption prevents caching and therefore has a negative impact on bandwidth, load time and ping.
Encryption also increases the changes of seeing the blog in question instead of other injected content.
Does anyone know if DANE will be supported?
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Enti…
Unfortunately, it looks like DANE isn’t happening, at least not for HTTPS: http://www.osnews.com/thread?605689