Internet Architecture Board


IAB Comments on The HTTPS-Only Standard

Home»Documents»IAB Correspondence, Reports, and Selected Documents»2015»IAB Comments on The HTTPS-Only Standard

9 April 2015

The Internet Architecture Board (IAB) is pleased to submit the following comments on the proposed HTTPS-Only Standard[1] to the US office of the Chief Information Officer.

We have recently issued a statement on Internet confidentiality and how that can help restore the trust users must have in the Internet.[2] Government information and web services are increasingly critical resources as civic interactions move online, requiring the confidentiality and integrity that encryption provides. The HTTPS-Only Standard represents an important initiative in securing United States government web domains and the draft standard is generally clear and technically sound. We welcome the initiative for leveraging Internet standards to promote private and integrity-assured access to government information.

We have a number of detailed comments for your consideration, itemized below.

Thank you again for the opportunity to comment on this effort and please do not hesitate to contact the IAB for further clarification.

Detailed Comments

  • “Home” document:
    • While integrity is recognized as an important goal of HTTPS-Only throughout the document, it is explicitly missing from the “Goals” subsection. We suggest adding a separate sentence that highlights the goal of integrity: “In addition, HTTPS ensures the integrity of the exchanges, making sure that pages and documents cannot be modified when they traverse the network.”
    •  In the “Background” section the link to the IAB Statement on Internet Confidentiality points to an Internet Society endorsement of the statement instead of the original statement as posted on the IAB web site. We recommend changing the link from to .
    • In the section titled, “Challenges and Considerations” the item on Server Name Indication should recognize that in addition to performance considerations, in some cases domains and subdomains may themselves be sensitive, for example (which does not currently exist, but is used for illustrative purposes here).
    • In the “Challenges and Considerations” Section, the item on mixed content should recognize that poorly-configured third-party HTTPS page elements can be a risk to the security of the entire page. That is to say, while the document recognizes that it is important for government HTTPS tools and configurations to adapt to known vulnerabilities, it is equally important to ensure that third-party services and page elements served over HTTPS also quickly adapt.[3]
  • “Why Everything?” document:
    • The following statement is not necessarily correct, “Originally invented just for websites, HTTP is now the primary protocol used by computers, tablets, smartphones, and many other devices to communicate over the vast public Internet.” While HTTP is a very important protocol on the Internet, it operates at a specific layer of network communication, on top of other protocols. We would suggest changing this sentence to instead read, “HTTP is currently a primary protocol for applications used on computers, tablets, smartphones, and many other devices.”
    • The section “Privacy by default” might be more accurately titled, “Privacy and integrity by default”.
    • As mentioned above, the link to the IAB Statement on Internet Confidentiality should point to the IAB-hosted version of this document rather than the Internet Society endorsement of the IAB document.
  • “Server Name Indication” document:
    • This document should have a new section that acknowledges that some domains and subdomains can be sensitive, so care must be taken in provisioning them, if possible, to not unduly reveal sensitive information, since SNI is exposed outside the encrypted part of a TLS handshake. For example, or (neither of which exist at this time) could be very revealing, and should be carefully considered before provisioning.
  • “Mixed Content” document:
    • As mentioned above, it is important that even secure third-party content be regularly evaluated against new HTTPS vulnerabilities. We are uncertain if guidance here belongs in the Mixed Content document or if it should be part of a new document in the HTTPS-Only Standard that addresses ongoing maintenance and grooming of TLS configurations, for example using tools like the Qualys SSL Labs’ server testing tool:

[2] Internet Architecture Board, “IAB Statement on Internet Confidentiality,” (November 14, 2014) available at:
[3] For example, in a recent Australian government internet election, a third-party analytics service was found to be vulnerable to injection due to their HTTPS configuration being vulnerable to the recently-reported FREAK vulnerability. See: Vanessa Teague and J. Alex Halderman, “Security flaw in New South Wales puts thousands of online votes at risk,” Freedom to Tinker (March 22, 2015), available at: