[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fiebig-acme-esecacme) 00

Security Dispatch                                              T. Fiebig
Internet-Draft                                                  TU Delft
Intended status: Informational                               K. Borgolte
Expires: July 15, 2019                              Princeton University
                                                        January 11, 2019


     Extended Security Considerations for the Automatic Certificate
                   Management Environment (ESecACME)
                     draft-fiebig-security-acme-00

Abstract

   Most Public Key Infrastructure X.509 (PKIX) certificates are issued
   via the ACME protocol.  Recently, several attacks against domain
   validation (DV) have been published, including IP-use-after-free and
   (forced) on-path attacks.  These attacks can often be mitigated by
   (selectively) requiring additional challenges, such as DNS
   validation, proof of ownership of a prior certificate, and by being
   more diligent in operating a certificate authority.  This document
   provides a list of currently known attacks and describes mitigations
   and operational procedures to prevent issuing a certificate to an
   unauthorized party.

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 https://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 July 15, 2019.

Copyright Notice

   Copyright (c) 2019 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



Fiebig & Borgolte         Expires July 15, 2019                 [Page 1]


Internet-Draft                  ESecACME                    January 2019


   (https://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  IP and Resource-use-after-free Attacks  . . . . . . . . .   3
       2.1.1.  Detection . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.2.  Defense . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  (Forced)-On-path Attacks  . . . . . . . . . . . . . . . .   4
       2.2.1.  Detection . . . . . . . . . . . . . . . . . . . . . .   5
       2.2.2.  Defense . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  DNS Cache Poisoning Attacks . . . . . . . . . . . . . . .   5
       2.3.1.  Detection . . . . . . . . . . . . . . . . . . . . . .   5
       2.3.2.  Defense . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  DNS Cache Staleness Attacks . . . . . . . . . . . . . . .   6
       2.4.1.  Detection . . . . . . . . . . . . . . . . . . . . . .   6
       2.4.2.  Defense . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Summary of CA Operational Improvements  . . . . . . . . . . .   6
     3.1.  Hardening Against Attacks Without DNS Control . . . . . .   7
     3.2.  Multi-Vantage Point Validation  . . . . . . . . . . . . .   7
     3.3.  BGP Monitoring  . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  DNS Resolver Configuration and Monitoring . . . . . . . .   7
     3.5.  DNSSEC Validation Failure and Lack of DNSSEC  . . . . . .   8
     3.6.  Recent Domain Transfer  . . . . . . . . . . . . . . . . .   8
   4.  Additional Validation Options . . . . . . . . . . . . . . . .   8
     4.1.  Proof of Ownership of a Prior Certificate . . . . . . . .   8
       4.1.1.  Limitations . . . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Today, most Public Key Infrastructure X.509 (PKIX) certificates are
   issued via the ACME protocol.  The automated nature of ACME and its
   heavy use of domain validation (DV) render it susceptible to a
   variety of attacks.  These attacks include IP-use-after-free



Fiebig & Borgolte         Expires July 15, 2019                 [Page 2]


Internet-Draft                  ESecACME                    January 2019


   [CSTRIFE], (forced) on-path attacks [BAMBOO], and attacks on
   protocols used for validation [DVP], like DNS.  In general, these
   attacks can be mitigated by (selectively) requiring additional
   challenges, e.g., validation of DNSSEC signatures, proof of ownership
   of a prior certificate, and by being more diligent when operating a
   certificate authority.

   This document provides a list of known attacks and how they can be
   detected.  It also describes mitigations and operational procedures
   that CAs SHOULD implement to reduce the threat of issuing a
   certificate to an unauthorized party.  This section holds information
   on how these mitigations may impact the usability of CAs using ACME
   to issue certificates.

2.  Attacks

   In this section, we describe practical attacks against DV, how to
   detect them, and which additional verification methods SHOULD be used
   in case of an attack.

2.1.  IP and Resource-use-after-free Attacks

   IP and resource-use-after-free attacks occur if a domain owner points
   a DNS record to a resource, which they later vacate without deleting
   the corresponding DNS record.  The resource, such as in cloud
   scenarios, could then be allocated by another party, thus, allowing
   an attacker to impersonate the owner.

   For example, assuming that the web server for www.example.com is
   hosted on a virtual machine a cloud provider and the AAAA record of
   www.example.com points to the IPv6 address of that virtual machine,
   e.g., 2001:db8:1234:1234::1, and, when the operator terminates the
   virtual machine and frees the resource, they do not remove the DNS
   record.  Then, it leads to a stale or dangling DNS record.  If then
   another user of the cloud provider allocates a virtual machine, and
   receives the same IPv6 address (by luck or through other means), then
   this user could proof ownership of www.example.com to an ACME
   compliant CA.

   These observations also hold for DNS records pointing to legacy IPv4
   resources (A records), email servers in case of email-based ownership
   verification (MX records), HTTP and HTTPS delegations (SRV records),
   and even DNS delegations if DNSSEC is not being used (NS records).
   The attacks' feasibility is further increased by the fact that some
   validation challenges may validate a domain by verify only one
   resource in case of multiple equivalent DNS records.





Fiebig & Borgolte         Expires July 15, 2019                 [Page 3]


Internet-Draft                  ESecACME                    January 2019


2.1.1.  Detection

   These attacks are difficult to detect from the CAs point of view,
   without domain owners taking additional precautions themselves.
   Techniques to detect the attack that CAs SHOULD use depend on the
   cooperation from domain owners.

   Domain owners SHOULD use TLSA records to pin the TLS public key for a
   name, allowing the CA to verify the TLSA record to the key for which
   a certificate is requested.

   A detection technique which does not require prior cooperation by
   domain owners leverages Certificate Transparency (CT) logs to
   identify certificates that were issued for the domain in the past,
   which can then be verified to still exist (thus, proving ownership of
   a previous certificate).  Furthermore, CAA records can be used to
   restrict the number of CT logs that the processing CA needs to
   search.  Additionally, if the processing CA is the only CA allowed to
   issue a certificate restricted through CAA records, then it MAY check
   that the certificate request is made by the same ACME account as
   prior successful certificate issuance requests.

2.1.2.  Defense

   If the TLSA public key and the public key used in making the
   certificate request do not match, then the CA MUST deny the requested
   certificate.  In case of a preexisting certificate or a mismatch in
   the requesting ACME account, the operator MUST use additional
   validation techniques.  If the domain has valid DNSSEC records, then
   a DNS challenge SHOULD be used.  Alternatively, the CA SHOULD use a
   validation method that requires ownership of a previously issued
   certificate's key.  Considering that NS and MX records may also
   suffer from resource-use-after-free attacks, unauthenticated DNS and
   email challenges MUST NOT be used.

   Due to the inherent usability implications of the defense the CA MAY
   mitigate on high-risk resources only, such as known cloud providers
   or for operators with a high customer churn.

2.2.  (Forced)-On-path Attacks

   If an attacker can perform a Monkey-in-the-Middle (MitM) attack by
   controlling part of the network path between the CA and the resource
   used for validation, then they can also impersonate an operator and
   illegitimately obtain a certificate for a domain.  Attackers may
   force this on-path situation, e.g., by using BGP shorter-prefix
   attacks [BAMBOO].




Fiebig & Borgolte         Expires July 15, 2019                 [Page 4]


Internet-Draft                  ESecACME                    January 2019


2.2.1.  Detection

   To detect on-path attacks, a CA SHOULD validate challenges from
   multiple vantage points.  For this purpose, the CA MUST operate a
   geographically and topologically distributed system for verification.
   This system MUST contain at least one validator per IP region
   (AfriNIC, APNIC, ARIN, LACNIC, and RIPE).  A CA monitor SHOULD also
   monitor the BGP prefix from which it the request originated, e.g.,
   via a service similar to https://bgpmon.net [1].  However, note that,
   depending how close the attacker is to the victim on the network
   path, there may no path without malicious activity.  Therefore, it
   generalizes the detection issue to that outlined for resource-use-
   after-free attacks.

2.2.2.  Defense

   The same defenses as for resource-use-after-free attacks apply.  If
   an ongoing attack on a network prefix is detected, the CA MUST NOT
   issue certificates for the affected domains until the attack is over.

2.3.  DNS Cache Poisoning Attacks

   If an attacker is able to poison the DNS cache [CPOIS] of a CA while
   the CA validates a domain, then they may change the target of the DNS
   name to be authenticated.  In turn, it allows the attacker to
   redirect the validation attempt to a host that they control.  DNS
   cache poisoning may be successful regardless of [RFC5452] if the
   attacker can exploit packet fragmentation.  By forcing a small on-
   path maximum transmission unit (MTU) between the CA's DNS resolver
   and a domain's authoritative DNS name server(s) using spoofed ICMP
   messages, an attacker may be able to fragment DNS responses.
   Correspondingly, by selecting the MTU so that fragmentation occurs
   after immediately the headers, an attacker can control the second
   part of a DNS packet, which then reassembles with with header of a
   benign packet.  In an ideal scenario, it allows an attacker to
   overwrite the additional section of DNS responses, which the attacker
   could then use to change the content of an additional section for a
   MX, NS, CNAME, or any other type of record chain to point to a system
   unde the attacker's control.

2.3.1.  Detection

   A CA can identify that this attack takes place by measuring the MTU
   of inbound packets.  If the MTU is exceptionally small, the operator
   MUST assume that the domain is under attack.






Fiebig & Borgolte         Expires July 15, 2019                 [Page 5]


Internet-Draft                  ESecACME                    January 2019


2.3.2.  Defense

   To mitigate DNS cache poisoning attacks, the CA MUST validate DNSSEC,
   as already mandated by the CA browser forum [BFOR] for CAA records.
   If DNSSEC cannot be validated, then the CA's resolvers MUST ignore
   fragmented UDP packets with a UDP payload size of less than 512
   octets.

   The CA MAY require DNSSEC validation to succeed and TLSA records to
   be in place for name servers of domains that require a MTU below 1000
   octets.  The CA MAY also opt to enforce DNS-over-TCP [RFC7766], DNS-
   over-TLS [RFC7858], or DNS-over-HTTPS [RFC8484].

   As the additional section of incoming answers at the end of a DNS
   response is particularly vulnerable to this attack, the CA's
   resolvers MUST NOT use data from the additional section, but resolve
   all names themselves.

2.4.  DNS Cache Staleness Attacks

   An attacker can execute an attack similar to resource-use-after-free
   attacks if a CA's DNS resolver caches a DNS record although the
   benign party may have updated the corresponding record.  Then, the
   CA's resolver might serve the cached record to the validation
   systems.  If the CA's resolver implements draft-ietf-dnsop-serve-
   stale, then an attacker has an even longer window of opportunity.
   This window can even be extended by launching a Denial-of-Service
   (DoS) attack on a domain's authoritative name servers, in which case
   the CA's resolver may serve a stale cached record with an expired TTL
   for up to a week.

2.4.1.  Detection

   For a CA, these attacks are not distinguishable from legitimate
   errors and downtimes.

2.4.2.  Defense

   To prevent DNS cache attacks, the CA's validation system's DNS
   recursor MUST NOT serve cached records, and it MUST NOT implement
   draft-ietf-dnsop-serve-stale.  If an authoritative server is
   unreachable, a certificate MUST NOT be issued.

3.  Summary of CA Operational Improvements

   In this section, we summarize the operational changes and mechanisms
   to reduce the chance of issuing a certificate to an unauthorized
   party.



Fiebig & Borgolte         Expires July 15, 2019                 [Page 6]


Internet-Draft                  ESecACME                    January 2019


3.1.  Hardening Against Attacks Without DNS Control

   If the validation target for a challenge (A/AAAA/NS/MX) is considered
   at-risk or located in a network with a high resource churn, e.g., a
   cloud provider or a residential ISP, then the CA SHOULD require the
   domain for which the certificate is to be issued to be DNSSEC signed,
   as well as a CAA and TLSA record to be present.  If the domain is not
   DNSSEC signed, or there is a mismatch between the TLSA record, then
   the CA SHOULD consider the domain under attack and MUST NOT issue a
   certificate.

   If the CA can identify a certificate has been issued for the same
   name before, it MAY consider requiring a challenge proving ownership
   of the identified certificate, or a DNSSEC signed DNS challenge.

3.2.  Multi-Vantage Point Validation

   A CA SHOULD validate challenges from more than one network vantage
   point.  They should validate from at least three distinct
   geographical and topological locations.  If at least one of the CA's
   validation nodes does not match the results of the other nodes, then
   the CA MUST consider the requested domain to be under attack and MUST
   NOT issue a certificate.

3.3.  BGP Monitoring

   A CA SHOULD monitor the current state of the BGP ecosystem, e.g., by
   using a service similar to https://bgpmon.net [2].  If any network
   prefix for the A, AAAA, MX, or NS records (or intermediate names and
   CNAMEs) is considered to be under a BGP MitM attack, then the CA MUST
   consider the requested domain to be under attack, and MUST NOT issue
   a certificate.

3.4.  DNS Resolver Configuration and Monitoring

   To mitigate DNS fragmentation attacks, a CA's DNS resolvers SHOULD
   ignore fragmented packets with UDP payload below 512 octets.  If a CA
   encounters UDP fragments of less than 1000 octets, it MAY require
   DNSSEC and TLSA records to be presented and validated for the zone
   before issuing a certificate.  The CA's resolvers MUST NOT trust the
   additional section of DNS responses and resolve all names on their
   own.

   To prevent attacks relying on stale DNS records, CAs MUST NOT utilize
   draft-ietf-dnsop-serve-stale on their recursors.  In fact, resolvers
   MUST NOT serve records from their cache to the validation system.  If
   the authoritative DNS servers of a domain are unreachable, then the
   CA MUST NOT issue a certificate.



Fiebig & Borgolte         Expires July 15, 2019                 [Page 7]


Internet-Draft                  ESecACME                    January 2019


3.5.  DNSSEC Validation Failure and Lack of DNSSEC

   If DNSSEC validation for a domain for which a certificate is
   requested fails, the CA MUST consider the domain to be under attack,
   and MUST NOT issue a certificate until DNSSEC validation is
   successful.  Depending on whether the domain is considered at-risk,
   the CA MAY decide to not issue a certificate in the absence of DNSSEC
   or CAA records.

3.6.  Recent Domain Transfer

   If a domain has been transfered within the last 72 hours, a CA MAY
   consider the domain's state of ownership as insufficiently defined.
   It MAY require proof of ownership of a prior certificate, or the zone
   to be DNSSEC signed, and TLSA as well as CAA records to be present
   before issuing a certificate.

4.  Additional Validation Options

4.1.  Proof of Ownership of a Prior Certificate

   If a CA detects an attack, it MAY require the requesting party to
   prove that it has access to the private key for a previously issued
   certificate.  This can be done implicitly by requiring validation
   over HTTPS, using a validating prior certificate, or explicitly by
   using a dedicated challenge.

4.1.1.  Limitations

   This option has several operational challenges.  An domain owner's
   infrastructure may not be design in a way that preserves prior
   private keys, for example in large container setups.  Similarly, the
   prior key might have been lost due to data loss.  Additionally, prior
   certificates may have expired.

   An attacker may have also obtained a prior private key by
   compromising a system, or by having had legitimate authority over the
   domain before.

5.  IANA Considerations

   There are no IANA considerations.

6.  Security Considerations

   This document itself serves as a summary of additional security
   considerations.  CA operators should carefully follow the




Fiebig & Borgolte         Expires July 15, 2019                 [Page 8]


Internet-Draft                  ESecACME                    January 2019


   recommendations made in this document to prevent issuing certificates
   to unauthorized parties.

7.  Acknowledgements

8.  References

8.1.  Normative References

   [BAMBOO]   Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J., and P.
              Mittal, "Bamboozling Certificate Authorities with BGP",
              August 2018,
              <https://www.usenix.org/conference/usenixsecurity18/
              presentation/birge-lee>.

   [BFOR]     CA/Browser Forum, ., "Baseline Requirements for the
              Issuance and Management of Publicly-Trusted Certificates",
              October 2018, <https://cabforum.org/wp-content/uploads/
              CA-Browser-Forum-BR-1.6.1.pdf>.

   [CPOIS]    IOActive Inc, ., "Black ops 2008: It's the end of the
              cache as we know it", 2008,
              <http://kurser.lobner.dk/dDist/DMK_BO2K8.pdf>.

   [CSTRIFE]  Borgolte, K., Fiebig, T., Hao, S., Kruegel, C., and G.
              Vigna, "Cloud Strife: Mitigating the Security Risks of
              Domain-Validated Certificates", February 2018,
              <http://dx.doi.org/10.14722/ndss.2018.23327>.

   [DVP]      Brandt, M., Dai, T., Klein, A., Schulman, H., and M.
              Waidner, "Domain Validation++ For MitM-Resilient PKI",
              n.d., <https://doi.org/10.1145/3243734.3243790>.

   [RFC5452]  Hubert, A. and R. van Mook, "Measures for Making DNS More
              Resilient against Forged Answers", RFC 5452,
              DOI 10.17487/RFC5452, January 2009,
              <https://www.rfc-editor.org/info/rfc5452>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/info/rfc7766>.

   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "Specification for DNS over Transport
              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.




Fiebig & Borgolte         Expires July 15, 2019                 [Page 9]


Internet-Draft                  ESecACME                    January 2019


   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <https://www.rfc-editor.org/info/rfc8484>.

8.2.  URIs

   [1] https://bgpmon.net

   [2] https://bgpmon.net

Authors' Addresses

   Tobias Fiebig
   TU Delft

   Email: t.fiebig@tudelft.nl


   Kevin Borgolte
   Princeton University

   Email: kevin@iseclab.org





























Fiebig & Borgolte         Expires July 15, 2019                [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/