Internet DRAFT - draft-hallambaker-webseccaa

draft-hallambaker-webseccaa



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]