Subject: IESG Statement on Maximizing Encrypted Access To IETF Information

From: The IESG <[email-masked]>
Date: Thu, 20 Aug 2015 12:36:40 -0700

Date: 20 August 2015

The IETF has recognised that the act of accessing public information 
required for routine tasks can be privacy sensitive and can benefit from 
using a confidentiality service, such as is provided by TLS. [BCP188] 
The IETF in its normal operation publishes a significant volume of 
public data (such as Internet-drafts), to which this argument applies. 
The IETF also handles non-public data (such as comments to NomCom, the 
IETF's nominating committee) that requires confidentiality due to the 
nature of the data concerned.

The IESG and the broader community [moz-https-only] have further 
concluded that there can be other harmful effects in continuing to 
access public data as cleartext. Recent massive-scale man-on-the-side 
intermediary attackers have been seen to take advantage of the absence 
of security to mount active attacks that would be more difficult had a 
transport security mechanism such as TLS been used. [great-cannon, 
quantum]

The IESG has therefore agreed that all IETF information must, by 
default, be made available in a privacy-friendly form that matches 
relevant best current practices. Further, all future embedded 
interactions with the IETF (such as <a> tags in HTML) should default to 
causing access via that privacy-friendly form. For content currently 
accessed using the HTTP protocol, using HTTPS URIs and appropriate TLS 
cipher-suites [BCP195] will be the preferred access mechanism, however 
this direction encompasses more than HTTP traffic alone.

However, as there may be tools affected by this, and recognising that 
there are a number of IETF participants who prefer to continue to access 
materials via cleartext, or who have issues with using standard 
confidentiality services, the IESG are also requiring that public 
information continue to be made available in clear, for example via HTTP 
without TLS.

The changes caused by this statement should only need operational 
systems work and should be transparent to almost all consumers of IETF 
information. There are a small number of cases where these changes might 
cause some issues, e.g., the current Internet-Draft boilerplate text, 
which uses the http: URI scheme. The IESG will work with the broader 
community, tools teams, and IETF Secretariat to make these adjustments 
while minimising disruption to the community.

Note that the "secure/privacy-friendly as the default according to best 
practices" principle set out in this statement applies to all IETF 
information, regardless of the protocol used to access that information.

References

[BCP188] https://tools.ietf.org/html/bcp188

[great-cannon] https://citizenlab.org/2015/04/chinas-great-cannon/

[moz-https-only] https://blog.mozilla.org/security/2015/04/30/
deprecating-non-secure-http/

[quantum] https://www.wired.com/2014/03/quantum/

[BCP195] https://tools.ietf.org/html/bcp195