Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

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.

Received on Tuesday, 13 January 2015 00:06:25 UTC