<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 7:23 PM, Kirk Hall via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-6705015555956669549WordSection1">
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal"><br></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
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. </p></div></div></blockquote><div><br></div><div>Enterprises already have this capability via enterprise policies, which do not require the installation of a specific root CA.</div><div><br></div><div>In your gap analysis, it seems this was overlooked, and therefore, may obviate both the need and arguments for redaction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
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.</p></div></div></blockquote><div><br></div><div>This is, of course, the same as if CAs issued SHA-1 certificates to satisfy enterprise needs (as some do, via private roots).</div><div><br></div><div>That is, the argument presented here is neither new nor unique, and is questionable as to whether it is in good faith, given that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
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.</p></div></div></blockquote><div><br></div><div>The conclusion you draw is not supported by the arguments made.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
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.  </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1"><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal"> <u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
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
<a href="http://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/Senate-IoT-security-bill-could-mandate-IoT-field-certificate-provisioning" target="_blank">
http://internetofthingsagenda.<wbr>techtarget.com/blog/IoT-<wbr>Agenda/Senate-IoT-security-<wbr>bill-could-mandate-IoT-field-<wbr>certificate-provisioning</a></p></div></div></blockquote><div><br></div><div>Respectfully, the argument you made argues for the exact opposite conclusion of your findings.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As this is being made as a significant argument in favor of it, it seems like it's fundamentally flawed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
Tadahiko has provided even more specific IoT cases where Redaction would be important for security:<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<u></u> <u></u></p>
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.25in">(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.</p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.25in">(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. 
<u></u><u></u></p>
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.25in">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.</p></div></div></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.25in">(3) Other security concerns about IoT devices include the following:<u></u><u></u></p>
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.25in"><u></u> <u></u></p>
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.5in">(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.</p></div></div></blockquote><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.5in">(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.</p></div></div></blockquote><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="m_-6705015555956669549MsoPlainText" style="margin-left:.5in">(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.</p></div></div></blockquote><div>This again presupposes that publicly trusted certificates is in the best interest of security or the ecosystem, and as such, it is not.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-6705015555956669549WordSection1">
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
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.<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
<u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">
Thanks for your attention to this new project (and this long email).  Please let me know if you want to join in.</p></div></div></blockquote><div><br></div><div>Please note that a substantially larger set of issues were highlighted.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div></div></div></div>