Dear IETF HTTP WG @w3.org,
I would like to express my disappointment with the HTTP/2 specification.
I believe that it fails to appropriately address RFC 7258 / BCP 188.
http://tools.ietf.org/html/bcp188
http://tools.ietf.org/html/rfc7258
"Pervasive Monitoring Is an Attack"
Specifically, as a non-profit operator of multiple independent web-sites
that do not warrant yearly acquisition and updates of CA-signed
certificates, I am not pleased that HTTP/2 fails to include
opportunistic encryption as part of the `http://` address scheme (and,
according to http://queue.acm.org/detail.cfm?id=2716278, appears to even
fail to require http:// address scheme support in the first place,
effectively declaring all of us small independents as second-class
citizens).
These are some of the specs for opportunistic encryption that should
have possibly been made an integral part of HTTP/2 in compliance with
BCP 188, but didn't:
http://tools.ietf.org/html/draft-hoffman-httpbis-minimal-unauth-enc-01
"Minimal Unauthenticated Encryption (MUE) for HTTP/2"
http://tools.ietf.org/html/draft-nottingham-http2-encryption-03
"Opportunistic Encryption for HTTP URIs"
I have not deployed the https:// address scheme on any of my
non-commercial web-sites, and do not plan on ever doing so, for the
following major reasons:
0. The https:// address scheme is not backwards compatible with http or
even with https itself:
0.0. If someone clicks an https:// link, but their browser does not
support https (maybe someone wants to visit my site from North Korea, or
a WiFi sponsored by advertisements that only allows non-https
connections, or a public office that administratively prohibits https
connections), then they will be left disappointed. They should instead
be able to receive the non-encrypted version of the site, or an
ad-filled copy of the web-site (my sites serve no ads), instead of being
denied access outright.
0.1. Similarly, the https:// address scheme is not even compatible with
https itself. Due to this incompatibility of https with https, as a
web-site operator, one would be forced to either support broken and/or
insecure SSL and TLS specs and/or ciphers that are not deemed BCP, and
also engage in IPv4 address space waste for SNI-less clients, or to
effectively engage in breaking and dividing the linked web again, since
the https:// links wouldn't work in the slightly outdated browsers.
As a side note, I would also like to point out that even
http://cr.yp.to/ is not available over https, and most likely never will
be, most certainly due the compatibility issues as above. Somewhat
ironic, especially considering that the operator is also the author of
ChaCha20 and Poly1305 ciphers used in TLS, and the domain name of the
site is a domain hack of the word "crypto".
In the current situation, should any operator decide to enable
"https://"; address scheme with TLS 1.2 only, and only with
ChaCha20-Poly1305 cipher suite, it is clear that many users will stop
being able to access the site by following the linked web (and other
users who are instead able to access such sites through https will
undoubtedly start linking to such sites with the https:// address
scheme), diminishing the linking potential of the world wide web as a
whole. In contrast, this wouldn't be the case should opportunistic
encryption be deployed as part of the http:// address scheme instead.
1. Administrative costs for https:// address scheme are prohibitive:
1.0. This concerns the initial certificate (and IPv4) acquisition.
There are some efforts being made to simplify this process
(LetsEncrypt), however, they are still not the reality. I'm not even
talking about SNI or lack thereof (Android 2.3 doesn't have SNI, for
example, and it hasn't been that long since it stopped being shipped
mainstream), so, in practice, this also involves IPv4 address space
waste and the associated non-trivial monthly costs.
1.1. The more important part is the continued maintenance. The fact
that it is considered a best practice for the certificates to be issued
on a yearly basis conflicts with the idea of the set-it-and-forget-it
mentality. Let's face it, many useful web properties on the internet
are left abandoned without updates for years, yet many of them remain of
interest.
(Or do you suddenly think that http://ipv6samurais.com/ and
http://www.itojun.org/ has no place to be? Itojun, RIP. Or would you
enjoy a big warning on http://www.kohala.com/start/? W. Richard
Stevens, RIP.)
The https address scheme is not sustainable here, because it would start
generating warnings about any such site (and that would even be the best
case scenario, since 0.1 above might preclude any access to any such
site in the first place, due to the failed TLS negotiation).
Additionally, some people just don't like using SSL, for whatever
reason. http://ftp.rodents-montreal.org/mouse/rodents-domain.txt
HTTP/2 is not backwards compatible with such users, because the http://
address scheme is effectively being made obsolete by no longer being
required to be implemented, without a good reason.
Why should users of older hardware supported by modern operating systems
like NetBSD be precluded from having an option of having the encryption
turned off? This goes back to the legally-barred-from-having-privacy
and the CO2 points raised by PHK over in another reply in this thread
and at http://queue.acm.org/detail.cfm?id=2716278.
For the record:
a) I'm an operator of http://BXR.SU/ -- Super User's BSD Cross Reference
-- a web-site containing 100k+ pages. I am highly interested in
deploying opportunistic encryption for the site. As per above,
deploying the https:// address scheme is completely out of the question
for me, because it will result in denial of access to my site and broken
links, and involve an unreasonable amount of extra administrative work
in updating the certificates on a yearly basis, skyrocketing the
maintenance time required.
b) I'm additionally the operator of http://mdoc.su/ -- short manual page
URLs -- a service of semantic URLs for man.cgi of FreeBSD.org,
OpenBSD.org, NetBSD.org and DragonFlyBSD.org, implemented through
nginx.conf location and rewrite rules alone. I believe there is no need
for any kind of encryption scheme for such service, opportunistic or
not. I do not appreciate the sentiment of the HTTP/2 movement to
effectively declare that my site is obsolete due to the lack of the
https address scheme support.
I believe that the agenda of mandatory switching to https:// for
everything conceivable, with loud warnings otherwise, goes in violation
of the rights and interests of independents like myself who have neither
the administrative nor the lobbying resources to follow or fight such
change.
I am sincerely asking for the IETF to not approve HTTP/2 as a standard
without the compatibility issues as above being addressed first. The
policy to abandon the http:// address scheme and adopt https:// will
only promote a significant link rot for the future generations to
experience well into the future (didn't we think TLS 1.0 was good
enough?), and will curtail independent and hobbyist operators.
Best regards,
Constantine A. Murenin,
MMath CS, UWaterloo '10.