>To be clear - we will still define how to use HTTP/2.0 with http:// URIs, because in some use cases, an implementer may make an informed choice to use the protocol without encryption. However, for the common case -- browsing the open Web -- you'll need to use https:// URIs and if you want to use the newest version of HTTP.
Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!"
> Someone explain to me when "an informed choice" would ever come to the conclusion of, "Encryption? Not Necessary!"
I've been informed that encrypted web traffic costs money for the certificate and for additional server hardware. Thus I made the informed choice to use HTTP/2.0 without encryption.
>encrypted web traffic costs money for the certificate and for additional server hardware
1.) You can make and self sign your own cert. As another poster pointed out, there's also distributed solutions.
2.) When we let standards that are going to be in-place for at least a decade be manipulated by the hardware costs at their inception, it's a bad standard.
Unencrypted HTTP/2 is for host-internal communication, ie. between app servers and public endpoints. Firefox and Chrome are both only going to support HTTPS for HTTP/2.
90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption. Encryption only really comes handy when confidential information and authentication credentials get exchanged.
Now if you provide authentication by other means, and confidentiality of the traffic not important, plain text protocols make sense because it enables caching proxy.
Typical use case: software updates distributed as signed packages. The information isn't very confidential, and using plain HTTP enables the usage of a caching local proxy.
> 90% of the time the desirable quality of TLS traffic is authentication of the server, not encryption.
Authentication of the server is not sufficient, you also have to authenticate every message as having a valid checksum and signature.
>Typical use case: software updates distributed as signed packages
This is a specific use-case because the package checksums are verified before any of the code is executed (unlike injected javascript to webpages). Also the checksum is usually obtained from the package server, so if SSL is broken the checksum can be spoofed as well.
> Do you perhaps mean "cryptography" rather than "encryption"?
That's true the poster said authentication of the server, if you sign every message cryptographically, you'll be able to detect message tampering. I should edit that.
>Encryption only really comes handy when confidential information and authentication credentials get exchanged.
It's 2015 and we have quad-core processors in phones that are faster than my laptop. What reason can anyone possibly have to not at least strive to encrypt everything? When is it advantageous to not encrypt?
Thanks for making HTTPS non-mandatory in HTTP/2, IETF!!