| Network Working Group | M. Pala |
| Internet-Draft | Bloomberg L.P. |
| Intended status: Experimental | April 8, 2016 |
| Expires: October 10, 2016 |
OCSP over DNS (ODIN)
draft-pala-odin-00
With the increase number of protocols and applications that rely on digital certificates to authenticate either the communication channel (TLS) or the data itself (PKIX), the need for providing an efficient revocation system is paramount. Although the Online Certificate Status Protocol (OCSP) allows for efficient lookup of the revocation status of a certificate, the distribution of this information via HTTP or HTTPS is not particularly efficient for high volume websites without incurring in high distribution costs (e.g., CDN).
This draft describes how to provide pre-signed OCSP responses via the DNS system in order to leverage its distributed nature and, therefore lowering operational costs for Certification Authorities.
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."
This Internet-Draft will expire on October 10, 2016.
Copyright (c) 2016 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.
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].
Many current applications use the certificate-based authentication features in Transport Layer Security (TLS) [RFC5246] to allow clients to verify that a connected server properly represents a desired domain name. Typically, in order to verify the revocation status of the certificate an HTTP request is to be performed in order to retrieve either the associated CRL[RFC5280] or an OCSP[RFC6960] response. Especially in high-volume websites, this approach has proven to be cumbersome for all parties involved in the validation process: Certification Authorities, network administrators, and client applications.
To address these issues, this document describes how to leverage the distributed nature of the Domain Name System (DNS) and its caching capabilities to reduce the costs of revocation checking both in terms of network load (client and server side) and resources requirements.
Currently there are three main options to retrieve the revocation information associated with a digital certificates:
All of these methods are based on the ability from the application to extract URLs out of the CRL (CrlDistributionPoint) or of the OCSP responder (AuthorityInfoAccess) from the certificate and query (almost uniquely via HTTP/HTTPS, although supported protocols might include LDAP and FTP) the corresponding server to retrieve the required data.
This document focuses only on the definition of the required options for providing OCSP responses over DNS as an alternative transport protocol. The reliability and accessibility of DNS records (e.g., issues related to TCP vs. UDP DNS responses) are out of the scope of this document.
The OCSP DNS resource record (RR) is used to distribute a certificate's revocation status to clients. The contents of the OCSP RR record is described in Section 3.1
The type value for the OCSP RR type is defined in Section 3.2.
The OCSP RR is class independent.
The OCSP RR Time to Live (TTL) should not exceed the validity period of the OCSP response that is contained in the record.
The RDATA for an OCSP RR consists of a single field which carries the DER encoded OCSP response for the identified certificate.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
+ OCSP Response Data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The OCSP response should contain only one response that refers to the certificate which contains that URL. Following this schema, the OCSP DNS URIs within the AIA extension SHOULD be unique for each certificate issued by a single CA.
This document uses a new DNS RR type, OCSP, whose value (TBD) was allocated by IANA from the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry.
The Authority Information Access extension, as defined in RFC 5280 [RFC5280], provides information about the certificate in which the extension appears. In order to specify the availability of OCSP responses over DNS, Certification Authorities should use a new accessMethod OID id-ad-ocsp-dns. The new access method OID is defined as follows:
id-ad-ocsp-dns OBJECT IDENTIFIER ::= { id-ad 3 }
When the id-ad-ocsp-dns appears as accessMethod, the accessLocation field describes the location of the OCSP response related to the certificate the extension appears is and its syntax should follow the specifications in RFC 4501 [RFC4501] for DNS URIs.
Please note that, when using this accessMethod, the use of the dnsathority in the specified URI is discouraged as this might reduce the benefits coming from the caching infrastructure of DNS and, possibly, overload the referred DNS server.
Although this specification does not mandate for any specific format for the DNS URI the for the issuing CA, some examples are provided with the intent to illustrate, not define, the format.
When the DNS URI refers to the issuing CA's domain, the use of the serialNumber of the certificate plus the hostname the certificate (e.g., for TLS certificates) could provide a good publishing algorithm:
dns:029348950321..323.domain.com?type=OCSPRR
When a CSP could provide separated sub-domains for the different CAs, the use of the serial number of the certificate might provide an easier solution:
dns:32412321532342...32434.domain.cspdomain?type=OCSPRR
Notice that a separate sub-domain for revocation information distribution is not required. Moreover, other DNS domains can be used (e.g., the certificate's owner one) in the extension (although this might require the certificate's owner to publish the OCSP responses in the appropriate DNS entry - similarly as what happens when OCSP stapling is used).
Several security considerations need to be explicitly considered for the system administrators and application developers to understand the weaknesses of the overall architecture.
It is important to highlight, however, that the following considerations are inherently derived from the nature of the DNS infrastructure and that deployment of the DNSSEC protocol might provide an efficient protection against them.
The first consideration is about possible man-in-the-middle attacks (MITMs). In particular, by lacking server authentication, the DNS protocol (both in TCP and UDP mode) is vulnerable to attacks where false responses are provided. Although all the information stored in the OCSP RR is signed, the data returned to the client could potentially be altered (e.g., by providing an empty response). However, it is important to notice that for responses that can be correctly verified (i.e., the OCSP response' signature is confirmed to be valid), the client can be sure that the response has not been faked by an attacker unless the OCSP's responder's private key has been compromised.
As mentioned earlier, the deployment of DNSSEC can help in mitigating the described family of attacks by providing a mean for the client to verify signatures of the DNS records themselves via the DNS keys.
The authors would like to thank everybody who provided insightful comments and helped in the definition of the deployment considerations. This is a reference [RFC5280].
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC4501] | Josefsson, S., "Domain Name System Uniform Resource Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006. |
| [RFC5246] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008. |
| [RFC5280] | Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R. and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008. |
| [RFC6960] | Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013. |
Use the Appendix to convey useful considerations that are not related to the protocol itself. Maybe a transport protocol that can be used together with the described protocol.