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



TRANS                                                             T. Ito
Internet-Draft                                           R. Ramirez, Ed.
Intended status: Informational                                     SECOM
Expires: September 2, 2018                                 March 1, 2018


                 Use of Name Redaction for Mass Devices
                draft-ito-yet-another-name-redaction-01

Abstract

   This document describes mechanisms to allow CT log submitters not to
   submit plain certificates.  While public Certificate Transparency
   (CT) logs allow anyone to observe server certificates and make
   confident to trust Certificate Authorities (CAs), there are some
   problems scaling to mass devices.  This document describes and
   presents some use cases for a mechanism that retains most of the
   security benefits gained from using Certificate Transparency.

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 September 2, 2018.

Copyright Notice

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



Ito & Ramirez           Expires September 2, 2018               [Page 1]


Internet-Draft       Name Redaction for Mass Devices          March 2018


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Redacted CT submission mechanism  . . . . . . . . . . . . . .   3
   5.  Concerns with each method . . . . . . . . . . . . . . . . . .   4
     5.1.  Use Private Roots (do not use name redaction nor CT)  . .   4
     5.2.  Use Public Roots  . . . . . . . . . . . . . . . . . . . .   4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Many devices communicate with TLS.  These devices include
   surveillance cameras and Network Attached Storage.  Such devices use
   server certificates to communicate with other devices such as smart
   phones.  The number of these TLS-communicating devices is expected to
   grow exponentially.  In contrast, efficiently searchable list of mass
   devices may assist attackers (typically, to construct a botnet).  In
   this document, I describe needs of name redaction mechanisms for
   those devices' certificates.  Their certificates are typically issued
   by an intermediate certificate authority, which is tied to the device
   vendor or service provider.

   On the other hand, there are some organizations who issue
   certificates only for their own domain space (with global IP
   address).  For that case, CA/BForum defines "technical constraints
   intermediate certificate authority", and allows organizations to
   moderate portions of the audit process CA/BForum BR1.5.4 [BR1.5.4],
   according to limitation of influence in case of miss issuance.

   However, Certificate Transparency v1 [RFC6962] and current v2 I-
   D.ietf-trans-rfc6962-bis26 [I-D.ietf-trans-rfc6962-bis] describe
   protocols for publicly logging all TLS server certificates issued by
   publicly trusted CAs.  CT log server also store certificates with
   above uses, and can end up assisting attacker in hijacking massive
   numbers of devices.  In addition, it would increase burden of CT log
   server near future, by exponential increase of mass devices.




Ito & Ramirez           Expires September 2, 2018               [Page 2]


Internet-Draft       Name Redaction for Mass Devices          March 2018


   I-D.draft-strad-trans-redaction-01
   [I-D.draft-strad-trans-redaction-01] focused on end-entity's privacy
   with name redaction.  This document focuses on other aspects, such as
   avoiding lack of scalability, or prohibiting use on large scale
   Botnet.  The purpose of this document is to reinforce discussion of
   I-D.draft-strad-trans-redaction-01
   [I-D.draft-strad-trans-redaction-01].

2.  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.  Terminology

   This document relies on terminology and data structures defined in
   [RFC-6962-BIS-26], including STH, SCT.

   The term "name redaction" refers to any kind of CT mechanism, which
   allow submitter not to log (possibly potion of) end-entity
   certificate.

   The term "domain-label name redaction" refers any to kind of name
   redaction mechanism, which allow submitter not log domain name.
   Domain-label name redaction is subset of name redaction.

   The term "OTA update" refers to over the air update of devices.

   The term "crypt agility" refers to the ability for a protocol to
   easily change the cryptographic algorithms it uses over time.

4.  Redacted CT submission mechanism

   The technical description of this section refers to I-D.draft-strad-
   trans-redaction-01 [I-D.draft-strad-trans-redaction-01].

   This section briefly describes the device scalability and security
   for three name redaction mechanisms, in order of increasing
   implementation complexity:

   o  Using wildcard certificates is the simplest option, but it is not
      suitable for use with massive numbers of devices.  Devices with a
      common wildcard certificate would need to share a private key,
      which would dramatically increase risk of key leakage.

   o  Logging a name-constrained intermediate CA certificate in place of
      the end-entity certificate, and is suitable for mass devices, as



Ito & Ramirez           Expires September 2, 2018               [Page 3]


Internet-Draft       Name Redaction for Mass Devices          March 2018


      it improves the scalability of the log server.  However, it
      requires some non-scalable operations on the part of the CA (i.e.
      issuing new intermediate certificate.).

   o  Domain-label name redaction mechanism reduces the burden put on
      the CA.  In addition, it allows CAs to operate mass devices more
      flexibly.  Furthermore, geographic information is very useful for
      mass device management, and service providers may want or try to
      use that information with certificates.  However, this information
      might be useful for attacker also.  By hiding this information for
      attacker, this mechanism prevents large-scale physical attacks on
      devices.  However, this option increases the implementation
      complexity considerably.

5.  Concerns with each method

   When an IoT service provider uses server certificates, the service
   provider will choose one of following.  In this section, we describe
   positive and negative points for each methods (including methods,
   which does not use name redaction).

5.1.  Use Private Roots (do not use name redaction nor CT)

   Pro: Do not need any change with current mechanisms.

   Con: Service providers need to construct a new trust store.  As the
   number of IoT services increases, it will become hard to manage the
   trust store, both for service providers and end users. ("scalability
   of trust store" issue)

   While private roots could be used, it could prevent interoperability,
   and incompatibility with modern browser software could force IoT
   device software to rely on custom software that likely would not
   receive security updates (as browser software does) leading to the
   same kind of problem of "frozen" legacy root stores that can't be
   updated that we saw during SHA-1 deprecation problems.

5.2.  Use Public Roots

   Since a mississued certificate for an IoT device would affect
   security of the Web, Service provider would have to maintain an OTA
   update mechanism for IoT devices to maintain security and crypt
   agility.  Some of the methods below may provide incentives for
   service providers to use such devices.

   o  Do not use name redaction.

      *  Log all end-entity certificates :



Ito & Ramirez           Expires September 2, 2018               [Page 4]


Internet-Draft       Name Redaction for Mass Devices          March 2018


            Pro: Compatible with current mechanism.

            Con: log server needs to deal with enormous log
            ("scalability of log server" issue).  IoT devices (cameras,
            sensors, etc.), can be proxies for DOS attacks.  Unredacted
            CT logs may help an DOS attacker to construct a botnet for
            DOS attack.  Logging Reveals Commercially Sensitive
            Information also.  Manufacturers using IoT certificates
            possibly won't want to show the number of devices they have
            shipped; redaction may help keep this information private.
            Competitors scanning CT logs could infer new product/service
            offerings prior to their public release.

      *  Disabling CT log checking with browser policy :

            Pro: Compatible with current CT Log server.

            Con: Browser needs to implement mechanism, and list of
            intermediate CAs not to check.

   o  Use name redaction

      *  With wild card Certificate :

            Pro : Near-compatible with current CT mechanism.

            Con : Secret keys could be leaked from IoT devices.

      *  With name-constrained intermediate CA :

            Pro: Near-compatible with current log server's
            implementation.

            Con: Browser needs to support name-constrained intermediate.
            CA need to implement name-constrained intermediate.

      *  domain-label name redaction : If "attacker can construct *list*
         of devices very *efficiently*", that list can assist attacker
         (typically, construction of botnet).  This mechanism limits the
         efficiency of construction, instead of preventing the
         construction of a list.

6.  IANA Considerations

   TBD






Ito & Ramirez           Expires September 2, 2018               [Page 5]


Internet-Draft       Name Redaction for Mass Devices          March 2018


7.  Security Considerations

   TODO: describe how CA can get assurance for domain owner's control
   over underling domain.  It should contain some management mechanism,
   and need further discuss.

8.  Acknowledgements

   Portions of this text were unabashedly borrowed from I-D.draft-strad-
   trans-redaction-01 [I-D.draft-strad-trans-redaction-01].

9.  References

9.1.  Normative References

   [I-D.draft-strad-trans-redaction-01]
              Stradling, R. and E. Messeri, "Certificate Transparency:
              Domain Label Redaction", draft-strad-trans-redaction-01
              (work in progress), January 2017.

   [I-D.ietf-trans-rfc6962-bis]
              Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
              Stradling, "Certificate Transparency Version 2.0", draft-
              ietf-trans-rfc6962-bis-24 (work in progress), December
              2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.

   [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,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <http://www.rfc-editor.org/info/rfc6125>.




Ito & Ramirez           Expires September 2, 2018               [Page 6]


Internet-Draft       Name Redaction for Mass Devices          March 2018


   [RFC6962]  Laurie, B., Langley, A., and E. Kasper, "Certificate
              Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
              <http://www.rfc-editor.org/info/rfc6962>.

9.2.  Informative References

   [BR1.5.4]  CA/Browser Forum, "Baseline Requirements for theIssuance
              and Management of Publicly-Trusted Certificates", 2017,
              <https://cabforum.org/wp-content/uploads/
              CA-Browser-Forum-BR-1.5.4.pdf>.

Authors' Addresses

   Tadahiko Ito
   SECOM
   Mitaka, Tokyo
   Japan

   Phone: +81 422 76 2111
   Email: tadahi-ito@secom.co.jp


   Robert Ramirez (editor)
   SECOM
   Mitaka, Tokyo
   Japan

   Phone: +81 422 76 2111
   Email: ro-ramiresu@secom.co.jp






















Ito & Ramirez           Expires September 2, 2018               [Page 7]


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