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.
On 02/06/15 10:37, Xiaoyin Liu wrote:
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/