idnits 2.17.1 draft-pala-odin-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2017) is 2353 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC4501' is defined on line 339, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Pala 3 Internet-Draft CableLabs 4 Intended status: Experimental November 13, 2017 5 Expires: May 17, 2018 7 OCSP over DNS (ODIN) 8 draft-pala-odin-03 10 Abstract 12 With the increase number of protocols and applications that rely on 13 digital certificates to authenticate either the communication channel 14 (TLS) or the data itself (PKIX), the need for providing an efficient 15 revocation system is paramount. Although the Online Certificate 16 Status Protocol (OCSP) allows for efficient lookup of the revocation 17 status of a certificate, the distribution of this information via 18 HTTP (or very rarely) HTTPS is not particularly efficient for high 19 volume websites without incurring in high distribution costs (e.g., 20 CDN). 22 In particular, this specification defines how to distribute OCSP 23 responses over DNS and how to define OCSP-over-DNS URLs in 24 certificates. The use of the DNS system to distribute such 25 information is meant to lower the costs of providing revocation 26 services (by leveraging the distributed nature of DNS cache) and 27 increase the availability of revocation information (by providing an 28 additional access method for revocation information retrieval). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 17, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 65 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 3. Overview of existing solutions . . . . . . . . . . . . . . . 3 67 4. Scope Statement . . . . . . . . . . . . . . . . . . . . . . . 3 68 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 69 6. The OCSP Resource Record (OCSPRR) . . . . . . . . . . . . . . 4 70 6.1. The OCSP RDATA Wire Format . . . . . . . . . . . . . . . 4 71 6.2. The OCSP RRType . . . . . . . . . . . . . . . . . . . . . 4 72 6.3. Time Validity . . . . . . . . . . . . . . . . . . . . . . 5 73 7. Specifying DNS URLs for OCSP RR . . . . . . . . . . . . . . . 5 74 7.1. URL definition . . . . . . . . . . . . . . . . . . . . . 5 75 7.2. DNS URL Processing . . . . . . . . . . . . . . . . . . . 6 76 7.3. OCSPRR URI Examples . . . . . . . . . . . . . . . . . . . 6 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 80 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 83 1. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 With the increasing number of highly available and highly utilized 92 websites that require secure communications to protect the flow of 93 information from the server to the client and the raising number of 94 devices (IoT) that require strong authentication capabilities, the 95 need for a low-cost efficient approach to revocation information 96 availability is crucial. The OCSP-over-DNS approach allows clients 97 to determine the revocation status of digital certificates by 98 optimizing the delivery mechanism for revocation information 99 distribution to the client. This transport protocol can be used in 100 lieu of or in addition to other PKIX endorsed transport mechanisms 101 such as HTTP. This specification addresses the problem of providing 102 a highly-available distributed system for OCSP responses [RFC6960]. 104 This document defines the DNS records to be used for OCSP data 105 publication and the definition of additional URLs for the 106 AuthorityInfoAccess (AIA) extension in certificates. 108 3. Overview of existing solutions 110 Currently there are three main options to retrieve the revocation 111 information associated with a digital certificates: 113 o by retrieving the freshest CRL 115 o by querying an OCSP responder for a freshly computed response 117 o by retrieving a pre-signed OCSP response from a web site 118 (typically a content distribution network or CDN) 120 o by verifying pre-computed OCSP responses embedded (stapled) during 121 the TLS negotiation (only in the TLS case, though) 123 All of these methods are based on the ability from the application to 124 extract URLs out of the CRL (CrlDistributionPoint) or of the OCSP 125 responder (AuthorityInfoAccess) from the certificate and query 126 (almost uniquely via HTTP/HTTPS, although supported protocols might 127 include LDAP and FTP) the corresponding server to retrieve the 128 required data. 130 4. Scope Statement 132 This document focuses only on the definition of the required options 133 for providing OCSP responses over DNS as an alternative transport 134 protocol. The reliability and accessibility of DNS records (e.g., 135 issues related to TCP vs. UDP DNS responses) are out of the scope of 136 this document. 138 5. Protocol Overview 140 In order to validate a certificate using OCSP-over-DNS, the client 141 should check the certificate for a DNS-based OCSP URI ("dns://") and 142 then retrieve the OCSP response from the DNS. After this point, all 143 procedures are to be performed according to the OCSP protocol as 144 defined in [RFC5019]. In particular, clients using OCSP-over-DNS, 145 SHOULD: 147 1. Lookup the OCSP URI provided in the AIA of the certificate to be 148 checked. The format of the URI comprises the id-ad-ocsp 149 identifier and a base URL where the scheme (``dns://'') is used. 150 The format of the full URI is discussed in Section 7. 152 2. Retrieve the DNS record carrying the required OCSP response. 154 6. The OCSP Resource Record (OCSPRR) 156 The OCSP DNS resource record (RR) is used to distribute a 157 certificate's revocation status to clients. The contents of the OCSP 158 RR record are described in Section 6.1. 160 The type value for the OCSP RR type is defined in Section 6.2. 162 The OCSP RR is class independent. 164 The OCSP RR Time to Live (TTL) should not exceed the validity period 165 of the OCSP response that is contained in the record. 167 6.1. The OCSP RDATA Wire Format 169 The RDATA for an OCSP RR consists of a single field which carries the 170 DER encoded OCSP response for the identified certificate. 172 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | / 176 + OCSP Response Data / 177 / / 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 The OCSP response should contain only one response that refers to the 181 certificate which contains that URL. Following this schema, the OCSP 182 DNS URIs within the AIA extension SHOULD be unique for each 183 certificate issued by a single CA. 185 6.2. The OCSP RRType 187 This document uses a new DNS RR type, OCSP, whose value (TBD) was 188 allocated by IANA from the Resource Record (RR) TYPEs subregistry of 189 the Domain Name System (DNS) Parameters registry. 191 6.3. Time Validity 193 The time validity should reflect the frequency of updates in 194 revocation information (i.e., the TTL should not be set to expire 195 after the OCSP response expiration). In practice, as an operational 196 matter, operators SHOULD ensure that the records are published in a 197 way that the TTL is low enough that they expire from caches before 198 the OCSP response expiration. 200 7. Specifying DNS URLs for OCSP RR 202 The Authority Information Access extension, as defined in [RFC5280], 203 provides information about the certificate in which the extension 204 appears. In order to specify the availability of OCSP responses over 205 DNS, Certification Authorities should use the OCSP accessMethod OID 206 (id-ad-ocsp) and use "dns" as the transport. 208 Please note that, when using this accessMethod, the use of the 209 dnsathority in the specified URI is discouraged as this might reduce 210 the benefits coming from the caching infrastructure of DNS and, 211 possibly, overload the referred DNS server. 213 7.1. URL definition 215 A DNS URL [RFC3986] begins with the protocol prefix "dns" and is 216 defined by the following grammar, following the ABNF notation defined 217 in [RFC5234]. 219 dnsurl = scheme COLON SLASH SLASH [target] 220 [QUESTION [ TYPE=rr_type ] 221 ; target: is the dns entry for 222 ; the lookup operation. 223 ; rr_type: is the type of record 224 ; to be retrieved. If not specified, 225 ; the default type is OCSPRR 227 scheme = "dns" 229 SLASH = %x2F ; forward slash ("/") 230 COLON = %x3A ; colon (":") 231 QUESTION = %x3F ; question mark ("?") 232 TYPE = "type" ; the keyword ("type") 234 Although this specification does not mandate for any specific format 235 for the component of the DNS URL, some examples are provided 236 in Section 7.3 with the intent to illustrate, not define, the format. 238 7.2. DNS URL Processing 240 In order to process the OCSP DNS URLs in a certificate, clients have 241 to extract the and, if provided, the of record from 242 the URL. After that, client MUST query for the specified record. 243 When the ``OCSPRR'' record type is used, the returned value MUST 244 contain the DER encoded OCSP response related to the certificate that 245 the client is going to validate. 247 7.3. OCSPRR URI Examples 249 When using the issuing CA's DNS sub-domain in the DNS URL, the hex 250 (or decimal) representation of the certificate's serialNumber MAY be 251 used as the hostname of the DNS URL. When combined with the specific 252 sub-domain of the issuing CA this provides a unique entry that can be 253 easily queried. For example, given that the sub-domain of the 254 issuing CA is "ca1.example.com", the resulting URL in the issued 255 certificate can be constructed as follows: 257 dns://04A3E45534A1B5.ca1.example.com?type=OCSPRR 259 Because the serialNumber of a certificate is guaranteed to be unique 260 within a (single) CA, different Certification Authorities MUST use 261 different sub-domains when using this publication algorithm to avoid 262 collisions across different CAs. 264 However, in some environments, the serial number that will be used in 265 the certificate to be issued can not be pre-fetched and embedded in 266 the AIA's DNS URL entry. In this case, the use of a monotonically 267 increasing or random integer number can be used instead. 269 In any case, it is important to notice that since the DNS entry is to 270 be used "AS IS" by the relying party that wants to fetch the OCSP 271 response by using the DNS URL, other techniques (e.g., the use of 272 prefixes for different issuing CAs combined with high-resolution 273 clock entries and small random or monotonic integer suffixes) can be 274 implemented independently by different Certificate Service Providers. 276 8. IANA Considerations 278 This document uses a new DNS RR type, OCSPRR, whose value (TBD) MUST 279 be allocated by IANA from the Resource Record (RR) TYPEs subregistry 280 of the Domain Name System (DNS) Parameters registry. 282 9. Security Considerations 284 Several security considerations need to be explicitly considered for 285 the system administrators and application developers to understand 286 the weaknesses of the overall architecture. It is important to 287 highlight, however, that the following considerations are inherently 288 derived from the nature of the DNS infrastructure and that deployment 289 of the DNSSEC protocol might provide an efficient protection against 290 them. 292 By lacking the ability to authenticate the originating server 293 directly, the DNS (not DNSSEC) protocol (both in TCP and UDP mode) is 294 vulnerable to attacks where false responses are provided. Although 295 all the information stored in the OCSP RR is signed, the data 296 returned to the client could potentially be altered (e.g., by 297 providing an empty or old response). This type of attack can lead to 298 the application's inability to retrieve the revocation information, 299 thus this approach is vulnerable to Denial of Service (DoS), Man-in- 300 the-middle (MITM), and Reply Attacks. 302 As mentioned earlier, the deployment of DNSSEC can help in mitigating 303 the described family of attacks by providing a mean for the client 304 (or its resolver) to verify signatures of the DNS records themselves 305 via the DNS keys. This said, the use of DNS (instead of DNSSEC) is 306 equivalent, from a security considerations point of view, to today's 307 deployment best practices for OCSP where pre-computed responses are 308 delivered by CDNs via HTTP (not HTTPS). Therefore, the provisioning 309 of OCSP responses via DNS does not lower or alter the security 310 considerations that apply to the use of OCSP. Last but not least, 311 because of the availability (in most cases) of independent DNS 312 servers that an application can query, the use of multiple requests 313 to different DNS servers (for the same DNS record) might be 314 implemented as a mitigating measure in case an attack is suspected or 315 detected. 317 10. Acknowledgments 319 The authors would like to thank everybody who provided insightful 320 comments and helped in the definition of the deployment 321 considerations. In particular, the authors would like to thank Scott 322 A. Rea for his support. We also would like to thank DigiCert and 323 the initial discussion and support for the initial idea. Last but 324 not least, the authors would like to thank all the people that 325 expressed interest in implementing support for this proposal. 327 11. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 335 Resource Identifier (URI): Generic Syntax", STD 66, 336 RFC 3986, DOI 10.17487/RFC3986, January 2005, 337 . 339 [RFC4501] Josefsson, S., "Domain Name System Uniform Resource 340 Identifiers", RFC 4501, DOI 10.17487/RFC4501, May 2006, 341 . 343 [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online 344 Certificate Status Protocol (OCSP) Profile for High-Volume 345 Environments", RFC 5019, DOI 10.17487/RFC5019, September 346 2007, . 348 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 349 Specifications: ABNF", STD 68, RFC 5234, 350 DOI 10.17487/RFC5234, January 2008, 351 . 353 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 354 Housley, R., and W. Polk, "Internet X.509 Public Key 355 Infrastructure Certificate and Certificate Revocation List 356 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 357 . 359 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 360 Galperin, S., and C. Adams, "X.509 Internet Public Key 361 Infrastructure Online Certificate Status Protocol - OCSP", 362 RFC 6960, DOI 10.17487/RFC6960, June 2013, 363 . 365 Author's Address 367 Massimiliano Pala 368 CableLabs 369 858 Coal Creek Cir 370 Louisville, CO 80027 371 US 373 Email: m.pala@cablelabs.com 374 URI: http://www.linkedin.com/in/mpala