[cabfpub] New RFC on CT Domain Label Redaction

[Ryan Sleevi]

On Fri, Nov 3, 2017 at 7:23 PM, Kirk Hall via Public <public at cabforum.org>
wrote:

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

Enterprises already have this capability via enterprise policies, which do
not require the installation of a specific root CA.

In your gap analysis, it seems this was overlooked, and therefore, may
obviate both the need and arguments for redaction.


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

This is, of course, the same as if CAs issued SHA-1 certificates to satisfy
enterprise needs (as some do, via private roots).

That is, the argument presented here is neither new nor unique, and is
questionable as to whether it is in good faith, given that.


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

The conclusion you draw is not supported by the arguments made.


> 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
>

Respectfully, the argument you made argues for the exact opposite
conclusion of your findings.

As we saw with the SHA-1 deprecation, the use of publicly trusted
certificates within niche cases - whether payment terminals or IOT -
directly harmed Web Security, as for years, CAs argued they could not stop
issuing SHA-1 certs due to the need to support legacy devices and niche
cases.

Things absolutely, unquestionably should be going to private roots - and
efforts that attempt to overlay the Web PKI of modern, routinely updated,
security patched devices with that of the special and unique needs of
things are actively detrimental to the security and stability of the
ecosystem. As shown by SHA-1, as shown by the 1024-bit deprecation, as
shown by discussions about certificate lifetimes.

As this is being made as a significant argument in favor of it, it seems
like it's fundamentally flawed.


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

Any argument about security through obscurity, as is being made here, is
rightfully deserving of ridicule and skepticism. The lack of robustness
around the security controls of such devices that presents disclosure as a
risk - disclosure which, incidentally, can be obtained via many extant
means - highlights the degree of concern that should be made toward such
arguments.


> (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.
>
This is a rather speculative argument that fails to analyze or accept the
profound security risk of public trust. It also suggests that redaction
represents the best technical solution, prior to such discussions as to
whether or not public trust is desirable or, from a security perspective,
acceptable (it is neither). As such, this is not a compelling argument.

(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.
>
DOS attacks are possible by all devices, and an orthogonal concern. More
importantly, however, the "low-resource IoT devices" is the same argument
CAs have used with respect to why they cannot update signature algorithms
("SHA-2 is too expensive") or key sizes. I find it incredibly disingenous
to see some CAs still advancing those arguments, knowing that they have
routinely used them to oppose improvements to security.


> (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.
>
Are you suggesting the DNS name is disclosing the geolocation? Could it be
that an alternative method (without the substantial cost and risk to the
ecosystem) is merely to not do so within the domain name.

(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.
>
This again presupposes that publicly trusted certificates is in the best
interest of security or the ecosystem, and as such, it is not.


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

Please note that a substantially larger set of issues were highlighted.

More importantly, it is incumbent on those supporters to show they can
fully address such efforts. While the CA/Browser Forum may discuss any such
matter, I want to emphasize that if the discussions fail to demonstrate
that they address the fundamental and substantial concerns raised, there is
no reason to presume user agents will adopt any support for redaction. This
is natural, as user agents are acting on behalf of their users, and must
consider the collective ecosystem risks, while CAs may be only focused on
their specific business cases, and not the overall harm caused by such
proposals or support - again, much like SHA-1 issuance, much like RSA
1024-bit issuance, and practically speaking, much like domain validation.

Thus, I would encourage you, if you intend for such efforts to be
successful and productive and result in a change in support for redaction,
it is not merely sufficient to "change the BRs" - but to satisfactorily
demonstrate that it is possible to address the set of overall ecosystem
concerns, and that it has been meaningfully done. Thus, before changing the
BRs, and after you believe you have created a viable solution that
meaningfully addresses the problem (and, on purely a technical level, the
draft fails to do so), circulate that for review.

I will note that any solution that requires trust in a CA's good behaviour
is, unfortunately, unacceptable. As Certificate Transparency has
demonstrated, such trust is fundamentally misplaced.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171104/490b9e15/attachment-0003.html>