Subject: [Trans] Call for adoption: draft-strad-trans-redaction-00

From: Melinda Shore <[email-masked]>
Date: Fri, 9 Sep 2016 12:24:22 -0800

Hi, all:

As you may have noticed, text related to name redaction
has been excised from 6962-bis.  Because there's interest
in support for redaction that text has been spun off into
a separate document (draft-strad-trans-redaction-00,
"Certificate Transparency: Domain Label Redaction"), and
this is a call for adoption of that draft as a working group
deliverable, for publication as (tentatively) an experimental
RFC.  If you've read the document, please let us know whether
or not you feel it's suitable for adoption, and if it's
a topic on which you've got particular interest, please
be prepared to contribute text :-).

The call for adoption closes in two weeks, at 23:59 UTC on
23 September 2016.

Thanks,

Melinda & Paul

---

From: Ben Laurie <[email-masked]>
Date: Mon, 12 Sep 2016 12:42:14 +0100

+1 for adoption...

On 9 September 2016 at 21:24, Melinda Shore <[email-masked]> wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Peter Bowen <[email-masked]>
Date: Tue, 13 Sep 2016 13:43:14 -0700

+1 for adoption

---

From: Jeremy Rowley <[email-masked]>
Date: Thu, 15 Sep 2016 15:36:43 +0000

+ 1 for adoption

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Melinda Shore
Sent: Friday, September 9, 2016 2:24 PM
To: [email-masked]
Subject: [Trans] Call for adoption: draft-strad-trans-redaction-00

Hi, all:

As you may have noticed, text related to name redaction has been excised from 
6962-bis.  Because there's interest in support for redaction that text has 
been spun off into a separate document (draft-strad-trans-redaction-00, 
"Certificate Transparency: Domain Label Redaction"), and this is a call for 
adoption of that draft as a working group deliverable, for publication as 
(tentatively) an experimental RFC.  If you've read the document, please let us 
know whether or not you feel it's suitable for adoption, and if it's a topic 
on which you've got particular interest, please be prepared to contribute text 
:-).

Thanks,

Melinda & Paul

---

From: Rob Stradling <[email-masked]>
Date: Thu, 15 Sep 2016 20:55:25 +0100

-0 for adoption.

I'm ambivalent about seeing redaction supported in CT.  I've worked on
redaction in the past only because I wanted to see CT succeed and
redaction seemed like a necessary prerequisite (to having browsers
require CT for all TLS certs).

Given that Chrome now requires CT - with redaction not permitted - for
all Symantec TLS certs, ISTM that redaction is not a necessary
prerequisite after all.  Therefore, my interest has waned.

If the WG adopts, we *really* needs folks who have a strong interest in
seeing redaction supported in CT to drive further work on this draft.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Ben Laurie <[email-masked]>
Date: Fri, 16 Sep 2016 12:18:10 +0100

> seeing redaction supported in CT to drive further work on this draft.

This is a fair point, and my position is that _if_ there is anyone who
will actually use redaction (i.e. clients that will support it, we
already know some CAs would like to be less transparent), then it
should be a WG doc, but I am equally OK with it being entirely
dropped, since it is not really an improvement to the ecosystem, in my
view.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 16 Sep 2016 12:10:52 -0800

> dropped, since it is not really an improvement to the ecosystem, in my

I haven't discussed this with Paul but my feeling right now
is that I'm happy to make adoption contingent on 1) someone
stating that they will definitely be using it, and 2) one of
those persons who will definitely be using it being willing
to step up as co-author.  There's no point to standardizing
technology that's not actually useful, and failing to adopt
the draft now does not close off the possibility of publishing
a redaction document in the future.

We've got another week - let's see if someone steps up, and
in the meantime Paul and I will talk.

Melinda

---

From: Tarah Wheeler <[email-masked]>
Date: Wed, 21 Sep 2016 13:23:14 +0000

Hi, I'm Tarah, and I'm new at Symantec. I'll be reviewing and responding
to the CT redaction thread, and actively involved in proposals.

Respectfully,

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Wed, 21 Sep 2016 10:15:45 -0800

> to the CT redaction thread, and actively involved in proposals.

A few months ago Symantec had stated that they'll be publishing
redacted labels - is that still the case?

Melinda

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 21 Sep 2016 15:00:52 -0700

>  redacted labels - is that still the case?

Symantec has stood up an RFC 6962-like log that supports an earlier
version of the redaction scheme, which reflects the thinking from 6962-bis
Draft 14.

It is not trusted by any CT client widely deployed, because it does not
implement RFC 6962 (which, as we know, does not support redaction).

Symantec has also had trouble, both with first-party and third-party
integrations (such as Venafi), with logging redacted certificates,
resulting in what might be described as 'over-redacted' certificates. That
is, certificates which are redacted even though their domains are public
and widely known, which is at conflict with Symantec's stated need for the
use case of redaction.

This has been summarized at
https://sslmate.com/blog/post/ct_redaction_in_chrome_53 for example, but
reflects redaction occurring for widely used, publicly disclosed domain
names - which seems at direct odds with the stated use cases.

Such previous explanations of Symantec's redaction policies can be found
at
http://www.symantec.com/connect/blogs/privacy-redaction-and-certificate-transparency
and
http://www.symantec.com/connect/blogs/balancing-certificate-transparency-and-privacy
, however, the evidence since these posts indicate an inconsistency in the
actual use case and policies.

This is perhaps a useful study into the utility, and the risk, of redaction.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 22 Sep 2016 11:41:48 +0100

> version of the redaction scheme, which reflects the thinking from 6962-bis

Symantec are still doing this today (e.g., https://crt.sh/?id=33742991
is a precertificate that was logged only a few hours ago).

The following report shows all of the "redacted precertificates" that
Symantec have issued, along with the corresponding certificates (where
known to CT):

https://crt.sh/reports/20160922_redacted-precertificates.html

---

From: Melinda Shore <[email-masked]>
Date: Thu, 22 Sep 2016 11:47:39 -0800

This is a reminder that the call for adoption closes tomorrow
(Friday) at 23:59 UTC.  We are also looking for commitments to
1) co-author the draft, if adopted, and 2) implement and
deploy.  It should be noted that so far we have no clear
commitments to either.

Melinda

---

From: Tarah Wheeler <[email-masked]>
Date: Fri, 23 Sep 2016 19:04:58 +0000

I will co-author the redaction RFC.

Respectfully,

Tarah Wheeler

---

From: Andrew Ayer <[email-masked]>
Date: Fri, 23 Sep 2016 13:07:01 -0700

+1 for adoption of draft-strad-trans-redaction-00.  If adopted, I plan
to implement support for redaction in my monitor and can contribute to
the document from my perspective as a monitor operator.

Regards,
Andrew

---

From: Ben Laurie <[email-masked]>
Date: Fri, 23 Sep 2016 22:57:32 +0100

In other words I guess I'm really a -0, too.