On Sat, Nov 4, 2017 at 4:45 PM, Melinda Shore <[email protected]> wrote:
> On 11/2/17 4:03 AM, Tadahiko Ito wrote: > > draft-strad-trans-redaction-01 is discussing about end-user security and > > raise 3 mechanism for name redaction. > > On the other hand, I would like to discuss need for “use of technically > > constrained intermediate” with aspects of security and scaleability > > (especially use of technically constrained intermediate with IoT > devices). > > Hi, all: > > I'll be getting an agenda out this weekend but note that > we'll be allocating time on the agenda at IETF 100 for > a redaction discussion, based on > https://www.ietf.org/internet-drafts/draft-ito-yet-another- > name-redaction-00.txt. > > We'd like to get the redaction question resolved (the trans working > group will/will not be working on this), so please give the draft > a read and post comments to the mailing list. If you'll be in > Singapore, please come to the session prepared for a redaction > discussion. > > Many thanks, > > Melinda > [Document Review] As noted in and throughout the document, the majority of the document is borrowed from https://datatracker.ietf.org/doc/draft-strad-trans-redaction/ , particularly around the discussion of the technical means and methods. Perhaps easiest to view is the diff here - https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-strad-trans-redaction-01.txt&url2=https://www.ietf.org/id/draft-ito-yet-another-name-redaction-00.txt The main differences, in reviewing this document, appear to be: - The difference in discussion about use cases - The removal of security and privacy considerations draft-strad-trans-redaction-01 attempted to pose the space as one of privacy and compliance. draft-ito-yet-another-name-redaction-00 attempts to pose the space as one of scalability and security (through obscurity). This position seems consistent with the authors' work within the CA/Browser Forum to discuss the policy-based mechanisms for this, as captured in this thread https://cabforum.org/pipermail/public/2017-November/012458.html , which also establishes and further develops the use cases. Given that this does not introduce any new technical mechanisms to address the policy concerns that resulted in a lack of interest for adoption of the previous draft, it seems that adoption or rejection is best based on the fitness for the use cases established and the interest of those adopting. >From the point of view of log operation, this draft does not seem to meaningfully change how a CT Log Operator behaves - that is, the same API endpoints function. The impact or support for such changes rests upon CAs (during issuance), clients (during the matching of SCTs to the associated certificate), and auditor/monitors (in evaluating the logs contents against certificates). We know that some CAs are supportive, as captured both in past on-list discussions, from deployment of ad-hoc redaction schemes in the wild (as evidenced by the contents of the Deneb Log operated by Symantec - https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=AR2177 ). However, the decision to trust or not trust such CAs and validate such certificates is fundamentally a policy question, and one answered by individual vendors in assessing the security risks of their products. If there are no products interested in consuming such certificates, or trust stores interested in supporting such mechanisms, it seems to suggest that it is not something that will be implemented or have consensus, and thus there may be limited value to standardizing. [Position] Given that this document does not provide any new technical insight to address the policy concerns (raised outside the IETF) with respect to redaction, it does not seem to introduce anything new to the conversation. With respect to the use cases in the Introduction, they are presumably informative rather than normative, but they appear to be "security through obscurity" and "scalability". I don't know if the IETF has guidance on whether "security through obscurity" is a valid case, compared with the previous document's approach from privacy, but at least with respect to scalability, it seems that there are both alternative technical solutions (c.f. STAR) and perhaps incorrect baseline assumptions (see https://mailarchive.ietf.org/arch/msg/trans/a8uErKaGFGZf7kucNFoglwFpskk ) that may offer more viable, less harmful approaches. With respect to its use within the set of CAs and PKI trusted within Chromium-based products, there has been zero interest in adoption of a technical solution in the absence of addressing the policy concerns. These policy concerns were not addressed nor mitigated in sufficient time to inform Chromium's product decisions and implementation regarding CT support, and as such, there are no present or future plans to support redaction within Chromium-based products. The introduction of redaction, which poses great risk, to an ecosystem and product which does not support redaction, as currently implemented, is gated not on the technical means, but providing a holistic means of addressing the policy concerns about redaction's attempts to maximize site operator's wishes against the harms caused to the ecosystem of relying parties and monitors, and the demonstration that providing less transparency is more beneficial to the ecosystem at large. Before considering adopting, it would be useful to know if there are other consumers of CT outside that "Web PKI" use case, how such ecosystems function, and whether or not the maintainers of such PKIs have interest in this case. As it applies to the Web PKI trusted within Chromium, we believe such technical solutions are counter-productive to the goals of Certificate Transparency for that PKI, and that CAs that issue such certificates should be (and have been) treated as actively misissuing certificates and undermining trust and security. Similarly, it seems useful to evaluate whether the introduction of redaction is one which provides an optional, if not widely supported addition to the ecosystem, much like RFC 6170, or whether it would serve as a net-negative to the stability and interoperability of the Certificate Transparency ecosystem, much like altering the preferred name syntax of DNS could allow new powerful features, but also undermine interoperability, stability, and security.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
