| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 28, 2007.
Copyright © The IETF Trust (2007).
The world wide web consists of sites served via the inssecure HTTP protocol and the encrypted HTTPS protocol. When using HTTPS, browsers employ public key certificates to perform domain authentication---cryptographic verification of the association between the website's domain name and its public key. When using HTTP, browsers connections to websites are vulnerable to any network intermediary capable of intercepting packets to, and forging packets from, the website (commonly known as a "man-in-the-middle attack").
As browsers default to the insecure HTTP protocol, security critical websites instruct browsers to activate HTTPS using HTTP-based redirection. As this redirection is performed via an insecure protocol, the activation of HTTPS is vulnerable to a man-in-the-middle attacks. To prevent attacks that would subvert the activation of HTTPS, browsers provides security indicators that are present only when HTTPS is in use (e.g. the padlock icon). The absence of these indicators on a site that should only be served via HTTPS is evidence of a man-in-the-middle attack. However, Empirical evidence shows that even when users are about to perform security critical tasks on pages that should always be served via HTTPS, they are unlikely to verify the presence of HTTPS indicators.
The proposed HTTPSSR DNS resource record signals to browsers that a website requires HTTPS, enabling browsers to activate domain authentication automatically without relying on HTTP-based redirections. When combined with DNSSEC, this mechanism protects users against man-in-the-middle attacks that could circumvent that activation of HTTPS.
1.
Introduction
2.
Requirements notation
3.
Prerequisites
4.
Record format
4.1.
The Version Byte
4.2.
The ForceHTTPS Character
4.3.
CertFingerprint Entries
5.
Textual representation
6.
Client guidelines
7.
IANA Considerations
8.
Security Considerations
9.
Acknowledgements
10.
References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
To establish a secure connection to a web site, browser users must type an HTTPS URL (a URL that begins with the HTTPS scheme) or use a bookmark to an HTTPS URL. Because few users know to type "https://", many web servers use insecure HTTP-based redirects to activate domain-authentication. This HTTPS activation step is vulnerable to man-in-the-middle attacks. To prevent such attacks that subvert domain authentication, users are expected to verify that HTTPS is active.
The security assumption that users will verify the presence of HTTPS before performing security critical tasks has proven to be overly optimistic. In a security usability study, 25 of 25 participants entered their own online banking passwords into an online banking website even though their browser behaved as it would if the participants were connected to a malicious network intermediary (man-inthe-middle attacker)---HTTPS was not active [Emperor] (Schechter, S., Dhamija, R., Ozment, A., and I. Fischer, “The Emperor's New Security Indicators: An evaluation of website authentication and the effect of role playing on usability studies,” May 2007.).
Websites can employ the proposed HTTP Service Security Requirements resource record (HTTPSSR) to instruct web clients (browsers) to use only HTTPS to access the website. The record may also inform web clients of an additional security requirement: that the certificate used to authenticate the site was issued by the certification authority chosen by the site.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
HTTPSSR SHOULD be deployed in conjunction with the DNS Security standards, also known as DNSSEC ([RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.), [RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.), and [RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.)). DNSSEC is necessary to protect the record against man-in-the-middle attacks.
| TOC |
The HTTP service security requirement (HTTPSSR) resource record is both specified and stored as a one octet version number (unsigned value 0 to 255) followed by a single <character-string> (as defined in [RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)).
The <character-string> contains the Requirements specified in the HTTPSSR syntax.
The following is a formal description of the HTTPSSR syntax, using the ABNF notation documented in [RFC2234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” November 1997.):
Requirements = ForceHTTPS [CertFingerprints]
ForceHTTPS = "Y" / "S" / "N"
CertFingerprints = CertFingerprint [CertFingerprints]
CertFingerprint = "|" HashAlgorithm "|" HashValue
HashValue = Base64
Base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )
base64_terminal = (2base64_char "==") / (3base64_char "=")
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
DIGIT = %x30-39 ;; Digits 0-9
ALPHA = UPALPHA / LOALPHA ;; case insensitive
UPALPHA = %x41-5A ;; Uppercase: A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z
Base64 is a base64 string as defined in [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.).
HashAlgorithm is the name of a hash algorithm. It SHOULD match exactly a case-sensitive name contained in the IANA registry named "Hash Function Textual Names" that was created by [RFC4572] (Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” July 2006.). All client implementations that support CertFingerprints SHOULD minimally support "sha-1".
We will now provide an overview of the version byte, ForceHTTPS character, and CertFingerprint entries. Additional guidelines for clients will then be presented in Section 6 (Client guidelines).
| TOC |
HTTPS-SSR records written for this draft MUST set the version number to 0. A client written to this version of the the HTTPSSR standard MUST ignore all records containing versions greater than 0.
| TOC |
A value of "Y" informs the client to activate HTTPS. The client MUST NOT connect to the site via insecure HTTP. A value of "S" informs the client to force HTTPS activation before connecting to the site if the client supports HTTPS. A client that supports HTTPS MUST NOT connect to the site via insecure HTTP. A value of "N" informs the client that the site can be reached via HTTP.
An HTTPS-enabled client MUST NOT connect to the site using HTTP unless the ForceHTTPS is set to "N" or no HTTPSSR record is present.
A client that does not support HTTPS MUST NOT connect to the site if ForceHTTPS is set to "Y". (A setting of "Y" is appropriate if the only content ever served via HTTP is a redirect to HTTPS.) A client that does not support HTTPS MAY connect to the site if ForceHTTPS is set to "N" or "S".
| TOC |
CertFingerprint entries inform clients to perform additional validatation steps to authenticate HTTPS server certificate chains.
Each CertFingerprint contains an algorithm name and a base64 encoded hash value (fingerprint).
If HTTPS is not in use, or the algorithm in a CertFingerprint entry is unknown to the client, the client SHOULD disregard the CertFingerprint entry.
If HTTPS has been activated and a CertFingerprint entry contains an algorithm that is known to the client, it SHOULD use the CertFingerprint entry to perform an additional check on the server's certificate chain. The certificate chain SHOULD be treated as valid if, and only if, it contains a certificate C such that HashAlgorithm(C) = HashValue.
CertFingerprint entries are intended to protect sites from certification authorities that fail to adequately authenticate domain name owners before issuing certificates. Without this record, an attacker need only fool one of the many certification authorities in order to obtain a valid certificate for a domain he does not own. Using this record, a site that is the customer of one certification authority can prevent an attacker from exploiting a certificate erroneously issued by another certification authority.
| TOC |
The Version octet is represented as a unsigned decimal ("0" to "255").
The Requirements field is a single string, but can be represented as one or more <character-strings> which are appended together.
The following are two different textual representations of the same HTTPSSR resource record
foo.example.com 700 IN HTTPSSR 10 (
"Y|sha-1|tM2bbXbmt8bGK2KJfot77g3NuC8|sha-256|"
"SepjSG9ldY6r7AB5rZKVN5u1i/ehRt36b499ZdPbrms")
foo.example.com 700 IN HTTPSSR 10 ( "Y|"
"sha-1|"
"tM2bbXbmt8bGK2KJfot77g3NuC8|"
"sha-256|"
"SepjSG9ldY6r7AB5rZKVN5u1i/eh"
"Rt36b499ZdPbrms")
| Figure 2 |
| TOC |
A DNSSEC-aware client MUST NOT consider the use of insecure HTTP to be permissible until one of the following three facts can be established:
For purposes of efficiency, clients MAY choose to pre-fetch contents via HTTP before determining whether such requests should have been issued via HTTPS. Clients may pre-fetch using HTTP as long as they do not perform any security-sensitive actions before determining that the use of HTTP is permissible.
Security-sensitive actions that MUST NOT be performed until the use of HTTP is known to be permissible include all of the following:
Clients that support HTTPSSR CertFingerprints MUST NOT perform security-sensitive actions via HTTPS without first validating all CertFingerprint values with known hash algorithms. Clients that choose not to support CertFingerprints MAY attempt to pre-fetch content or perform security-sensitive actions via HTTPS before establishing the status of the HTTPS-SSR record.
Clients MAY handle HTTPSSR records from unsigned zones as they would from signed zones. The values in the record can only increase the confidentiality and integrity of a web request. While a bogus HTTPSSR record could prevent access to a legitimate HTTP or HTTPS server, this does not significantly increase the risk of such an attack; any attacker capable of introducing a forged HTTPSSR record to deny access to a site could accomplish the same goal by forging an invalid DNS address record.
When accessing a URL that contains an HTTPS prefix, the client MUST NOT fallback to HTTP as a result of any information contained in the HTTPSSR record.
If a client receives multiple valid HTTPSSR records with version number "0", it SHOULD treat all CertFingerprint entries as if they came from the same HTTPSSR record and enforce the most stringent of the ForceHTTPS requirements found. (If any ForceHTTPS requirement is "Y", enforce Y. If no ForceHTTPS value is "Y" but one or more is set to "S", enforce "S". If all ForceHTTPS values are "N", enforce "N".)
| TOC |
This document updates the IANA registry "DOMAIN NAME SYSTEM PARAMETERS" [http://www.iana.org/assignments/dns-parameters] in sub-registry "TYPES", by defining the HTTPSSR RR type.
| TOC |
The integrity of the HTTPSSR resource record is only as secure as any other record stored within the domain name system.
HTTPSSR add additional authentication checks to web connections, and never remove these checks. As such, HTTPSSR can only increase the confidentiality and integrity of connections. An attacker capable of forging a site's HTTPSSR records would be able to render that site unavailable, or to increase load on the site by redirecting HTTP traffic to HTTPS. This is not a concern because any attacker capable of forging a site's DNS records is already capable of rendering that site unavailable. For example, the attacker could simply forge the web site's IP address records.
| TOC |
Stuart Schechter would like to thank Andy Ozment (Cambridge), Wes Hardaker (SPARTA), Olaf Kolkman (NLnet Labs), Scott Rose (NIST), and Sam Weiler (SPARTA) for comments on earlier drafts of this specification. The author would like to thank Mike Beltzner (Mozilla), Darin Fisher (Google), Rob Franco (Microsoft), Eric Lawrance (Microsoft), Tariq Sharif (Microsoft), and Daniel Veditz (Mozilla) for their early feedback on the ideas that led to this specification and for help in defining its scope.
This work is sponsored by the I3P under Air Force Contract FA8721-05-0002. Opinions, interpretations, conclusions and recommendations are those of the author(s) and are not necessarily endorsed by the United States Government. This work was produced under the auspices of the Institute for Information Infrastructure Protection (I3P) research program. The I3P is managed by Dartmouth College, and supported under Award number 2003-TK-TX-0003 from the U.S. Department of Homeland Security, Science and Technology Directorate. Points of view in this document are those of the authors and do not necessarily represent the official position of the U.S. Department of Homeland Security, the Science and Technology Directorate, the I3P, or Dartmouth College.
| TOC |
| TOC |
| Stuart E. Schechter | |
| MIT Lincoln Laboratory | |
| 244 Wood Street | |
| Lexington, MA 02420 | |
| US | |
| Phone: | +1 781 981 2683 |
| Email: | stuart@post.harvard.edu |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).