Subject: [Trans] Request for feedback

From: Tadahiko Ito <[email-masked]>
Date: Thu, 2 Nov 2017 21:03:38 +0900

Hi
I am Tadahiko Ito.
I wrote my first I-D.
<
https://www.ietf.org/internet-drafts/draft-ito-yet-another-name-redaction-00.txt

Any feedback is welcome.

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

Regards Tadahiko

---

From: Melinda Shore <[email-masked]>
Date: Sat, 4 Nov 2017 12:45:24 -0800

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

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 9 Nov 2017 13:07:07 -0500

> Singapore, please come to the session prepared for a redaction

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