Internet Engineering Task Force (IETF) Phillip Hallam-Baker INTERNET-DRAFT Comodo Group Inc. Intended Status: Standards Track April 8, 2015 Expires: October 10, 2015 Title draft-hallambaker-webseccaa-00 Abstract DNS Publication of HTTP Strict Security and Key Pinning Declarations Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hallam-Baker October 10, 2015 [Page 1] Internet-Draft DNS Publication HSTS & HPKP April 2015 Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Record Format and Interpretation . . . . . . . . . . . . . . . 4 4.1. Record Format . . . . . . . . . . . . . . . . . . . . . . 4 4.1.1. HSTS . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1.2. HPKP . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Hallam-Baker October 10, 2015 [Page 2] Internet-Draft DNS Publication HSTS & HPKP April 2015 1. Abstract HTTP Strict Transport Security (HSTS) and Public Key Pinning (HPKP) define security policies that provide Secure After First Use security when published through HTTP over TLS. This specification defines a mechanism allowing HSTS and HPKP assertions to be published using DNS CAA records to support Secure On First Use mechanisms. 2. Definitions 2.1. Requirements Language 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 RFC 2119 [RFC2119]. 3. Introduction HTTP Strict Transport Security (HSTS) [RFC6797] defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS Policy, which is represented by and conveyed via the Strict-Transport- Security HTTP response header field over secure transport (e.g., TLS). While signaling the security configuration of the HTTP server in-band affords considerable deployment advantages, the security policy enforcement is of the ?Secure After First Contact? type. Conveying HSTS policy declarations inband does not and cannot provide security on first contact. One response to this limitation is the use of ?pre-loaded list? registries as described in [RFC6797] section 14.6. Such lists are frequently employed by HTTP clients supporting the HTTP Strict Security mechanism. The Certificate Authority Authorization record (CAA) [RFC6844] provides an extensible mechanism for publishing assertions that relate to the issue and use of PKIX certificates. This document defines CAA tags for HTTP Strict Security (HSTS) and Public Key Pinning (HPKP). Unlike TLSA record specified by DANE [RFC6698], the syntax and intended semantics of a HSTS or HPKP record are identical to the corresponding HTTP headers. This affords considerable convenience in provisioning as all that is necessary is to forward data from the HTTP headers to the DNS service, a task which may be performed with little or no code. Hallam-Baker October 10, 2015 [Page 3] Internet-Draft DNS Publication HSTS & HPKP April 2015 4. Record Format and Interpretation The CAA record is an extensible DNS Resource Record defined for the purpose of making assertions about CA issued PKIX keys in the DNS. Although the intended semantics are identical, the context is not. In particular, a CAA record is presented through the DNS rather than in- band within the TLS protocol. While a CAA record MAY be authenticated by a valid DNSSEC signature, such a signature only establishes that the record is authoritative, it does not provide evidence of the state of the TLS server to which the record refers. The consequences of the difference in semantics are discussed in the security considerations section. 4.1. Record Format The CAA record has four fields: * A flags field, permitting a criticality bit to be set. * A tag length field specifying the length of the following tag value * An attribute tag. Reserved tag values are specified in the IANA "Certification Authority Restriction Properties" registry. * A data block specifying the value. 4.1.1. HSTS To publish a HTTP Strict Security declaration as a CAA record, the following parameters are used: * Flags = 0 * Tag Length = 4 * Tag = 'hsts' * Value = The HTTP Strict Security policy declaration as specified in [RFC6797]. 4.1.2. HPKP To publish a Public Key Pinning declaration as a CAA record, the following parameters are used: * Flags = 0 Hallam-Baker October 10, 2015 [Page 4] Internet-Draft DNS Publication HSTS & HPKP April 2015 * Tag Length = 4 * Tag = 'hpkp' * Value = The Public Key Pinning policy declaration as specified in [I-D.ietf-websec-key-pinning]. 4.2. Interpretation A CAA record with a hsts or hpkp tag is an assertion that HTTPS queries to the specified domain will return the data specified in the Value section as a HTTP Strict-Transport-Security header or Public Key Pinning header. While the semantics of data presented through a CAA record are identical to the presentation of the same record through a HTTP header by a Web server operating on port 443 of the same domain, the context in which the record is presented are different. In particular, DNS records have an explicit expiry time while HTTP transactions do not. 5. Security Considerations HSTS and HPKP are security policy mechanisms that attempt to set a minimum level of security. Providing additional channels through which security policy can be published does not introduce new security vulnerabilities affecting confidentiality or integrity but does create new opportunities for denial of service. In particular, self-inflicted denial of service attacks. As noted previously, CAA records provide an out-of-band mechanism for publication of HSTS and HPKP. Since the records are not presented by the CAA records with the hsts or hpkp tag MUST NOT be cached for longer than the DNS expiry interval. When used to compile pre-loaded lists, hsts and hpkp declarations published by CAA records SHOULD be validated by an attempt to establish a HTTP connection over TLs if possible and verifying that the HTTP headers presented in the response are consistent. If this is not possible (e.g. the Web site is not publicly visible), the list compiler SHOULD re-verify the published CAA records on a regular basis. 6. IANA Considerations On publication, IANA should add the following entries to the "Certification Authority Restriction Properties" registry: Hallam-Baker October 10, 2015 [Page 5] Internet-Draft DNS Publication HSTS & HPKP April 2015 Tag Meaning Reference ----------- -------------------------------------- --------- hsts Strict-Transport-Security [This] hpkp Public-Key-Pins [This] issue Authorization Entry by Domain [RFC6844] 7. Acknowledgements TBS 8. References 8.1. Normative References [RFC6797] Hodges, J.,Jackson, C.,Barth, A., "HTTP Strict Transport Security (HSTS)", RFC 6797, November 2012. [RFC6844] Hallam-Baker, P.,Stradling, R., "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, January 2013. [I-D.ietf-websec-key-pinning] Evans, C,Palmer, C,Sleevi, R, "Public Key Pinning Extension for HTTP", Internet-Draft draft- ietf-websec-key-pinning-21, 5 October 2014. 8.2. Informative References [RFC6698] Hoffman, P.,Schlyter, J., "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. Author's Address Phillip Hallam-Baker Comodo Group Inc. philliph@comodo.com Hallam-Baker October 10, 2015 [Page 6]