Network Working Group S. Schechter Internet-Draft MIT Lincoln Laboratory Intended status: Standards Track April 26, 2007 Expires: October 28, 2007 Storing HTTP Security Requirements in the Domain Name System draft-schechter-HTTPSSR-00.txt Status of this Memo 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 Notice Copyright (C) The IETF Trust (2007). Schechter Expires October 28, 2007 [Page 1] Internet-Draft DNS HTTPSSR RR April 2007 Abstract 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. Schechter Expires October 28, 2007 [Page 2] Internet-Draft DNS HTTPSSR RR April 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 3. Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Record format . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. The Version Byte . . . . . . . . . . . . . . . . . . . . . 8 4.2. The ForceHTTPS Character . . . . . . . . . . . . . . . . . 8 4.3. CertFingerprint Entries . . . . . . . . . . . . . . . . . 8 5. Textual representation . . . . . . . . . . . . . . . . . . . . 10 6. Client guidelines . . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Schechter Expires October 28, 2007 [Page 3] Internet-Draft DNS HTTPSSR RR April 2007 1. Introduction 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]. 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. Schechter Expires October 28, 2007 [Page 4] Internet-Draft DNS HTTPSSR RR April 2007 2. Requirements notation 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]. Schechter Expires October 28, 2007 [Page 5] Internet-Draft DNS HTTPSSR RR April 2007 3. Prerequisites HTTPSSR SHOULD be deployed in conjunction with the DNS Security standards, also known as DNSSEC ([RFC4033], [RFC4034], and [RFC4035]). DNSSEC is necessary to protect the record against man- in-the-middle attacks. Schechter Expires October 28, 2007 [Page 6] Internet-Draft DNS HTTPSSR RR April 2007 4. Record format 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 (as defined in [RFC1035]). The 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]: 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]. 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]. 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. Schechter Expires October 28, 2007 [Page 7] Internet-Draft DNS HTTPSSR RR April 2007 4.1. The Version Byte 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. 4.2. The ForceHTTPS Character 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". 4.3. CertFingerprint Entries 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. Schechter Expires October 28, 2007 [Page 8] Internet-Draft DNS HTTPSSR RR April 2007 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. Schechter Expires October 28, 2007 [Page 9] Internet-Draft DNS HTTPSSR RR April 2007 5. Textual representation 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 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 Schechter Expires October 28, 2007 [Page 10] Internet-Draft DNS HTTPSSR RR April 2007 6. Client guidelines 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: 1. The site's zone, or one of its ancestor zones on the path to the nearest trust anchor, is unsigned (not DNSSEC compliant) 2. The site's zone is signed, its key has been validated, and signed zone records (e.g. NSEC or NSEC3 records) indicate that the HTTPSSR record is absent 3. The site's zone is signed, its key has been validated, the HTTPSSSR record has been validated, and that record's ForceHTTPS value is set to 'N' or, for clients that do not support HTTPS, to 'S'. 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: o Issuing any HTTP request a method other than GET or HEAD (the Safe methods as defined by [RFC2616]) o Issuing any request that contains form data o Executing any code received in an HTTP response o Presenting any data contained in an HTTP response to the user (If such information is presented, users might take further security- sensitive actions or interpret information as authentic when it may not be.) o Caching any data from an HTTP response in a form that would cause it to be loaded in place of an authenticated response in the future. (It may be cached if it will not be treated as valid unless it is established that HTTP requests were indeed permissible for the site.) 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 Schechter Expires October 28, 2007 [Page 11] Internet-Draft DNS HTTPSSR RR April 2007 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".) Schechter Expires October 28, 2007 [Page 12] Internet-Draft DNS HTTPSSR RR April 2007 7. IANA Considerations 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. Schechter Expires October 28, 2007 [Page 13] Internet-Draft DNS HTTPSSR RR April 2007 8. Security Considerations 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. Schechter Expires October 28, 2007 [Page 14] Internet-Draft DNS HTTPSSR RR April 2007 9. Acknowledgements 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. Schechter Expires October 28, 2007 [Page 15] Internet-Draft DNS HTTPSSR RR April 2007 10. References [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. [IANA] Internet Assigned Numbers Authority, "Well Known Port Numbers". [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2538bis] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", October 2005. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. Schechter Expires October 28, 2007 [Page 16] Internet-Draft DNS HTTPSSR RR April 2007 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)", RFC 4572, July 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [SSL2] Hickman, K., "The SSL Protocol", February 1995. [SSL3] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol Version 3.0", November 1996. Schechter Expires October 28, 2007 [Page 17] Internet-Draft DNS HTTPSSR RR April 2007 Author's Address Stuart E. Schechter MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 US Phone: +1 781 981 2683 Email: stuart@post.harvard.edu Schechter Expires October 28, 2007 [Page 18] Internet-Draft DNS HTTPSSR RR April 2007 Full Copyright Statement Copyright (C) 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Schechter Expires October 28, 2007 [Page 19]