TOC 
Network Working GroupS. Schechter
Internet-DraftMIT Lincoln Laboratory
Intended status: Standards TrackApril 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 © The IETF Trust (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.



Table of Contents

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 

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] (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 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).



 TOC 

3.  Prerequisites

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 

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 <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 

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.



 TOC 

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".



 TOC 

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. 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 

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 <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 

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:

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 

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.



 TOC 

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.



 TOC 

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.



 TOC 

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 (TXT, HTML, XML).
[RFC2234] Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 2234, November 1997 (TXT, HTML, XML).
[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 (TXT, HTML, XML).
[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 (TXT, PS, PDF, HTML, XML).
[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.
[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.


 TOC 

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


 TOC 

Full Copyright Statement

Intellectual Property

Acknowledgment