Subject: [Trans] Adoption of draft-strad-trans-redaction-00

From: Peter Bowen <[email-masked]>
Date: Thu, 24 Nov 2016 14:30:06 -0800

I've been thinking more about
[draft-strad-trans-redaction-00](https://tools.ietf.org/html/draft-strad-trans-redaction-00)
and I am now leaning against adoption by the WG.  This working group
is about transparency not translucency.  The goals stated in [What is
Certificate Transparency?](http://www.certificate-transparency.org/what-is-ct)
have not changed since first published in 2013 (according to the
WayBackMachine).  They are:

* Make it impossible (or at least very difficult) for a CA to issue a
SSL certificate for a domain without the certificate being visible to
the owner of that domain.
* Provide an open auditing and monitoring system that lets any domain
owner or CA determine whether certificates have been mistakenly or
maliciously issued.
* Protect users (as much as possible) from being duped by certificates
that were mistakenly or maliciously issued.

I believe that a log inclusion proof should provide assurance that
these goals are met.  It should mean that the certificate was included
in the log intact and that it is available from the log for review.

This is important when looking at things like
NSRequiresCertificateTransparency in Apple App Transport Security and
the [Expect-CT draft](https://tools.ietf.org/html/draft-stark-expect-ct).
These allow a server or application owner to specify that CT is
required for connections.
One can also imagine a future draft to update the [TLSA
RFC](https://tools.ietf.org/html/rfc6698) to add CT as a flag in
certificate usage so that a site could declare via DNS to only trust a
certificate that has an inclusion proof (or SCT).  Adding some
"translucent" option means that these become far less valuable policy
directives.

I think the primary driver for the redaction draft has been the fact
that one major web browser vendor has suggested that they may set a
policy to require CT by default. The IETF has been very successful by
avoiding policy and focusing on technical protocols.  For example, the
DNS RFCs discuss how DNS works not how it is deployed.  Even within
the ICANN/PTI rooted DNS, there are policy differences.  The dk TLD
requires that all DNS servers for registered domains under dk be
publicly accessible and meet certain technical requirements while the
xyz domain accepts name servers that have IP addresses in address
blocks that are not global (as defined in [RFC
6890](https://tools.ietf.org/html/rfc6890), e.g. 10.0.0.0/8).  It is
also possible to use the DNS protocol on standalone networks not
interconnected to other networks.  The same should be true for CT --
the protocol and expectations should be well defined and usable in a
variety of ways and policy should be separate from the RFCs.

To be clear, I do not believe that lack of support for adoption of the
redaction draft should imply support for a policy of requiring CT by
default.  That is a different discussion for a different list.  The
question at hand is watering down CT and that is something I do not
think should happen.

Thanks,
Peter

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Nov 2016 11:11:45 -0500 (EST)

On Thu, 24 Nov 2016, Peter Bowen wrote:

[ chair hat on ]

> WayBackMachine).  They are:

Note that the website you quote is the Google transparency project page.
It is not the IETF Trans WG charter, which you can find at:

https://datatracker.ietf.org/wg/trans/charter/

It includes:

 	While the privacy issues related to use of RFC6962 for public
 	web sites are minimal, the working group will consider privacy
 	as it might impact on uses of CT e.g. within enterprises or
 	for other uses of logs

If redaction support is something that can influence whether or not CT
gets deployed, it is definitly within the charter (or a charter update)
to work on redaction.

> avoiding policy and focusing on technical protocols.

I would argue that facilitating certain properties like redaction in
the standard would be the way to guarantee different logs can apply
different local privacy policies to their log operation. With redaction
support logs can choose to support redaction or not. With no redaction
in the specification, logs cannot make that choice.

> The question at hand is watering down CT and that is something I do not
> think should happen.

That's certainly in scope to discuss on this list during the adoption
call.

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Nov 2016 16:27:46 +0000

I think Peter is mixing up the Chrome/Google project and the IETF working group.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: Peter Bowen <[email-masked]>
Date: Fri, 25 Nov 2016 08:57:17 -0800

On Fri, Nov 25, 2016 at 8:11 AM, Paul Wouters <[email-masked]> wrote:
>> Certificate
>> Transparency?](http://www.certificate-transparency.org/what-is-ct)

You are correct, I cited the Google (6962) project, not the IETF WG
charter.  That being said, I don't think that the underlying concern
is invalid.

> gets deployed, it is definitly within the charter (or a charter update)

Lack of redaction has not prevented 6962 from being widely deployed.
There are more than a dozen logs in operation which contain over 24.5
million distinct unexpired certificates.  6962-bis builds on 6962
adding lots of positive features based on experience with 6962 and I'm
sure most logs operators will stand up new logs following the
standards track RFC when published.

Privacy is something that needs to be considered, but that does not
mean redaction is the right solution.  I would prefer that CT offer a
strong guarantee of transparency even if it means not logging every
certificate.  6962bis offers an option for privacy -- logging name
constrained CA certificates.

> in the specification, logs cannot make that choice.

This means different logs have different properties which runs
contrary to prior discussions on similar topics.  How is allowing
logging "redacted" certificates different from allowing a log to
accept certificates that it finds valuable even if they don't chain to
a known root?

Thanks,
Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Nov 2016 23:53:18 +0000

> There are more than a dozen logs in operation which contain over 24.5 million
> distinct unexpired certificates.

We don't know that.  What we do know is that the world's most-used browser is requiring it for some, soon all, certificates.  I could claim that Chrome is the only reason why 6962 is deployed.  And 12 logs is still one less than the number of root zone DNS servers :)
 
> Privacy is something that needs to be considered, but that does not mean
> redaction is the right solution.  I would prefer that CT offer a strong
> guarantee of transparency even if it means not logging every certificate.
> 6962bis offers an option for privacy -- logging name constrained CA
> certificates.

And how much does it cost, on average, to get a name-constrained subCA from one of the trusted roots?  (I have no idea; that's an honest question.)  But should privacy only be limited to those who can afford to get one, or forced to buy a wildcard, or similar?

The IETF considers privacy to be very important.  Certificates should not be exempt from that.

---

From: Matt Palmer <[email-masked]>
Date: Sat, 26 Nov 2016 11:10:58 +1100

> in the specification, logs cannot make that choice.

Logs don't redact, and they don't choose what to log (other than a few very
broad criteria to ensure stability).

- Matt

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 26 Nov 2016 00:12:35 +0000

> broad criteria to ensure stability).

Was it finally settled in -bis that logs cannot take a subset of certs from the roots they accept?