[cabfpub] New RFC on CT Domain Label Redaction

Fri Nov 3 23:23:06 UTC 2017

Entrust, Secom, Comodo, and other CAs will be asking the IETF TRANS Working Group to revive work on a new RFC to complete specifications for CT Domain Label Redaction (called "Redaction" for short in this message).  The new RFC would only cover technical issues and not policy issues.

The RFC for Certificate Transparency, RFC 6962, started to address Redaction, but never completed the work because of policy issues that were raised about "recourse", or how domain owners would be able to obtain information about redacted certificates that were CT logged to determine if they were legitimate or misissued.

This email is to lay out the course we want to follow to complete the technical specs for Redaction in the IETF, and also to address the recourse issues and consider appropriate changes to the Forum's Baseline Requirements in response.

1. New IETF effort on completing Redaction specifications via a new RFC

Tadahiko of Secom and Rob Stradling of Comodo are working on a new I-D draft on Redaction that will be presented to the IETF TRANS Working Group for consideration.  Tadahiko will present the draft at the next IETF meeting in Singapore in mid-November.

Why do we want to complete the Redaction specifications?  Because we believe enterprise users of certificates in particular want to have the option of using publicly-trusted, CT logged certificates behind their firewalls that do not reveal their security topography by revealing all nodes in the FQDN during CT logging.  In most cases, it's not practical to set up and maintain a private root for use behind the firewall and push out the private root to all users, including vendors and contractors, so that is not a viable alternative for many enterprises.

It's been suggested that publicly trusted certs could be issued but not CT logged, but this is also an unacceptable alternative for use with common browser and application software because of the constant browser warnings that would be displayed to users ("not logged, not secure") - at a minimum, this could set up "warning fatigue" among users causing them to ignore more serious warnings, which is bad for security.

It's also been suggested that enterprises should just use wildcard certificates everywhere - but that could push users to using the same wildcard cert key pair on hundreds of servers, which is bad for security.  Likewise, using multiple identical wildcard certs with different key pairs across hundreds or thousands of servers with different FQDNs could be incredibly hard to track and manage.  That leaves redacted, publicly-trusted, CT logged certs as the best security solution for these website owners.

Another reason for completing an RFC for Redaction is the increasing use of certificates in IoT devices.  There are good reasons why "things" that connect to the internet (cars, baby monitors, etc.) will want to use publicly trusted certificates that work in common browsers and applications, but will not want the device identity number hierarchy publicly disclosed on CT logs for security purposes.  While "things" could go to private roots, going that direction could prevent interoperability, and incompatibility with modern browser software could cause IoT device software to rely on custom software that doesn't receive security updates (as browser software does) and lead to the same kind of frozen legacy root stores that can't be updated that we saw during SHA-1 deprecation problems.

We think it's in the security and commercial interests of browsers to encourage IoT devices to use publicly trusted certificates with their software, but device makers might not do so if they can't use Redaction for security purposes.  See also http://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/Senate-IoT-security-bill-could-mandate-IoT-field-certificate-provisioning

Tadahiko has provided even more specific IoT cases where Redaction would be important for security:

(1) Customers may want to use server certificates for surveillance cameras and network attached storage.  The use of those internet-connected devices will increase in the near future.

(2) In addition, in vehicle-to-vehicle communications auto manufacturers are planning to use some form of PKI, and likely will want to externally control some of devices on vehicles in future.

Although currently they're not using RFC 5280 certificates, some devices will likely be externally controllable and will use publicly trusted certs in the future. In that case, they will want name redaction for obvious security purposes.

(3) Other security concerns about IoT devices include the following:

(a) For low-resource IoT devices (cameras, sensors, some car uses, etc.), DOS attacks are possible, and unredacted CT logs may help the DOS attacker.

(b) For some IoT devices (cameras, sensors, etc.), geo-location information is very sensitive.  If the certificate is logged with CT, there must be a mechanism like redaction to anonymize.

(c) Manufacturers using IoT certificates won't want to show the number of devices they have shipped, and redaction may help keep this information private.

For all these reasons, we plan to move forward in the IETF TRANS Working Group on a new domain label Redaction RFC.

Those in the Forum who want to support this effort should contact Tadahiko, Rob, and me this week.

2. Resolving "recourse" policy issues in the Baseline Requirements

The "recourse" issues were best stated by Ryan Sleevi in this April 2016 message: https://groups.google.com/a/chromium.org/d/msg/ct-policy/vsTzv8oNcws/imuC3iloBwAJ
I think all of these scenarios outlined in the email can be addressed by existing Certificate Problem Report requirements under BR 4.9.1 through 4.9.3, but can be improved by adding new provisions something like the following (this is just conceptual text, not a specific BR amendment proposal at this time):

"If a CA uses redaction when CT logging a certificate, the CA SHALL create and implement a process by which a party ("Inquiring Party") who owns or controls a domain ("Subject Domain") and sees a redacted certificate ("Redacted Certificate") for the Subject Domain in a CT log or elsewhere may request additional information about the Redacted Certificate issued to a prior Applicant ("Applicant"), and may also request revocation of the Redacted Certificate if appropriate.  The CA SHALL publicly post an email address, telephone number, and general process ("Inquiry Process") for such requests.   The Inquiry Process SHALL include the following elements:

*       A format that may be used by the Inquiring Party to request information about a Redacted Certificate, including name and contact information by which the CA may contact the Inquiring Party;

*       The manner by which the CA will confirm that the Inquiring Party owns or controls the Subject Domain.  The CA SHOULD offer the Inquiring Party multiple options for verification methods to confirm the Inquiring Party's ownership or control of the Subject Domain;

*       The process the CA will follow once the Inquiring Party has shown ownership or control of the Subject Domain, including how the CA will notify the Applicant about the Inquiring Party's inquiry and what information the CA will provide to the Inquiring Party and the Applicant; and

*       If the Applicant objects to the CA providing information about the Redacted Certificate to the Inquiring Party, or if the Inquiring Party requests revocation of the Redacted Certificate, the general process the CA will follow to adjudicate the dispute among the parties."

Because this process will chiefly be carried out by CAs, we plan to first discuss this in the Forum to get a workable proposal drafted for "recourse" language, and then to post it to the TRANS WG for public comments.  After that, we can consider a specific ballot in the Forum to add appropriate "recourse" provisions to the BRs.

Thanks for your attention to this new project (and this long email).  Please let me know if you want to join in.

Kirk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20171103/be5ecbff/attachment-0001.html>