[cabfpub] New RFC on CT Domain Label Redaction

Mon Nov 13 14:22:01 UTC 2017

I can understand the sentiment, but in the spirit of ensuring we install
screws with screwdrivers and nails with hammers, rather than the other way
around, it's worth noting that alternative methods of providing that degree
of transparency exist, and in a way that can preserve much more of the
privacy properties.

You can see this at
https://security.googleblog.com/2017/01/security-through-transparency.html
based on the CONIKS work from Princeton ( https://coniks.cs.princeton.edu/ )

On Mon, Nov 13, 2017 at 12:35 AM, Dimitris Zacharopoulos via Public <
public at cabforum.org> wrote:

> Even though it is currently out of scope in the current form of the CA/B
> Forum, IMO it would be very beneficial to use CT Logs to include
> pre-Certificates used for digital signatures and S/MIME. These Certificates
> include Personally Identifiable Information and e-mail addresses that could
> be collected by spammers so redaction would be something useful to have.
>
> I understand that currently there is no application to enforce this but
> having a technical provision might drive a product to implement support for
> SCTs in client Certificates.
>
>
> Dimitris.
>
>
> On 13/11/2017 5:49 πμ, Eric Mill via Public wrote:
>
> To note for the record: when a group of affiliated with the U.S. Federal
> PKI attended CA/Browser Forum F2F 39 in Redmond, on behalf of the General
> Services Administration and the Department of Defense, I announced that
> were beginning a new project to create a publicly trusted root, and that we
> planned to submit all issued certificates to Certificate Transparency logs.
>
> As part of that, I also represented GSA and DoD's consensus that we were
> not requesting support for CT redaction in order to meet that pledge. We
> were, and are, comfortable with a CT requirement that does not include
> support for redaction.
>
> To speak just for myself, but based on my work experience at improving the
> security of federal government systems, the effect of implementing support
> for redaction in the CT ecosystem would be to reduce security, and I
> strongly recommend that CAs drop any efforts to push for support of it.
>
> There are at least 3 ways that redaction would reduce internet security if
> implemented in CT:
>
> * Increasing the complexity and bug surface of SCT-consuming clients (such
> as browsers and monitors) and SCT-producing systems (such as CAs).
>
> * Loss of visibility and accountability in the Web PKI by reducing the
> value of CT logs to the ecosystem. This is combined with the likelihood of
> "over-redaction", where enterprises choose to redact certificates by
> default out of misplaced security concerns.
>
> * What Chrome and others have already pointed out -- there are a variety
> of situations in which domain owners may lose visibility what certificates
> are authorized for their own hostnames, either through domain transfers or
> acquisitions, or through governance issues in sufficiently large
> enterprises.
>
> While I'm sure CAs are accurately representing the concerns of some of
> their customers, the customers are not always right. Relying on the
> obscurity of hostnames as a security boundary is not only ineffective, but
> dangerous. And in the case of the Web PKI, where security is shared and
> where the actions of individual CAs can sometimes imperil the security of
> organizations who have no relationship to those CAs, ecosystem
> accountability is a paramount concern.
>
> -- Eric
>
> On Fri, Nov 3, 2017 at 7:23 PM, Kirk Hall via Public <public at cabforum.org>
> wrote:
>
>> 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-coul
>> d-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/vsT
>> zv8oNcws/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
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>
>
> --
> Eric Mill
> Senior Advisor, Technology Transformation Services, GSA
> eric.mill at gsa.gov, +1-617-314-0966 <%28617%29%20314-0966>
>
>
> _______________________________________________
> Public mailing listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171113/a56a5ff8/attachment-0003.html>