Internet DRAFT - draft-ito-yet-another-name-redaction
draft-ito-yet-another-name-redaction
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]
