Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"

From: Xiaoyin Liu <[email-masked]>
Date: Tue, 2 Jun 2015 05:37:46 -0400

Hi,
 
I support this IESG statement. Here are my suggestions on how to implement this statement:
 
1) Fix all the mixed content issues on the IETF websites, such as https://tools.ietf.org/wg/dprive/draft-ietf-dprive-problem-statement/, which contains JavaScript loaded from http://trac.tools.ietf.org/tools/trac/htdocs/js/jquery.js.
2) Change all hardcoded http links to protocol relative or https, such as the "List Archive" link on [1].
3) Add <link rel="canonical" href="https://..."> to every page, so that search engines will prefer to index HTTPS links.[2][3]
4) Enable HTTP Strict Transport Security for every IETF subdomains, and submit ietf.org to the HSTS preload list.[4] I know that the IESG still wants cleartext content to be available. But I think HSTS is very important. There are many HTTP links to IETF on the Internet, such as those on our mailing lists, that are unlikely to update regardless of this statement. HSTS can help in this case. People using non-browser clients, IE, and old phone browsers are not affected by HSTS.
5) Please ask the RFC Editor Team to update their website (https://www.rfc-editor.org/) according to this IESG statement as well. Currently there is no way to submit or view RFC errata over HTTPS. https://www.rfc-editor.org/errata.php redirects to http://www.rfc-editor.org/errata.php.
 
Thanks!
Xiaoyin Liu
 
[1] https://datatracker.ietf.org/wg/appsawg/documents/
[2] https://tools.ietf.org/html/rfc6596 
[3] https://support.google.com/webmasters/answer/139066?rd=1#https
[4] https://hstspreload.appspot.com/

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 12:47:55 +0100

Thanks for the good set of proposed actions. I've added those
to a list I'm keeping.

They also all look good, though I think we'll need to figure out
the right thing(s) to do to combine HSTS with the current draft's
concept of plaintext access remaining available. (We do have >1
(sub)domain though, so that may help.)

S.