Policy Discussion: Name Redaction

1124 views
Skip to first unread message

Ryan Sleevi

unread,
Mar 31, 2016, 10:19:19 PM3/31/16
to Certificate Transparency Policy
As RFC 6962-bis approaches maturity, it seems an appropriate time to begin a discussion regarding policies surrounding the redaction of domain labels within certificates. This is particularly salient for two reasons: Ensuring that a Log Policy for RFC 6962-bis is appropriately ready as 6962-bis finalizes, and due to the upcoming requirement on 1 June 2016 that Symantec Corporation must disclose all certificates issued, as a result of a past continuous series of misissuance events.

RFC 6962-bis, Draft 13, Section 4 spells out, briefly, the argument for domain redaction, as well as possible means of technically accomplishing it. These means are, in essence, the use of a wildcard certificate, a special construction of the pre-certificate to allow substitution of domains, or the use of what is termed as a Name-Constrained Intermediate CA, which is technically compatible with the definition in the Baseline Requirements of a Technically Constrained Subordinate CA Certificate.

As part of this discussion, there are three main actors to consider - what is expected of the Logs when accepting a certificate, what is expected of CAs when submitting a precertificate, and what is expected of clients when encountering such a certificate. Our core concern is on the latter two elements - ultimately, the Log will ideally accept any submission (that appropriately chains), and instead, it's a question of what CAs are expected/permitted to do, and what Chromium clients will do in response.

There's also two facets to this discussion - what is acceptable for EV certificates, and what is acceptable for those certificates that are not EV (i.e. notions like DV/IV/OV). To simplify this, we are only talking about policies for the not-EV case. As currently implemented and deployed, name redaction is not permitted for EV certificates, as reflective of the current UI treatment granted to them and communicated to users, we have no plans to revisit this decision as a matter of policy and trust, even if it becomes technically viable. So this discussion is primarily about DV certificates.

To recap: This is focused on what CAs are expected to do (and what clients will do when encountering such) for non-EV certificates.


Option 1: No name redaction allowed at all.

This is perhaps the simplest option, and provides the most public trust and transparency. This treats all domain names, and certificates issued by public trust anchors, as needing a degree of public accountability. It improves the present state of the anti-phishing world, by requiring that all domain names (which have certificates associated with them) be publicly disclosed and programatically accessible, which can then be used to do analysis and mitigation for threats.

On the other hand, it is at some conflict with the hierarchical notion of the DNS - in which domain holders are permitted, by design, to set the policies below their domain. It does feel at odds with this design to dictate policies to domain holders that all labels must be, in effect, public.


Option 2: Allow redaction without any associated policies.

This is non-viable, precisely because it would allow a CA to redact domains to a degree that prevents detection of misissuance. For example, it is technically valid to log a precertificate for "*.?.com" - but such a log event provides no information to Monitors and Auditors of the well-functioning behaviour of the CA, or that a misissuance event has not occurred.


Option 3: Only permit redaction up to the level of effective TLD - plus two labels.

This relies upon using information from secondary sources, such as the public suffix list, to determine what an effective TLD is. For example, "com" is a TLD, as is "uk", as both appear within the IANA Root Zone Database, while "co.uk" is effectively a TLD, as registrations happen for independent and distinct security zones and entities below it, even though it is not part of the Root Zone Database.

The "plus two labels" means that, for a given domain of top.secret.example.com, we determine the effective TLD as "com", thus one additional label is "example.com", and two additional labels are "secret.example.com". As such, it would be permissible to redact as "?.secret.example.com", but it would be a violation to redact as "?.?.example.com".

The reasoning for this is subtle, and is based on finding the appropriate balance between the need for accountability and transparency with respect to Publicly Trusted Certificates, while accepting the sovereignty and needs of domain holders to keep some domain labels 'hidden' from the world at large. Accepting a policy of eTLD+1, such that "?.example.com", has been a concern of multiple domain operators we've spoken to, because of the uncertainty as to whether that certificate was for "www.example.com", "mail.example.com", or "testing-and-staging.example.com", each of which may be operated by different teams and different policies. The goal is to ensure that those running the server for, say, mail.example.com, cannot inadvertently permit a CA to misissue a certificate for www.example.com.

This also seeks to balance the incentives of domain holders who desire redaction with the need for transparency, in that it admittedly does mean that, in order to leverage the advantages afforded by name redaction, an organization must take appropriate steps to segment their DNS into a redaction zone. The risk is that, without such a policy, redaction will be seen as the default, whether by users or, worse, encouraged by CAs, and thus mask or dilute misissuance events.

With Option 3, there's two variants:

Option 3a: The determination of the "effective TLD" shall consider both the ICANN and PRIVATE divisions of the Public Suffix List (as described at https://publicsuffix.org/list/ )
Option 3b: The determination of the "effective TLD" shall only consider the ICANN section of the Public Suffix List

On the basis of the security arguments, it would seem like Option 3a is the appropriate balance, and we've not yet found an argument for Option 3b, but are including for completeness.


We would like to solicit discussion and feedback on these options, from CAs, domain holders, monitors, and clients. There are various concerns from stakeholders that have been privately raised, but we think it's much more appropriate to have a public discussion.

We would also like to see about reaching a decision over the course of the next several weeks. We believe that if there is consensus to be found as to how redaction shall happen, then it can play a significant role in determining what appropriate steps Chromium takes in response to Symantec's misissuance event, both for the set of pre-existing certificates that were issued prior to 1 June 2016, and for those certificates issued after 1 June 2016.

Nick Lamb

unread,
Apr 1, 2016, 4:04:01 AM4/1/16
to Certificate Transparency Policy
As an individual I am a relying party, a domain holder, and, thanks to Let's Encrypt, a subscriber in the sense in which CAs understand that word. In my day job I operate a private CA, and write software which relies upon both the web PKI and private trust relationships, but I do not speak for my employer here.

Option 1 seems like the best option overall.

It's the most straight-forward and thus, very importantly, easiest to get right. This is important because CAs have no history of correct implementation of new standards. On the contrary, we've seen every sort of mistake and excuse from CAs over the years, so we can expect that any redaction options will immediately be abused, with CAs offering the excuse that they didn't properly understand the rules, and that getting the rules right was too hard, and then that they historically got things wrong and feel they owe a duty to their subscribers (which is to say, not the general public who need the Web PKI to be safe, but their paying customers who often don't care) to keep disobeying the rules indefinitely rather than disappoint the customer by admitting to their mistake.

As I understand it, the CT logs today are effectively Option 1 for lack of any implementation of alternatives. Do we have any evidence of actual problems caused by this, as opposed to (as will inevitably happen) stakeholders proposing theoretical problems or stating their dislike for this outcome? Just because the option to redact has been conceived, doesn't mean we need to choose it.

Redaction is an interesting technology, but I don't think it's appropriate for open Web PKI. I can easily imagine a future where CT is such a success that successful CAs run CT logs for the certificates which aren't intended for the open Web PKI, often sold as "Private SSL" or "Corporate SSL" just to be able to show their subscribers on these services that they're doing responsible things. For example Entrust's "Private SSL" CA promises exclusive control of a (non-public, and thus not ICANN sanctioned) DNS suffix within their shared CA. So while two rival corporations share the same CA (the wisdom of this I won't comment on) the most obvious and dramatic nasty outcomes, in which your rival secures a certificate for a name you're already using, is not possible with this CA. With redacted CT logs they could prove they live up to this promise, in a way that a company's own technical personnel (or the sector's media) could scrutinize at their leisure.

Håvard Molland

unread,
Apr 1, 2016, 6:18:26 AM4/1/16
to Ryan Sleevi, Certificate Transparency Policy
I see another variant of option 3 which seems worth mentioning. Require that certificates with SCTs containing name redaction are only allowed to be served from the private IP address space. This is a policy that would have to be implemented in the client, so it's not a CA policy as such. That is, if the client receives a SCT with name redaction from a server on a public IP, the cert validation would fail. This could help mitigate phishing certs (only for those clients supporting CT though [1]), and it would probably restrain server owners from unnecessarily using name redactions.

[1] ..or it could be combined with some "local only" critical extension, meaning that name redacted certs would only work in clients supporting the extension. This might be acceptable since it will only affect private networks where there is relative good control of which clients are being used.

On Fri, Apr 1, 2016 at 4:19 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

Option 1: No name redaction allowed at all.

This is perhaps the simplest option, and provides the most public trust and transparency. This treats all domain names, and certificates issued by public trust anchors, as needing a degree of public accountability. It improves the present state of the anti-phishing world, by requiring that all domain names (which have certificates associated with them) be publicly disclosed and programatically accessible, which can then be used to do analysis and mitigation for threats.

On the other hand, it is at some conflict with the hierarchical notion of the DNS - in which domain holders are permitted, by design, to set the policies below their domain. It does feel at odds with this design to dictate policies to domain holders that all labels must be, in effect, public.


Option 2: Allow redaction without any associated policies.

This is non-viable, precisely because it would allow a CA to redact domains to a degree that prevents detection of misissuance. For example, it is technically valid to log a precertificate for "*.?.com" - but such a log event provides no information to Monitors and Auditors of the well-functioning behaviour of the CA, or that a misissuance event has not occurred.


Option 3: Only permit redaction up to the level of effective TLD - plus two labels.

This relies upon using information from secondary sources, such as the public suffix list, to determine what an effective TLD is. For example, "com" is a TLD, as is "uk", as both appear within the IANA Root Zone Database, while "co.uk" is effectively a TLD, as registrations happen for independent and distinct security zones and entities below it, even though it is not part of the Root Zone Database.

The "plus two labels" means that, for a given domain of top.secret.example.com, we determine the effective TLD as "com", thus one additional label is "example.com", and two additional labels are "secret.example.com". As such, it would be permissible to redact as "?.secret.example.com", but it would be a violation to redact as "?.?.example.com".

The reasoning for this is subtle, and is based on finding the appropriate balance between the need for accountability and transparency with respect to Publicly Trusted Certificates, while accepting the sovereignty and needs of domain holders to keep some domain labels 'hidden' from the world at large. Accepting a policy of eTLD+1, such that "?.example.com", has been a concern of multiple domain operators we've spoken to, because of the uncertainty as to whether that certificate was for "www.example.com", "mail.example.com", or "testing-and-staging.example.com", each of which may be operated by different teams and different policies. The goal is to ensure that those running the server for, say, mail.example.com, cannot inadvertently permit a CA to misissue a certificate for www.example.com.

This also seeks to balance the incentives of domain holders who desire redaction with the need for transparency, in that it admittedly does mean that, in order to leverage the advantages afforded by name redaction, an organization must take appropriate steps to segment their DNS into a redaction zone. The risk is that, without such a policy, redaction will be seen as the default, whether by users or, worse, encouraged by CAs, and thus mask or dilute misissuance events.

With Option 3, there's two variants:

Option 3a: The determination of the "effective TLD" shall consider both the ICANN and PRIVATE divisions of the Public Suffix List (as described at https://publicsuffix.org/list/ )
Option 3b: The determination of the "effective TLD" shall only consider the ICANN section of the Public Suffix List

On the basis of the security arguments, it would seem like Option 3a is the appropriate balance, and we've not yet found an argument for Option 3b, but are including for completeness.


We would like to solicit discussion and feedback on these options, from CAs, domain holders, monitors, and clients. There are various concerns from stakeholders that have been privately raised, but we think it's much more appropriate to have a public discussion.

We would also like to see about reaching a decision over the course of the next several weeks. We believe that if there is consensus to be found as to how redaction shall happen, then it can play a significant role in determining what appropriate steps Chromium takes in response to Symantec's misissuance event, both for the set of pre-existing certificates that were issued prior to 1 June 2016, and for those certificates issued after 1 June 2016.

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/c0aa7e6f-9f42-4b2d-a59a-5fc5184a16c3%40chromium.org.

Ben Laurie

unread,
Apr 1, 2016, 8:37:19 AM4/1/16
to Ryan Sleevi, Certificate Transparency Policy
On 1 April 2016 at 03:19, Ryan Sleevi <rsl...@chromium.org> wrote:
As RFC 6962-bis approaches maturity, it seems an appropriate time to begin a discussion regarding policies surrounding the redaction of domain labels within certificates. This is particularly salient for two reasons: Ensuring that a Log Policy for RFC 6962-bis is appropriately ready as 6962-bis finalizes, and due to the upcoming requirement on 1 June 2016 that Symantec Corporation must disclose all certificates issued, as a result of a past continuous series of misissuance events.

RFC 6962-bis, Draft 13, Section 4 spells out, briefly, the argument for domain redaction, as well as possible means of technically accomplishing it. These means are, in essence, the use of a wildcard certificate, a special construction of the pre-certificate to allow substitution of domains, or the use of what is termed as a Name-Constrained Intermediate CA, which is technically compatible with the definition in the Baseline Requirements of a Technically Constrained Subordinate CA Certificate.

As part of this discussion, there are three main actors to consider - what is expected of the Logs when accepting a certificate, what is expected of CAs when submitting a precertificate, and what is expected of clients when encountering such a certificate. Our core concern is on the latter two elements - ultimately, the Log will ideally accept any submission (that appropriately chains), and instead, it's a question of what CAs are expected/permitted to do, and what Chromium clients will do in response.

There's also two facets to this discussion - what is acceptable for EV certificates, and what is acceptable for those certificates that are not EV (i.e. notions like DV/IV/OV). To simplify this, we are only talking about policies for the not-EV case. As currently implemented and deployed, name redaction is not permitted for EV certificates, as reflective of the current UI treatment granted to them and communicated to users, we have no plans to revisit this decision as a matter of policy and trust, even if it becomes technically viable. So this discussion is primarily about DV certificates.

To recap: This is focused on what CAs are expected to do (and what clients will do when encountering such) for non-EV certificates.


Option 1: No name redaction allowed at all.

This is perhaps the simplest option, and provides the most public trust and transparency. This treats all domain names, and certificates issued by public trust anchors, as needing a degree of public accountability. It improves the present state of the anti-phishing world, by requiring that all domain names (which have certificates associated with them) be publicly disclosed and programatically accessible, which can then be used to do analysis and mitigation for threats.

On the other hand, it is at some conflict with the hierarchical notion of the DNS - in which domain holders are permitted, by design, to set the policies below their domain. It does feel at odds with this design to dictate policies to domain holders that all labels must be, in effect, public.

This point seems important to me, and allows for a fourth possibility:

Option 4: Allow domain owners to set redaction policy

This could be informal, e.g. domain owners can spot certs with names in their domains that are overly redacted in their view, and then:

a) Update their internal policies to prevent recurrence,

b) Ask for the corresponding cert to be revoked.

This could also deal with redactions like "?.com" as anyone owning a domain in .com would be able to ask for revocation.



Option 2: Allow redaction without any associated policies.

This is non-viable, precisely because it would allow a CA to redact domains to a degree that prevents detection of misissuance. For example, it is technically valid to log a precertificate for "*.?.com" - but such a log event provides no information to Monitors and Auditors of the well-functioning behaviour of the CA, or that a misissuance event has not occurred.


Option 3: Only permit redaction up to the level of effective TLD - plus two labels.

This relies upon using information from secondary sources, such as the public suffix list, to determine what an effective TLD is. For example, "com" is a TLD, as is "uk", as both appear within the IANA Root Zone Database, while "co.uk" is effectively a TLD, as registrations happen for independent and distinct security zones and entities below it, even though it is not part of the Root Zone Database.

The "plus two labels" means that, for a given domain of top.secret.example.com, we determine the effective TLD as "com", thus one additional label is "example.com", and two additional labels are "secret.example.com". As such, it would be permissible to redact as "?.secret.example.com", but it would be a violation to redact as "?.?.example.com".

The reasoning for this is subtle, and is based on finding the appropriate balance between the need for accountability and transparency with respect to Publicly Trusted Certificates, while accepting the sovereignty and needs of domain holders to keep some domain labels 'hidden' from the world at large. Accepting a policy of eTLD+1, such that "?.example.com", has been a concern of multiple domain operators we've spoken to, because of the uncertainty as to whether that certificate was for "www.example.com", "mail.example.com", or "testing-and-staging.example.com", each of which may be operated by different teams and different policies. The goal is to ensure that those running the server for, say, mail.example.com, cannot inadvertently permit a CA to misissue a certificate for www.example.com.

This also seeks to balance the incentives of domain holders who desire redaction with the need for transparency, in that it admittedly does mean that, in order to leverage the advantages afforded by name redaction, an organization must take appropriate steps to segment their DNS into a redaction zone. The risk is that, without such a policy, redaction will be seen as the default, whether by users or, worse, encouraged by CAs, and thus mask or dilute misissuance events.

With Option 3, there's two variants:

Option 3a: The determination of the "effective TLD" shall consider both the ICANN and PRIVATE divisions of the Public Suffix List (as described at https://publicsuffix.org/list/ )
Option 3b: The determination of the "effective TLD" shall only consider the ICANN section of the Public Suffix List

On the basis of the security arguments, it would seem like Option 3a is the appropriate balance, and we've not yet found an argument for Option 3b, but are including for completeness.


We would like to solicit discussion and feedback on these options, from CAs, domain holders, monitors, and clients. There are various concerns from stakeholders that have been privately raised, but we think it's much more appropriate to have a public discussion.

We would also like to see about reaching a decision over the course of the next several weeks. We believe that if there is consensus to be found as to how redaction shall happen, then it can play a significant role in determining what appropriate steps Chromium takes in response to Symantec's misissuance event, both for the set of pre-existing certificates that were issued prior to 1 June 2016, and for those certificates issued after 1 June 2016.

--

Ryan Sleevi

unread,
Apr 1, 2016, 12:05:08 PM4/1/16
to Håvard Molland, Ryan Sleevi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 3:17 AM, Håvard Molland <haav...@opera.com> wrote:
I see another variant of option 3 which seems worth mentioning. Require that certificates with SCTs containing name redaction are only allowed to be served from the private IP address space. This is a policy that would have to be implemented in the client, so it's not a CA policy as such. That is, if the client receives a SCT with name redaction from a server on a public IP, the cert validation would fail. This could help mitigate phishing certs (only for those clients supporting CT though [1]), and it would probably restrain server owners from unnecessarily using name redactions.

[1] ..or it could be combined with some "local only" critical extension, meaning that name redacted certs would only work in clients supporting the extension. This might be acceptable since it will only affect private networks where there is relative good control of which clients are being used.

Right, I think that if this option was pursued, we'd likely need to consider it in combination with [1]. Certificate Transparency is meant to provide transparency for the whole ecosystem, and only requires a sizable number of clients to actually do the checking (SCT, STH, etc) to achieve that, much like a herd immunity. The concern would be that allowing this without [1] would mean that clients that don't fully support CT would have no protection, and I think that would be in conflict with the goals.

The question of how to implement [1] is figuring out what represents an acceptable set of "local only" in a world of IPv6. My understanding and belief is that the notion of a separation between "public" and "private" becomes significantly more muddy in an IPv6 world - while you could say it's only applicable to link-local addresses, I believe that's different (and less flexible) then what you'd get with IPv4's reserved IP range - and so if we accept IPv6 as a reality, I'm not sure how we would implement that.

Do you have any thoughts about how you'd segment "private" and "public", for IPv4 and IPv6, to be able to enforce this?

I'm also ignoring the practical matter that I think [1], while I believe necessary to balance the risks, would probably be at odds with the use case/justification for redacted certs (e.g. interoperating with legacy clients in an organization's private infrastructure), so this may not work in practice, but I do think it's worth exploring.

Ryan Sleevi

unread,
Apr 1, 2016, 12:15:38 PM4/1/16
to Ben Laurie, Ryan Sleevi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 5:37 AM, Ben Laurie <be...@google.com> wrote:
On 1 April 2016 at 03:19, Ryan Sleevi <rsl...@chromium.org> wrote:
<snip>
On the other hand, it is at some conflict with the hierarchical notion of the DNS - in which domain holders are permitted, by design, to set the policies below their domain. It does feel at odds with this design to dictate policies to domain holders that all labels must be, in effect, public.
This point seems important to me, and allows for a fourth possibility:

Option 4: Allow domain owners to set redaction policy

This could be informal, e.g. domain owners can spot certs with names in their domains that are overly redacted in their view, and then:

a) Update their internal policies to prevent recurrence,

b) Ask for the corresponding cert to be revoked.

This could also deal with redactions like "?.com" as anyone owning a domain in .com would be able to ask for revocation.

Unfortunately, I think relying on revocation - which seems key to this proposal - would be a non-starter, given that revocation doesn't work; not just for browsers, but also the vast majority of TLS clients (e.g. those based on OpenSSL, or those using language bindings from PHP, Perl, Python, Go, etc).

So I want to avoid a situation where revocation (either via OCSP/CRL or via blacklisting) is seen as the mitigation for a problem.

A variation of this is that the domain holder doesn't ask for the corresponding cert to be revoked, but instead asks for the corresponding certificate to be disclosed and publicly logged. However, I think that begins to suffer the same problem as the eTLD+1-style redaction, which is that it overly-incentivizes redaction, and reduces the ability for Monitors, Auditors, and the community at large to ensure that a CA is following applicable practices.

There is certainly an element of CT Monitoring for which ONLY the legitimate domain holder can make attestations to. For example, only google.com can clearly and decisively determine whether or not a certificate for www.google.com is misissued (from the point of view of naming). However, anyone in the Monitoring/Auditing community can determine if the certificate is misissued for other reasons, such as failing to abide by the Baseline Requirements' policies on extensions, cryptographic algorithms, naming forms, etc.

However, even though the domain holder is the only clear determinant for misissuance, under today's (no redaction) system, Monitors and Auditors can still make use of the information in CT logs as a signal of the probability of misissuance, and potentially notify or communicate with the domain holder.

For example, consider a CT Monitor-as-a-service who is looking for misissuance for "www.example.com". It may be the case that their CDN (cdn.example.com) uses a different CA (or arbitrary set of CAs), and their marketing team (demo.example.com) may be a third-party company, but "www.example.com" is always under direct control of the organization, and so they coordinate with a monitor to make sure it always follows the policies. When such a monitoring service sees a ?.example.com that conflicts with www.example.com's policy, it has no option but to trigger an alarm, since it can't be sure that ? was for www or for cdn.

If we want Monitoring to be effective for domain holders, we want to reduce the number of false alarms. If the domain holder has to respond to each and every alarm (which may have been caused by their CDN or their marketing company choosing to issue a redacted cert, perhaps because the CA offered the option), ask the CA to log the full cert (after first having to prove that they are, in fact, example.com to the CA), and then configure the Monitor to ignore that pre-cert iff it has the matching certificate, then I think that prevents effective or scalable monitoring.

This is also (part of) the logic behind eTLD+1.

As such, I have trouble thinking this Option 4 is at all viable or acceptable, on a pragmatic standpoint, for a healthy CT ecosystem, but I'd appreciate a second-check of the logic here to make sure I haven't misunderstood anything.

Ben Laurie

unread,
Apr 1, 2016, 1:03:27 PM4/1/16
to Ryan Sleevi, Certificate Transparency Policy
On 1 April 2016 at 17:14, Ryan Sleevi <rsl...@chromium.org> wrote:


On Fri, Apr 1, 2016 at 5:37 AM, Ben Laurie <be...@google.com> wrote:


On 1 April 2016 at 03:19, Ryan Sleevi <rsl...@chromium.org> wrote:
<snip>
On the other hand, it is at some conflict with the hierarchical notion of the DNS - in which domain holders are permitted, by design, to set the policies below their domain. It does feel at odds with this design to dictate policies to domain holders that all labels must be, in effect, public.

This point seems important to me, and allows for a fourth possibility:

Option 4: Allow domain owners to set redaction policy

This could be informal, e.g. domain owners can spot certs with names in their domains that are overly redacted in their view, and then:

a) Update their internal policies to prevent recurrence,

b) Ask for the corresponding cert to be revoked.

This could also deal with redactions like "?.com" as anyone owning a domain in .com would be able to ask for revocation.

Unfortunately, I think relying on revocation - which seems key to this proposal - would be a non-starter, given that revocation doesn't work; not just for browsers, but also the vast majority of TLS clients (e.g. those based on OpenSSL, or those using language bindings from PHP, Perl, Python, Go, etc).

So I want to avoid a situation where revocation (either via OCSP/CRL or via blacklisting) is seen as the mitigation for a problem.

So, is the idea with 3 that logs refuse to log certs that don't comply?

Andrew Ayer

unread,
Apr 1, 2016, 1:31:46 PM4/1/16
to Certificate Transparency Policy
On Thu, 31 Mar 2016 19:19:19 -0700 (PDT)
Ryan Sleevi <rsl...@chromium.org> wrote:

> *Option 3*: Only permit redaction up to the level of effective TLD -
I'm generally supportive of name redaction, and I understand the
concerns with allowing eTLD+1 redaction. That said, the eTLD+2 policy
strikes me as rather arbitrary and I don't think it fully solves the
problems which you raised. For instance, a sub-division of example.com
which uses sub.example.com might outsource their mail server,
mail.sub.example.com, to a third party. If a name-redacted pre-cert
for ?.sub.example.com is logged, the monitor run by sub.example.com
would not know what to do. Also, CAs could still redact as
much as possible by default. If they think redaction is good, why
wouldn't they? The difference in harm to the CT ecosystem between
redacting to eTLD+1 by default and redacting to eTLD+2 by default is
just a matter of degree.

I would instead require mandatory opt-in to name redaction with
a newly-defined property in a CAA record. Any label to the left
of the name with the CAA record could be redacted. For example,
a domain holder could allow redactions like ?.internal.example.com
or ?.?.internal.example.com by setting the appropriate CAA record on
internal.example.com. A domain holder who is sufficiently confident in
their internal accounting of certificates could even permit redactions
like ?.example.com by setting a domain-wide CAA record on example.com.
And a domain holder who wants no redaction could have that too.

Browsers would not be able to enforce this policy. However, a domain
holder's monitor would know their redaction policy and raise an alarm
if an overly-redacted pre-certificate for their domain is logged. Of
course, browsers should still enforce that no labels are redacted past
eTLD+1, to ensure that a domain holder's monitor can actually notice
the log entry.

Regards,
Andrew

Nick Lamb

unread,
Apr 1, 2016, 1:53:36 PM4/1/16
to Certificate Transparency Policy, haav...@opera.com, rsl...@chromium.org

On Friday, 1 April 2016 17:05:08 UTC+1, Ryan Sleevi wrote:
The question of how to implement [1] is figuring out what represents an acceptable set of "local only" in a world of IPv6. My understanding and belief is that the notion of a separation between "public" and "private" becomes significantly more muddy in an IPv6 world - while you could say it's only applicable to link-local addresses, I believe that's different (and less flexible) then what you'd get with IPv4's reserved IP range - and so if we accept IPv6 as a reality, I'm not sure how we would implement that.

Modern IPv6 does have the notion of "local" address ranges but they're globally unique. RFC 4193 explains the sensible engineering solution which carves out a range, within which you pick 48 random bits for your organisation, plus 16 bits of subnet IDs

The reason they're globally unique is that we know from IPv4 that organisations merge all the time, and then invariably end up with address collisions and all the mess that entails. Obeying RFC 4193 statistically renders such collisions so unlikely as to be irrelevant unless you're hooking hundreds of thousands of networks together, which is hardly a "private" system any more. In practice it is reasonable to expect some people will set the "random" bits to 0000 0000 0000 because people are idiots, but hopefully we can train administrators on larger networks to take the word "random" at least semi-seriously.

So, anyway, it would be possible for Chrome to detect that an address was in the RFC 4193 range, thus not on the public Internet, and choose to behave differently for that address, much as it might for RFC 1918 addresses today. It doesn't seem sensible to me to apply semantics to the addressing, whether for RFC 1918 or RFC 4193, but it's certainly no crazier for RFC 4193 than it was for RFC 1918.

Ryan Sleevi

unread,
Apr 1, 2016, 2:06:03 PM4/1/16
to Ben Laurie, Ryan Sleevi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 10:03 AM, Ben Laurie <be...@google.com> wrote:
On 1 April 2016 at 17:14, Ryan Sleevi <rsl...@chromium.org> wrote:
<snip>
Unfortunately, I think relying on revocation - which seems key to this proposal - would be a non-starter, given that revocation doesn't work; not just for browsers, but also the vast majority of TLS clients (e.g. those based on OpenSSL, or those using language bindings from PHP, Perl, Python, Go, etc).

So I want to avoid a situation where revocation (either via OCSP/CRL or via blacklisting) is seen as the mitigation for a problem.
So, is the idea with 3 that logs refuse to log certs that don't comply?

Well, as I tried to call out in the original message, my hope is to avoid policies that require log behaviour changes; the policies can be enforced/observed via Monitors and Auditors, rather than implemented via Logs themselves (much in the same way that it's beneficial for logs to accept certificates from CAs that do not conform to the Baseline Requirements, so long as they're validly signed)

In all cases of name redaction, I think the answer for what happens when a CA "over-redacts" a certificate would be to take appropriate action on that CA, as befitting root store maintenance. This could vary in severity from no longer allowing that CA to redact at all (since their redactions were not in accordance with their status as a public trust provider) to removing that CA from the trust store entirely. 

Ryan Sleevi

unread,
Apr 1, 2016, 2:17:09 PM4/1/16
to Andrew Ayer, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 10:25 AM, Andrew Ayer <ag...@andrewayer.name> wrote:
I'm generally supportive of name redaction, and I understand the
concerns with allowing eTLD+1 redaction.  That said, the eTLD+2 policy
strikes me as rather arbitrary and I don't think it fully solves the
problems which you raised.  For instance, a sub-division of example.com
which uses sub.example.com might outsource their mail server,
mail.sub.example.com, to a third party.  If a name-redacted pre-cert
for ?.sub.example.com is logged, the monitor run by sub.example.com
would not know what to do.  Also, CAs could still redact as
much as possible by default. If they think redaction is good, why
wouldn't they?  The difference in harm to the CT ecosystem between
redacting to eTLD+1 by default and redacting to eTLD+2 by default is
just a matter of degree.

Absolutely correct.
 
I would instead require mandatory opt-in to name redaction with
a newly-defined property in a CAA record.  Any label to the left
of the name with the CAA record could be redacted.  For example,
a domain holder could allow redactions like ?.internal.example.com
or ?.?.internal.example.com by setting the appropriate CAA record on
internal.example.com.  A domain holder who is sufficiently confident in
their internal accounting of certificates could even permit redactions
like ?.example.com by setting a domain-wide CAA record on example.com.
And a domain holder who wants no redaction could have that too.

Browsers would not be able to enforce this policy.  However, a domain
holder's monitor would know their redaction policy and raise an alarm
if an overly-redacted pre-certificate for their domain is logged.  Of
course, browsers should still enforce that no labels are redacted past
eTLD+1, to ensure that a domain holder's monitor can actually notice
the log entry.

Andrew,

Thanks for bringing this up, because it's actually come up several times in past discussions on the matter, and I agree, I think this is a promising avenue for exploration.

There are upsides and downsides to this, and quite honestly, we're not sure where the balance is, so it's great to have more of this discussion.

The upsides are, as you note, it gives the domain holder full control via mandatory opt-in, and that allows maximum flexibility.

The downsides are a bit more with this proposal, and affect the timing and delivery of a policy:
- The specification of the CAA property (should it be an attribute on the 'issue' / 'issuewild', or should it be a new CAA attribute?)
- Whether or not CAs are obligated to check CAA today (they are not) or what they do in the presence of a violation of a CAA record. CAs are, surprisingly, not supportive of actually respecting the CAA property when it says "not them", apparently because they feel it's anticompetitive. I find this disappointing and boggle at the logic there, but it's relevant to consider that, as such, CAs may instead simply ignore this property. If we were to go this route, it would affect not just how a CA logs, but also how a CA handles CAA records, and that can take time.
- It becomes a policy of CAs issuance practices that cannot be objectively measured or quantified. That is, there's no way an independent third-party can assess whether or not a CA is following their stated policies and practices regarding the handling.

These downsides are not insurmountable by any means. For example, monitors and auditors already lack the ability to objectively evaluate whether or not a CA is following its domain validation procedures, precisely because the only party that can speak to whether or not they authorized things is the domain holder themselves.

There is a slight issue (or perhaps it's not actually an issue), which is more intrinsic to CAA itself, which is that CAA records flow from the leaf to the parent, rather than from the parent to the leaf. That is, if foo.internal.example.com sets a policy to allow name redaction, but example.com wants to set a blanket policy of forbidding name redaction for all of its domains, there's no way to express that in CAA. That's because the CAA Record Set terminates search the moment it finds the CAA at foo.internal.example.com. Even though example.com is hierarchically superior, it has less control.


I mention all of this to explore the tradeoffs, because it's useful to hear from those who both favor name redaction (for their own domains, naturally) and to those who would not want name redaction (which may include both domain holders, such as the example.com vs foo.internal.example.com case I mentioned, as well as Monitors/Auditors who believe in greater transparency for the Public Trust ecosystem).

Finally, I'm wondering what suggestions you, or others, would have on what the expectations would be around a solution. I would presume that it would be contingent upon a CA that MUST examine CAA records, and MUST NOT issue certificates in violation of that policy in any circumstance (that is, the only way to support that redaction would be for the domain holder to change their record).

Fabrice Gautier

unread,
Apr 1, 2016, 2:54:43 PM4/1/16
to Nick Lamb, Certificate Transparency Policy, haav...@opera.com, rsl...@chromium.org
Some companies do use "public" IPv4 addresses for their private
internal network as well, so it looks like such proposal would prevent
them from doing any name redaction.

-- Fabrice

Kane York

unread,
Apr 1, 2016, 2:55:22 PM4/1/16
to Certificate Transparency Policy, ag...@andrewayer.name, rsl...@chromium.org
First of all, I support the eTLD+2 proposal, with language strongly suggesting that it be named things like 'private', 'internal', or 'restricted'. For example, "service.internal.company.co.uk" would be allowed to be logged as "?.internal.company.co.uk".

What if we had a CAA record that was enforced by the browser?

> Upon encountering a domain that presents a certificate with a redacted-segment Signed Certificate Timestamp, the browser will query the CAA records for the parent domain. If the returned CAA record is nonexistent or does not have the "allowredaction" (Name TBD) attribute, the certificate is invalid and a certificate error should be presented to the user. Additionally, if the domain's parent's parent is a public suffix, [if company.co.uk is a public suffix: False] the certificate is invalid.
> The certificate authority must not issue a redacted-name certificate without verifying the existence of such a CAA record, and such a record must be at least 2 levels below the public suffix.

This procedure is independently verifiable - if there is no such CAA record on internal.company.co.uk, then the issued certificate is bogus.
It does add latency - 1 uncommon DNS query - to the browser's TLS connection, which is unfortunate. I would recommend caching a positive result for a static period (24hr?) to avoid that overhead, and a negative result for a shorter period (10m?) to discourage attacks.

Also, it makes DNS a source of certificate validity information, which it was not in the past. Questionable dependency there.

Kane York

unread,
Apr 1, 2016, 2:59:31 PM4/1/16
to Certificate Transparency Policy, ag...@andrewayer.name, rsl...@chromium.org


On Friday, April 1, 2016 at 11:55:22 AM UTC-7, Kane York wrote:

This procedure is independently verifiable - if there is no such CAA record on internal.company.co.uk, then the issued certificate is bogus.
It does add latency - 1 uncommon DNS query - to the browser's TLS connection, which is unfortunate. I would recommend caching a positive result for a static period (24hr?) to avoid that overhead, and a negative result for a shorter period (10m?) to discourage attacks.

Mistyped - meant "mitigate" the checking overhead. 

Ryan Sleevi

unread,
Apr 1, 2016, 3:04:01 PM4/1/16
to Kane York, Certificate Transparency Policy, Andrew Ayer, Ryan Sleevi
On Fri, Apr 1, 2016 at 11:55 AM, Kane York <kane...@gmail.com> wrote:

First of all, I support the eTLD+2 proposal, with language strongly suggesting that it be named things like 'private', 'internal', or 'restricted'. For example, "service.internal.company.co.uk" would be allowed to be logged as "?.internal.company.co.uk".

What if we had a CAA record that was enforced by the browser?

Sorry, that's been more than thoroughly discussed during the CAA standardization. That's not what CAA is for, not just as a matter of "Well, we don't want that," but for all the reasons that were covered during CAA standardization.

The simplest, easiest answer for "Why that's not viable" is perhaps pointing out that certificate policies change over time. I may have allowed CA X at time 0, but CA Y a year later. Similarly, I may have allowed redaction in the past, but decided not to allow it now.

On the client side, in the real world, there's simply no way to reliably get the records needed. So that's also a hard blocker.
 
This procedure is independently verifiable - if there is no such CAA record on internal.company.co.uk, then the issued certificate is bogus.
It does add latency - 1 uncommon DNS query - to the browser's TLS connection, which is unfortunate. I would recommend caching a positive result for a static period (24hr?) to avoid that overhead, and a negative result for a shorter period (10m?) to discourage attacks.

Also, it makes DNS a source of certificate validity information, which it was not in the past. Questionable dependency there.

For the reasons explained above, it doesn't.

It's worth highlighting that the CAA record as proposed by Andrew *also* cannot be independently verified, because CAA checks are done at time of validation of the domain, which can happen up to 39 months before the actual issuance of a certificate (as per the Baseline Requirements). So even for a certificate freshly issued, a third-party Monitor (e.g. not the domain holder) cannot go and fetch CAA records and examine whether or not the CA followed its policy. Only the domain holder can make that attestation.

The difference, and benefit, of Andrew's CAA proposal versus a blanket policy (eTLD+1/eTLD+2/no restriction), is that it makes name redaction an explicit, quantifiable, objective opt-in on behalf of the domain holder. A CA cannot simply push its customers into name redaction by default, for example, and it's not something that a domain holder can do "by accident". 

Ryan Sleevi

unread,
Apr 1, 2016, 3:14:30 PM4/1/16
to Nick Lamb, Certificate Transparency Policy, Håvard Molland, Ryan Sleevi
Ah! I had missed that.

There is one more downside to this approach - and it's one we've explored with similar web policies gated on notions of public vs private - which is that it runs the risk of creating non-deterministic behaviours for standard configs. That is, consider the "split-DNS" route where a service resolution for "example.com" returns [FC00:..., 2001:0400:..., 8.x.x.x]. Depending on a variety of factors (Happy Eyeballs, DNS round robin, etc), the address you connect to could vary, which means that you can encounter a service that has the appearance of arbitrarily failing, even when they're all talking to the same endpoint.

This has certainly been a concern in other contexts (for example, treatment of certain local traffic as apriori secure for privielged features), and perhaps it's even more of an edge case to expect to see this, but that'd at least be part of the concern with this.

It also seems like it doesn't fit with the model where these internal services may be listening on globally routable addresses (or at least, mapped so such via DNS), but which only answer for certain networks (for example, firewall ingress policies or VPNs). In this model, you still want to prevent the certificates from being logged, but you'd want to be able to serve them on globally routable IPv6 IPs.

Finally, the last place where I can think it gets 'weird' is with things like HTTP/2's connection coalescing properties. What happens if you have a certificate that contains both "public" and "redacted" names as part of a single certificate. With how HTTP/2 coalescing is defined, it would be viable to reuse the "public" IP connection for the "redacted" domain (note: the client has the full, unredacted certificate; it's only the SCT that is redacted), which would bypass these policies. It would seem like it would involve some changes to HTTP/2 spec, or at least browsers' Fetch() spec, to examine not just the certificate (which has the full name) but also the SCTs, and establish a new unique connection to that domain, and then ensure that domain matches the private IPv4/IPv6 space, and then and only then allow the connection to continue.

I may have missed something, though, in thinking why this proposal may not be workable, much like I did with the IPv6 segmentation of FC00, so definitely want to keep the discussion going. 

Andrew Ayer

unread,
Apr 1, 2016, 4:06:24 PM4/1/16
to Certificate Transparency Policy
On Fri, 1 Apr 2016 11:16:28 -0700
Ryan Sleevi <rsl...@chromium.org> wrote:

> - The specification of the CAA property (should it be an attribute on
> the 'issue' / 'issuewild', or should it be a new CAA attribute?)
> - Whether or not CAs are obligated to check CAA today (they are not)
> or what they do in the presence of a violation of a CAA record. CAs
> are, surprisingly, not supportive of actually respecting the CAA
> property when it says "not them", apparently because they feel it's
> anticompetitive. I find this disappointing and boggle at the logic
> there, but it's relevant to consider that, as such, CAs may instead
> simply ignore this property. If we were to go this route, it would
> affect not just how a CA logs, but also how a CA handles CAA records,
> and that can take time.

I would make this a brand new CAA property, and completely decouple
it from the question of issue/issuewild enforcement. In theory, CAs
should have no problem with this - they aren't currently allowed to do
name redaction anyways, and the presence or lack of the name redaction
property would apply equally to all CAs. Adopting CAA for the limited
purpose of name redaction seems like all upside for CAs compared to
the status quo. Hopefully being able to offer name redaction to their
customers would be sufficient motivation for CAs to do the small amount
of engineering work needed and to overcome any psychological aversion
to the general concept of CAA. For this reason, I think it's important
that CAA be used from the beginning with name redaction if it is to ever
be used: rolling it out later will be much harder if it results in a
restriction on CAs compared to the status quo.

> - It becomes a policy of CAs issuance practices that cannot be
> objectively measured or quantified. That is, there's no way an
> independent third-party can assess whether or not a CA is following
> their stated policies and practices regarding the handling.
>
> These downsides are not insurmountable by any means. For example,
> monitors and auditors already lack the ability to objectively
> evaluate whether or not a CA is following its domain validation
> procedures, precisely because the only party that can speak to
> whether or not they authorized things is the domain holder themselves.

Indeed, the inability of third parties to assess is my greatest
reservation with this idea, although as you suggest it's not that
different from assessing DV procedures.

It's actually somewhat possible for third party monitors to quantify.
If a large percentage of the redacted pre-certs logged by a CA lack a
corresponding CAA record, particularly in comparison to other CAs'
percentages, it's an indication that the CA might be misbehaving and
deserves some additional scrutiny. This, combined with the fact that a
domain owner can always know for sure that the policy was violated,
makes me comfortable with the tradeoff.

> There is a slight issue (or perhaps it's not actually an issue),
> which is more intrinsic to CAA itself, which is that CAA records flow
> from the leaf to the parent, rather than from the parent to the leaf.
> That is, if foo.internal.example.com sets a policy to allow name
> redaction, but example.com wants to set a blanket policy of
> forbidding name redaction for all of its domains, there's no way to
> express that in CAA. That's because the CAA Record Set terminates
> search the moment it finds the CAA at foo.internal.example.com. Even
> though example.com is hierarchically superior, it has less control.

Good point, although it doesn't seem like this would be a dealbreaker
in practice. Redactions can't "escape" up the hierarchy, so if the
administrators of example.com see a redaction
of ?.internal.example.com, they know they need to talk with the
internal.example.com administrators.

> I mention all of this to explore the tradeoffs, because it's useful
> to hear from those who both favor name redaction (for their own
> domains, naturally) and to those who would not want name redaction
> (which may include both domain holders, such as the example.com vs
> foo.internal.example.com case I mentioned, as well as
> Monitors/Auditors who believe in greater transparency for the Public
> Trust ecosystem).
>
> Finally, I'm wondering what suggestions you, or others, would have on
> what the expectations would be around a solution. I would presume
> that it would be contingent upon a CA that MUST examine CAA records,
> and MUST NOT issue certificates in violation of that policy in any
> circumstance (that is, the only way to support that redaction would
> be for the domain holder to change their record).

Right, though to be clear CAs would only need to examine the name
redaction property, and not the issue/issuewild properties. I would
also propose that a violation by a CA of this policy would be grounds
to reject future name redactions by that CA.

Regards,
Andrew

Ryan Sleevi

unread,
Apr 1, 2016, 6:46:38 PM4/1/16
to Andrew Ayer, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 1:05 PM, Andrew Ayer <ag...@andrewayer.name> wrote:
I would make this a brand new CAA property, and completely decouple
it from the question of issue/issuewild enforcement.  In theory, CAs
should have no problem with this - they aren't currently allowed to do
name redaction anyways, and the presence or lack of the name redaction
property would apply equally to all CAs.  Adopting CAA for the limited
purpose of name redaction seems like all upside for CAs compared to
the status quo. Hopefully being able to offer name redaction to their
customers would be sufficient motivation for CAs to do the small amount
of engineering work needed and to overcome any psychological aversion
to the general concept of CAA.  For this reason, I think it's important
that CAA be used from the beginning with name redaction if it is to ever
be used: rolling it out later will be much harder if it results in a
restriction on CAs compared to the status quo.

In general, I agree with this, but that does mean that a specification would need to be written and submitted for IETF Expert Review, per https://tools.ietf.org/html/rfc6844#section-7.2

The other challenge here is related to the context that I originally mentioned, which is seeing how such a policy would work with respect to Chromium's upcoming enforcement of CT records for certificates issued by Symantec that are not independently-operated (e.g. sub-CAs with independent infrastructure and audits operated by non-Symantec entities).

There are three dimensions to this: the set of certificates issued prior to 1 June, the certificates issued after 1 June and prior to RFC 6962-bis compliant logs, and the certificates issued after RFC 6962-bis logs are operationalized.

Obviously, this proposal fits with the final category with no problem, but it would seem to present some challenges to the first two. Thoughts from you (or others) on this topic?
 
Good point, although it doesn't seem like this would be a dealbreaker
in practice.  Redactions can't "escape" up the hierarchy, so if the
administrators of example.com see a redaction
of ?.internal.example.com, they know they need to talk with the
internal.example.com administrators.

This is a fair point - it ensures that a single level of the label hierarchy will always be consistent, and any inconsistency will be scoped to a label beneath, but with enough indication as to the responsible party. I can buy that.
 
Right, though to be clear CAs would only need to examine the name
redaction property, and not the issue/issuewild properties.  I would
also propose that a violation by a CA of this policy would be grounds
to reject future name redactions by that CA.

So to accomplish this, it would seem like the CT Plan would need to put a requirement on the structure/contents of the CA's CP/CPS to mandate such a statement, to ensure that CAs are aware that over-redaction / failure to check CAA is a failure to follow the CA's policies, which SHOULD (in a perfect world of auditors) be a violation of their appropriate audit standard (because it was issued outside the policies).

The concern with "reject future name redactions by that CA" is that it then becomes incumbent upon every client, supporting CT, to know which CAs are in the 'naughty bin' and had their CT-redaction privileges suspended, as well as determining whether past redactions are valid or invalid, and whether or not there is a point in the future in which new redactions may be acceptable. This challenge is perhaps part of the appeal of Option 1, by sidestepping the entire problem of redaction.

At fundamental question is whether or not an over-redacted pre-certificate should represent "misissuance". If so, it's clearer what can happen to that CA, up to and including removal. However, if it's not misissuance, but "something else," that becomes trickier.

Peter Bowen

unread,
Apr 1, 2016, 6:59:01 PM4/1/16
to Ryan Sleevi, Andrew Ayer, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 3:45 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> At fundamental question is whether or not an over-redacted pre-certificate
> should represent "misissuance". If so, it's clearer what can happen to that
> CA, up to and including removal. However, if it's not misissuance, but
> "something else," that becomes trickier.

An "over-redacted" pre-certificate should not be worse than no
pre-certificate. After all, there is no requirement that a CA log
every certificate they issue, as far as I know. The requirements
suggested and discussed so far are all at the per-certificate level
and are "if you want Chrome to accept the certificate" not "if you
want Chrome to accept the CA", unless I'm missing something.

Thanks,
Peter

Ryan Sleevi

unread,
Apr 1, 2016, 7:11:39 PM4/1/16
to Peter Bowen, Ryan Sleevi, Andrew Ayer, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 3:59 PM, Peter Bowen <pzb...@gmail.com> wrote:
On Fri, Apr 1, 2016 at 3:45 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> At fundamental question is whether or not an over-redacted pre-certificate
> should represent "misissuance". If so, it's clearer what can happen to that
> CA, up to and including removal. However, if it's not misissuance, but
> "something else," that becomes trickier.

An "over-redacted" pre-certificate should not be worse than no
pre-certificate.  After all, there is no requirement that a CA log
every certificate they issue, as far as I know. 

There is or will be for two CAs - Symantec and CNNIC - at least with respect to trust.
 
The requirements
suggested and discussed so far are all at the per-certificate level
and are "if you want Chrome to accept the certificate" not "if you
want Chrome to accept the CA", unless I'm missing something.

Apologies for not being clearer. Part of this is thinking about a world in which all certificates "must" be logged, whether as a specific CA enforcement (as in the above), or in the future world for all certificates.

It's not unreasonable to state that yes, clients could each enforce this logic. Part of our goal is to minimize the amount of logic and updates that clients will need as part of a well-functioning Certificate Transparency system. Certainly, there is the understandable need to be able to update the set of qualified logs, and associated meta-data about the qualified logs (such as 'last valid' date), since logs, like CAs, can and will fail. However, an ideal world would not require tracking meta-data at the per-CA level; that is, the current state of the world with some CAs needing to be logged is an interim step, not a final step, with the final phase being that all CAs globally need to log all certificates.

That final goal is fairly easy to define, implement, and enforce, for any client that wishes to support CT in a robust fashion. However, if it becomes necessary for clients to track the 'redaction state', then that becomes even more complicated - especially if some clients permit redaction, while others prohibit it. With that in mind, we want to consider the ecosystem challenges, risks, and views when considering how to handle such events.

For example, a CA egregiously and continually over-redacts, what represents an appropriate response, both from CT and non-CT clients? For CT clients, they could reject such SCTs (thus simply not trust those certificates), but what about for non-CT clients, or for CT clients that don't necessarily have the same update cycle? What should they do?

In trying to explore this, we're trying to figure out what a recommendation for a CT implementation, that wishes to use this policy, should be reasonably expected to implement.

Today, a client would need to:
- Have the ability to update the set of trusted roots (to handle removals, for example)
- Have the ability to update the set of trusted logs (to handle removals, for example)

What we're concerned about is whether there also need to be additional requirements, such as:
- Have the ability to update whether or not a given root is required to log to CT
- Have the ability to update [??? - whatever else is an appropriate policy reaction]

That's why I'm trying to explore this space, to make sure that responses that the community feels are appropriate, with respect to name redaction, have the corresponding client code and behaviours built-in.

Sanjay Modi

unread,
Apr 1, 2016, 7:51:42 PM4/1/16
to Certificate Transparency Policy
Majority of the domains where our customers chose to preserve privacy by opting out of CT logging fall under “secret.example.com” pattern – effective TLD + 2 labels. Large enterprise customers have expressed their strong desire to keep their internal domain names private.  Permitting redaction up to the level of effective TLD - plus two labels will force many enterprises to change their internal network setup to add one more label to their domain names so that they can preserve the needed privacy.
There can be two options to preserve the privacy as well as give needed control to domain operators:
  1. Permit redaction up to the level of effective TLD - plus one label.
  2. Permit redaction up to the level of effective TLD - plus one label or allow domain operators to specify level of redaction for their domain.
A good prevention mechanism like CAA can be effectively used to allow specific CA to issue certificate to specific sub domain operated by different operators.

Ryan Sleevi

unread,
Apr 1, 2016, 7:57:37 PM4/1/16
to Sanjay Modi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 4:51 PM, Sanjay Modi <sanja...@symantec.com> wrote:
Majority of the domains where our customers chose to preserve privacy by opting out of CT logging fall under “secret.example.com” pattern – effective TLD + 2 labels. Large enterprise customers have expressed their strong desire to keep their internal domain names private.  Permitting redaction up to the level of effective TLD - plus two labels will force many enterprises to change their internal network setup to add one more label to their domain names so that they can preserve the needed privacy.

That's correct, and as explained, that would be intentional/desirable.
 
There can be two options to preserve the privacy as well as give needed control to domain operators:
  1. Permit redaction up to the level of effective TLD - plus one label.
  2. Permit redaction up to the level of effective TLD - plus one label or allow domain operators to specify level of redaction for their domain.
Given the previous explanation of concerns with eTLD+1 earlier on the thread, could you explain if anything was missed in the considerations thus far? Overall, this does not feel appropriate as a blanket policy, as I explained already, and even less so compared to eTLD+2.

A good prevention mechanism like CAA can be effectively used to allow specific CA to issue certificate to specific sub domain operated by different operators.

I'm not sure I understand the remark about a "specific CA to issue certificate to specific sub domain". The discussion of CAA was in the context of an independent property, for which the CA MUST respect, and MUST only redact IF and ONLY IF such a record was present (rather than the opposite, which seems to be what you're suggesting) 

Peter Bowen

unread,
Apr 1, 2016, 8:28:00 PM4/1/16
to Ryan Sleevi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 4:10 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Fri, Apr 1, 2016 at 3:59 PM, Peter Bowen <pzb...@gmail.com> wrote:
>>
>> On Fri, Apr 1, 2016 at 3:45 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>> > At fundamental question is whether or not an over-redacted
>> > pre-certificate
>> > should represent "misissuance". If so, it's clearer what can happen to
>> > that
>> > CA, up to and including removal. However, if it's not misissuance, but
>> > "something else," that becomes trickier.
>>
>> An "over-redacted" pre-certificate should not be worse than no
>> pre-certificate. After all, there is no requirement that a CA log
>> every certificate they issue, as far as I know.
>
>
> There is or will be for two CAs - Symantec and CNNIC - at least with respect
> to trust.

Let's pretend there is a third CA operator - InterGalacticTrust (IGT)
- in the same category as the above two and assume IGT has a CA called
"IGT Earth CA - G3". As I understand it, this CA could issue
certificates with the following characteristics:
1) EKU: serverAuth, contains SCTs
2) EKU: clientAuth, contains SCTs
3) EKU: serverAuth, no SCTs
4) EKU: clientAuth, no SCTs

Assuming that there are not SCTs in a stapled OCSP response or a TLS
extension, then Chrome would only trust (1), right? But is there any
reason that IGT couldn't log a precert for #3 or #4? And if they did,
why would it be worse to partially redact it versus not logging it?

So isn't the real issue determining if #1 really meets the requirement
to be trusted, rather than whether IGT is logging "overly" redacted
certificates?

Thanks,
Peter

Ryan Sleevi

unread,
Apr 1, 2016, 8:57:21 PM4/1/16
to Peter Bowen, Ryan Sleevi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 5:27 PM, Peter Bowen <pzb...@gmail.com> wrote:
Let's pretend there is a third CA operator - InterGalacticTrust (IGT)
- in the same category as the above two and assume IGT has a CA called
"IGT Earth CA - G3".  As I understand it, this CA could issue
certificates with the following characteristics:
1) EKU: serverAuth, contains SCTs
2) EKU: clientAuth, contains SCTs
3) EKU: serverAuth, no SCTs
4) EKU: clientAuth, no SCTs

Assuming that there are not SCTs in a stapled OCSP response or a TLS
extension, then Chrome would only trust (1), right?  But is there any
reason that IGT couldn't log a precert for #3 or #4?  And if they did,
why would it be worse to partially redact it versus not logging it?

So isn't the real issue determining if #1 really meets the requirement
to be trusted, rather than whether IGT is logging "overly" redacted
certificates?

Is it an issue? Yes, absolutely.
Is it the real issue? No, for the reasons I tried to explain what the root of the concern (aka the real issue) is.

I'm not sure if there's confusion in how I explained it, but yes, it's certainly possible to add logic to implement #1 purely client side. The downside is the economies of scale, and the number of distinct clients which would potentially need to implement that logic versus treating it as a root program policy matter. That is the real issue - there are concrete tradeoffs to both approaches, and it's unclear what the appropriate measure is.

I get the feeling, implicit from your argument, is that it can and should be a client enforcement issue. That suffers from the problems I mentioned, which makes it unappealing. The question is trying to explore what problems arise from the other approach, which is to treat it as a policy matter.

This is relevant and germane both in the case of "IGT Earth CA - G3", but also in imagining what a possible world looks like if/when CT is required for all SSL/TLS certificates. Would such a requirement be PURELY a client-side matter, or would there ALSO be a root policy requirement (that is, CAs MUST log all issued certificates, or else they're perceived as misissued)? What should a response be if a certificate can be provided that can be shown not to be in any qualified log at a given point of time?

I mention this to try to highlight the need of determining what we want "the future" to look like (in particular, with respect to "name redaction") - that is, what's the ideal outcome - and then working backwards to figure out what are transitional steps along the way that help move there, so that we don't set a decision that conflicts with that.

Michael Klieman

unread,
Apr 1, 2016, 11:02:53 PM4/1/16
to Ryan Sleevi, Certificate Transparency Policy
Thanks for starting the discussion here. There are both material implementation benefits from eTLD+1 and reasonable approaches to address the concerns you’ve raised.    

Supporting eTLD+1 provides the ability for customers who want to redact the option to do so with today’s implementations — our data shows that the majority of server operators who want to redact at all are doing so with only eTLD+1 to begin with. Supporting eTLD+1  will speed up the feasibility of making CT mandatory since it requires no changes to server operators’ infrastructure. The act of starting with eTLD+2 will necessarily slow down CT adoption to account for the time for server operators who require privacy for their internal domains to rename all their private sites — look at how long transitioning to 2048 or SHA2 is taking… starting with eTLD+1 completely eliminates the dependency on server operators and enables us to create a practical, immediately implementable (and enforceable) policy.         

The rationale for eTLD+2 seems to be centered on minimizing false alarms. There are two cases of false alarms that are being discussed:

1. Where server operators individually manage www, mail, cdn and where these server operators monitor individually (if the domain is monitored centrally, eTLD+1 is preferable for server operators and info sec team because it requires less support). It is still possible to minimize false alarms for the individuals in this case, as previously suggested, by requiring CA’s to enable customers the ability to set the level at which they redact. With this requirement, if alarms are triggered for legitimate certificates, it will only be because internal enterprise policy on the acceptable level of redaction wasn’t followed… and those alarms are OK — they will force either no redaction or following of enterprise policy (which can include differences like info sec monitoring results for all of ?.example.com and their CDN monitoring only ?.cdn.example.com).
2. The case of truly bad false alarms would occur only where a CA independently over-redacts. Our expectation is that full logging (no redaction) MUST BE the default implementation for all CA’s, something that (along with allowing customers redaction level flexibility) could be formalized as part of the baseline requirements.

With these two requirements accompanying eTLD+1, we can solve for false alarms, require nothing new from server operators, and create an approach that can move the industry far more quickly to universal support for CT.  





--

Ryan Sleevi

unread,
Apr 1, 2016, 11:28:47 PM4/1/16
to Michael Klieman, Ryan Sleevi, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 8:02 PM, Michael Klieman <Michael...@symantec.com> wrote:
Thanks for starting the discussion here. There are both material implementation benefits from eTLD+1 and reasonable approaches to address the concerns you’ve raised.    

Supporting eTLD+1 provides the ability for customers who want to redact the option to do so with today’s implementations — our data shows that the majority of server operators who want to redact at all are doing so with only eTLD+1 to begin with.

Could you explain how you're measuring that? This only represents Symantec customers, correct?

More importantly, can you explain why redaction is important? As indicated, it seems entirely reasonable policy to simply not support it at all. So it's useful to hear - from CAs and their customers - what justifications there are, and how to balance those concerns with the broader ecosystem's.
 
Supporting eTLD+1  will speed up the feasibility of making CT mandatory since it requires no changes to server operators’ infrastructure. The act of starting with eTLD+2 will necessarily slow down CT adoption to account for the time for server operators who require privacy for their internal domains to rename all their private sites — look at how long transitioning to 2048 or SHA2 is taking… starting with eTLD+1 completely eliminates the dependency on server operators and enables us to create a practical, immediately implementable (and enforceable) policy.

While I promise I'm not intentionally trying to pick on you, but since you brought it up yourself, it's worth noting that every CA was able to successfully transition their customers to RSA-2048 and to SHA-2 - except, it would seem, Symantec. It's useful to have this perspective and understand the context, just as it's similarly useful to hear from other CAs - many who are logging all of their certificates today without any redaction at all.
 
The rationale for eTLD+2 seems to be centered on minimizing false alarms.

Not entirely; I think it's important to not lose sight of the concerns of eTLD+2 in the broader perspective, which is a fundamental question of whether such redaction of publicly trusted certificates is a good idea, and the necessary trade-offs between the intersection of relying parties, monitors, site operators, and CAs.

- A policy of eTLD+2 unquestionably favors less transparency, and thus favors CAs, and admittedly requires some change on the site's part (for those who redact), but benefits sites that don't wish to redact, monitors and relying parties.
- A policy of eTLD+1 favors even less transparency, provides greater benefit to the sites that do wish to redact, and causes greater harm to those that don't.
- A policy of no redaction unless CAA present favors greater transparency, provides the functionality to sites that do want to redact, causes no harm to those that don't want to redact, and causes greater effort for CAs and sites that do redact.
- A policy of redaction unless CAA present saying no redaction favors less transparency, provides the functionality to sites that do wish to redact, but causes harm to those that don't want to redact.
- A policy of no redaction at all provides no benefits to those that do wish to redact, nor to their CAs, but causes no harm that sites that don't want to redact, and provides greater benefits to monitors and relying parties. For that matter, it COULD provide greater benefit to users, by providing Monitors and Auditors the tools to examine CT logs for suspicious/phishy domain names and react appropriately (notifying domain registrar, notifying SmartScreen/SafeBrowsing, etc). This would be one of the few times a certificate actually reduced the risk of phishing, even!

I want to make sure I concretely understand your proposal, and what tradeoffs you're asking the various stakeholders to make.
 
There are two cases of false alarms that are being discussed:

1. Where server operators individually manage www, mail, cdn and where these server operators monitor individually (if the domain is monitored centrally, eTLD+1 is preferable for server operators and info sec team because it requires less support). It is still possible to minimize false alarms for the individuals in this case, as previously suggested, by requiring CA’s to enable customers the ability to set the level at which they redact. With this requirement, if alarms are triggered for legitimate certificates, it will only be because internal enterprise policy on the acceptable level of redaction wasn’t followed… and those alarms are OK — they will force either no redaction or following of enterprise policy (which can include differences like info sec monitoring results for all of ?.example.com and their CDN monitoring only ?.cdn.example.com).

I'm unclear what you're advocating here.

I can't tell if you're suggesting CAA policy to restrict redaction, or CAA policy to permit redaction, and I'm not sure what you suggest as the means or consequences for a failure of a CA to abide by either.

I see several possible interpretations, so I want to make sure:

1) No redaction unless CAA records present; if present, acceptable to eTLD+1
2) Redaction permissible at any time, unless CAA record present; when redacting, acceptable to eTLD+1

2. The case of truly bad false alarms would occur only where a CA independently over-redacts. Our expectation is that full logging (no redaction) MUST BE the default implementation for all CA’s, something that (along with allowing customers redaction level flexibility) could be formalized as part of the baseline requirements.

Part of my confusion above is trying to understand how to quantify what customers redaction level flexibility is. I'm uncertain if you're suggesting that the CA simply provides a checkbox to "redact", or if you're embracing the suggestions provided on the thread so far, which include objective and quantifiable means for a site to opt-in to redaction.
 
With these two requirements accompanying eTLD+1, we can solve for false alarms, require nothing new from server operators, and create an approach that can move the industry far more quickly to universal support for CT.  

I don't "require nothing new from server operators" is an objective positive, since we've got multiple parties involved - relying parties, sites that wish for no redaction, sites that wish for full redaction, monitors, and CAs. I think we want to make sure to quantify the benefits - and risks - to all parties involved of redaction.

Sanjay Modi

unread,
Apr 2, 2016, 12:02:07 AM4/2/16
to Certificate Transparency Policy, sanja...@symantec.com, rsl...@chromium.org


On Friday, April 1, 2016 at 4:57:37 PM UTC-7, Ryan Sleevi wrote:


On Fri, Apr 1, 2016 at 4:51 PM, Sanjay Modi <sanja...@symantec.com> wrote:
Majority of the domains where our customers chose to preserve privacy by opting out of CT logging fall under “secret.example.com” pattern – effective TLD + 2 labels. Large enterprise customers have expressed their strong desire to keep their internal domain names private.  Permitting redaction up to the level of effective TLD - plus two labels will force many enterprises to change their internal network setup to add one more label to their domain names so that they can preserve the needed privacy.

That's correct, and as explained, that would be intentional/desirable.

Many enterprises register  specific domains entirely for internal usage. Except eTLD+1 no subdomain is visible on the internet.  
While this usage is perfectly legitimate today the eTLD+2 policy will require enterprises not only change their internal domain name policies but also internal applications and tools that use these domain names. The amount of change require here to preserve privacy will require large enterprises more time to fully adopt CT. 
 
 
There can be two options to preserve the privacy as well as give needed control to domain operators:
  1. Permit redaction up to the level of effective TLD - plus one label.
  2. Permit redaction up to the level of effective TLD - plus one label or allow domain operators to specify level of redaction for their domain.
Given the previous explanation of concerns with eTLD+1 earlier on the thread, could you explain if anything was missed in the considerations thus far? Overall, this does not feel appropriate as a blanket policy, as I explained already, and even less so compared to eTLD+2.


The concern expressed with eTLD+1 is where different domain operators operate sub domains such as mail.example.com and www.example.com. This can be addressed by #2 where example.com can set a redaction policy of eTLD+2 so that monitoring certificate issuance for mail.example.com and www.example.com is not impacted.
This concern can also be addressed by preventive approach like CAA (independent of CT) by specifying authorized CA for each sub domain

Andrew Ayer

unread,
Apr 2, 2016, 12:08:39 AM4/2/16
to Certificate Transparency Policy
I'm confused why certificates issued prior to June 1 are an issue - since
Symantec is not required to log such certificates, they can simply not
log the certs which they would otherwise redact. As for the certificates
issued after June 1 but prior to RFC 6962-bis-compliant logs, how would
label redaction work technically? I suppose there's nothing stopping a CA
from logging a pre-cert with "?" labels, but would clients and auditors
be expected to understand redaction despite talking with pre-bis logs
and using pre-bis data structures?

That bit of confusion aside, I do understand how the CAA record approach
would take longer to put in place than the other proposed options.
However, if the CAA record approach is considered desirable, I think it
would be a shame to pass over it because of the impending Symantec
deadline. Instead, I think it would be better to wait and do one of the
following in the interim:

a. Option 1 (no name redaction allowed).

b. Option 3 (eTLD + 2), but only for Symantec, and with an explicit
sunset date, after which this policy would replaced with a general
policy on name redaction. I don't think limiting this policy to
Symantec would be inappropriate: it's only temporary, Symantec is
currently the only CA required to log non-EV certs, and there's going
to be special-casing in the client (really only Chromium at this point)
for Symantec anyways.

Basically, I don't think the decision on a long-term, general name
redaction policy should be rushed or influenced because of
Symantec's June 1 deadline.

Regards,
Andrew

Ryan Sleevi

unread,
Apr 2, 2016, 1:14:03 AM4/2/16
to Sanjay Modi, Certificate Transparency Policy, Ryan Sleevi
On Fri, Apr 1, 2016 at 9:02 PM, Sanjay Modi <sanja...@symantec.com> wrote:


On Friday, April 1, 2016 at 4:57:37 PM UTC-7, Ryan Sleevi wrote:
That's correct, and as explained, that would be intentional/desirable.

Many enterprises register  specific domains entirely for internal usage. Except eTLD+1 no subdomain is visible on the internet.  
While this usage is perfectly legitimate today the eTLD+2 policy will require enterprises not only change their internal domain name policies but also internal applications and tools that use these domain names. The amount of change require here to preserve privacy will require large enterprises more time to fully adopt CT. 

As explained previously, there is a trade-off between constituencies here, and we're trying to seek the right balance. We're equally trying to understand the use cases for redaction, and their relevance.

This is especially relevant for certificates interoperating with the public PKI, as the practices of these certificates intended for internal uses do have consequences on the ability of the overall ecosystem to move and improve. The issues of MD5, SHA-1, and RSA-1024 all reflect that.

As I mentioned elsewhere on the thread, part of the goal is understanding what the long-term ecosystem should look like, and working back to understanding what the intermediate steps are. Certainly, I think part of that vision would be that cases that are not related to the Web PKI - such as the payment processing case given for SHA-1 - do not issue from the same set of roots used for global issuance, due to the impedence mismatches in the ability to affect change.

Redaction has a similar challenge, and thus it is important to understand the variety of perspectives with redaction, and their use case. For example, if the short-term need for redaction is for a use-case that is better suited by alternative means long-term, then that's incredibly relevant to the discussion.

In this case, the eTLD+2 case, it suggests that though the domain holder (example.com) may wish eTLD+1, the risks of blanketly allowing a policy of eTLD+1 is too great a risk to the overall ecosystem. As such, a modicum of individual self-determinism is traded to balance out the collective ecosystem risks.
 
The concern expressed with eTLD+1 is where different domain operators operate sub domains such as mail.example.com and www.example.com. This can be addressed by #2 where example.com can set a redaction policy of eTLD+2 so that monitoring certificate issuance for mail.example.com and www.example.com is not impacted.
This concern can also be addressed by preventive approach like CAA (independent of CT) by specifying authorized CA for each sub domain

While I appreciate the remarks about CAA, I will note that it does not provide an effective guard against misissuance at present, precisely because of CA's opposition towards respecting it. 

For example, the CPS for Thawte ( https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.15.pdf ), Section 4.2.4, does not provide relying parties with:

1) Knowledge of what CAA records to configure (for example, should it be "symantec.com", "thawte.com", or something else)
2) Knowledge about what Symantec will do if they encounter a CAA record.

So that it's clear I'm not just picking on Symantec, consider the CPS of Entrust ( https://www.entrust.com/wp-content/uploads/2016/03/SSL-CPS-English-20160307-Version-2-14.pdf ), Section 4.1.1, which states "If a CAA record exists that does not list Entrust as an authorized CA, an RA will verify the use of the domain name despite the CAA record" - in effect, that they will not observe or respect CAA records.

This is why the current CAA properties (issue and issuewild) are wholly insufficient as a defense against missussance, unless and until CAs are obligated to respect them, and to allow no overrides.

This is part of why Andrew Ayer proposed the introduction of a new property, with a corresponding obligation that despite the obstructionism of CAs regarding the "issue" and "issuewild" properties, they MUST respect this new property to redact. This provides meaningful control for a domain holder, and a positive (public) declaration of such policies.

Of course, what this property is, and how it should work, remains to be specified, but the broad outline is there.


Ryan Sleevi

unread,
Apr 2, 2016, 1:27:33 AM4/2/16
to Andrew Ayer, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 9:06 PM, Andrew Ayer <ag...@andrewayer.name> wrote:
I'm confused why certificates issued prior to June 1 are an issue - since
Symantec is not required to log such certificates, they can simply not
log the certs which they would otherwise redact. 

As noted in https://security.googleblog.com/2015/10/sustaining-digital-certificate-security.html , as of June 1st 2016, all certificates issued by Symantec itself will be required to support Certificate Transparency; that is, be logged.

After June 1, 2016, certificates newly issued by Symantec that do not conform to the Chromium Certificate Transparency policy may result in interstitials or errors - that is, be presented with conforming SCTs. 
 
As for the certificates
issued after June 1 but prior to RFC 6962-bis-compliant logs, how would
label redaction work technically?  I suppose there's nothing stopping a CA
from logging a pre-cert with "?" labels, but would clients and auditors
be expected to understand redaction despite talking with pre-bis logs
and using pre-bis data structures?

Purely on a technical level, one can log a redacted precertificate to existing (non-bis) logs, in as much as redaction is defined as a series of X.509v3 extensions, rather than an intrinsic protocol exchange of the log. Clients which do not understand these extensions will reject (as the precertificate will not match the certificate). Monitors which encounter these precertificates will encounter an unknown non-critical extension, as well as a series of non-BR conforming domain labels (as ? is not valid).

While that is one option, we're seeking input from the community to better inform what decisions are in the broader Internet's interests, with respect to post-June 1, pre-6962-bis issuance.
 
That bit of confusion aside, I do understand how the CAA record approach
would take longer to put in place than the other proposed options. 
However, if the CAA record approach is considered desirable, I think it
would be a shame to pass over it because of the impending Symantec
deadline.

I didn't mean to give the impression that was at all on the table. No, we want to make sure policies are robust and scalable, but we also wanted to set an expectation about a reasonable time for discussion; that is, rather than wait 2 years to see if anyone else has any thoughts. If the discussion needs more time, or more time is needed to explore technical options, I think that's entirely viable.

Separately, there's two timelines - deciding on the principles/goals, and deciding on the best technical means to achieve. We truly want to allow time for the technical means to reach an acceptable level of maturity, while also wanting to work with the community to figure out what the vision is, in the event there needs to be interim, time-limited solutions that, while consistent with those goals, may be less elegant or complete.
 
Instead, I think it would be better to wait and do one of the
following in the interim:

a. Option 1 (no name redaction allowed).

b. Option 3 (eTLD + 2), but only for Symantec, and with an explicit
sunset date, after which this policy would replaced with a general
policy on name redaction.  I don't think limiting this policy to
Symantec would be inappropriate: it's only temporary, Symantec is
currently the only CA required to log non-EV certs, and there's going
to be special-casing in the client (really only Chromium at this point)
for Symantec anyways.

Thanks. This is very useful and valuable feedback.
 
Basically, I don't think the decision on a long-term, general name
redaction policy should be rushed or influenced because of
Symantec's June 1 deadline.

To reiterate: I wholly agree, and I did not want to give the impression that it was or would be. 

Michael Klieman

unread,
Apr 2, 2016, 2:10:17 AM4/2/16
to rsl...@chromium.org, Certificate Transparency Policy


On Apr 1, 2016, at 8:28 PM, Ryan Sleevi <rsl...@chromium.org> wrote:



On Fri, Apr 1, 2016 at 8:02 PM, Michael Klieman <Michael...@symantec.com> wrote:
Thanks for starting the discussion here. There are both material implementation benefits from eTLD+1 and reasonable approaches to address the concerns you’ve raised.    

Supporting eTLD+1 provides the ability for customers who want to redact the option to do so with today’s implementations — our data shows that the majority of server operators who want to redact at all are doing so with only eTLD+1 to begin with.

Could you explain how you're measuring that? This only represents Symantec customers, correct?

Measured by examining current behavior of customers for whom CT logging happens by default but where the customer still chooses to not log.

More importantly, can you explain why redaction is important? As indicated, it seems entirely reasonable policy to simply not support it at all. So it's useful to hear - from CAs and their customers - what justifications there are, and how to balance those concerns with the broader ecosystem's.

It is commonplace for server operators to use certificates from the same publicly trusted roots for both internal and external sites. That is often due to enterprise policy, simplicity in management, and lower likelihood of errors where the same process is used everywhere. From a naming convention, organizations often have naming conventions which are considered private. Further, name redaction is contemplated in 6962-bis specifically because of the recognition that the privacy requirements of customers are an important part of expanding CT adoption.

 
Supporting eTLD+1  will speed up the feasibility of making CT mandatory since it requires no changes to server operators’ infrastructure. The act of starting with eTLD+2 will necessarily slow down CT adoption to account for the time for server operators who require privacy for their internal domains to rename all their private sites — look at how long transitioning to 2048 or SHA2 is taking… starting with eTLD+1 completely eliminates the dependency on server operators and enables us to create a practical, immediately implementable (and enforceable) policy.

While I promise I'm not intentionally trying to pick on you, but since you brought it up yourself, it's worth noting that every CA was able to successfully transition their customers to RSA-2048 and to SHA-2 - except, it would seem, Symantec. It's useful to have this perspective and understand the context, just as it's similarly useful to hear from other CAs - many who are logging all of their certificates today without any redaction at all.

These transitions have in each case been slower than anyone would like due to the long transitions required particularly in enterprise settings. As for use cases, the many large and complex organizations we serve regularly have the scenarios I describe above.


 
The rationale for eTLD+2 seems to be centered on minimizing false alarms.

Not entirely; I think it's important to not lose sight of the concerns of eTLD+2 in the broader perspective, which is a fundamental question of whether such redaction of publicly trusted certificates is a good idea, and the necessary trade-offs between the intersection of relying parties, monitors, site operators, and CAs.

- A policy of eTLD+2 unquestionably favors less transparency, and thus favors CAs, and admittedly requires some change on the site's part (for those who redact), but benefits sites that don't wish to redact, monitors and relying parties.

To be clear, I am advocating on behalf of the privacy considerations needed by customers -- but on a case by case basis. This doesn't benefit us or other CAs. Redaction addresses the real world cases that get in the way of faster widespread adoption of CT.  eTLD+1 is no worse for a site that doesn't want to redact while eTLD+2 is clearly worse for a site that does. Redaction at any level does not make a difference for relying parties since the client is verifying the existence of a valid SCT. Nor does redaction at any level impact monitors... Only a site owner can monitor use of its own domain and the act of redacting necessarily requires a smarter monitor at any level of redaction.

- A policy of eTLD+1 favors even less transparency, provides greater benefit to the sites that do wish to redact, and causes greater harm to those that don't.

The only one for whom there is "less transparency" is the site operator who specifically wants the balance between privacy and the monitoring benefits. Per below, eTLD+1 doesn't prevent someone from choosing a more restricted level of redaction if desired.

- A policy of no redaction unless CAA present favors greater transparency, provides the functionality to sites that do want to redact, causes no harm to those that don't want to redact, and causes greater effort for CAs and sites that do redact.

Agreed. As you know we support mandatory CAA checking by all CAs and think that CAA and CT together can be a powerful combo of both prevention and detection. That said, the notion of requiring CAA for an org that wants to redact seems overly prescriptive. 

- A policy of redaction unless CAA present saying no redaction favors less transparency, provides the functionality to sites that do wish to redact, but causes harm to those that don't want to redact.

Agreed. Again, we would advocate for MUST log by default for all CAs. We're not trying to promote redaction but make it available for customers who want privacy for their domains... and not create a technical burden to get that privacy.

- A policy of no redaction at all provides no benefits to those that do wish to redact, nor to their CAs, but causes no harm that sites that don't want to redact, and provides greater benefits to monitors and relying parties. For that matter, it COULD provide greater benefit to users, by providing Monitors and Auditors the tools to examine CT logs for suspicious/phishy domain names and react appropriately (notifying domain registrar, notifying SmartScreen/SafeBrowsing, etc). This would be one of the few times a certificate actually reduced the risk of phishing, even!

The issue here is handling those benefits for public sites vs. the needs for private sites (where most of these benefits don't apply). While I certainly like the idea of better phishing protection, getting CT adopted everywhere to enable orgs to monitor their domains to detect misissuance should be the primary objective... redaction support that's easy to implement will help achieve that. 


I want to make sure I concretely understand your proposal, and what tradeoffs you're asking the various stakeholders to make.
 
There are two cases of false alarms that are being discussed:

1. Where server operators individually manage www, mail, cdn and where these server operators monitor individually (if the domain is monitored centrally, eTLD+1 is preferable for server operators and info sec team because it requires less support). It is still possible to minimize false alarms for the individuals in this case, as previously suggested, by requiring CA’s to enable customers the ability to set the level at which they redact. With this requirement, if alarms are triggered for legitimate certificates, it will only be because internal enterprise policy on the acceptable level of redaction wasn’t followed… and those alarms are OK — they will force either no redaction or following of enterprise policy (which can include differences like info sec monitoring results for all of ?.example.com and their CDN monitoring only ?.cdn.example.com).

I'm unclear what you're advocating here.

I can't tell if you're suggesting CAA policy to restrict redaction, or CAA policy to permit redaction, and I'm not sure what you suggest as the means or consequences for a failure of a CA to abide by either.

Not suggesting a CAA requirement at all as part of CT redaction. Just eTLD+1 along with a BR requirement to log by default and provide customers the ability to choose the level of any desired redaction.

I see several possible interpretations, so I want to make sure:

1) No redaction unless CAA records present; if present, acceptable to eTLD+1
2) Redaction permissible at any time, unless CAA record present; when redacting, acceptable to eTLD+1

2. The case of truly bad false alarms would occur only where a CA independently over-redacts. Our expectation is that full logging (no redaction) MUST BE the default implementation for all CA’s, something that (along with allowing customers redaction level flexibility) could be formalized as part of the baseline requirements.

Part of my confusion above is trying to understand how to quantify what customers redaction level flexibility is. I'm uncertain if you're suggesting that the CA simply provides a checkbox to "redact", or if you're embracing the suggestions provided on the thread so far, which include objective and quantifiable means for a site to opt-in to redaction.

I mean redaction can start at eTLD+1, but that customers be given the ability to redact at any level they choose.

 
With these two requirements accompanying eTLD+1, we can solve for false alarms, require nothing new from server operators, and create an approach that can move the industry far more quickly to universal support for CT.  

I don't "require nothing new from server operators" is an objective positive, since we've got multiple parties involved - relying parties, sites that wish for no redaction, sites that wish for full redaction, monitors, and CAs. I think we want to make sure to quantify the benefits - and risks - to all parties involved of redaction.

Yes... and looking at the various stakeholders, the party that is impacted by the redaction policy is limited to an org that chooses to redact its own information. 

Ryan Sleevi

unread,
Apr 2, 2016, 2:54:26 AM4/2/16
to Michael Klieman, rsl...@chromium.org, Certificate Transparency Policy
On Fri, Apr 1, 2016 at 11:10 PM, Michael Klieman <Michael...@symantec.com> wrote:
Redaction addresses the real world cases that get in the way of faster widespread adoption of CT. eTLD+1 is no worse for a site that doesn't want to redact while eTLD+2 is clearly worse for a site that does.

I would disagree, especially with what you've put forward as the proposal (opt-out, rather than opt-in).

If I purchase "example.com", for example, and I see a number of certificates in CT logs for "?.example.com", I have no idea whether these are pre-existing certificates for "www.example.com" or whether it was for "ryansleeviisbeingapain.example.com" - the latter being a subdomain I'd be much less likely to personally use than the former.

While the suggestion would be that, as the new holder, I should go and ask the CA to revoke those certificates, it's well understood that revocation doesn't work, especially in the presence of an attacker. Here, the availability of adequate information, as the new holder, allows me to make informed security decisions as appropriate the risk.

Now, the above works both as a fundamental argument against redaction at all, but shows how there can be a material difference between eTLD+1 vs eTLD+2. If, as the new holder, there is a wide corpus of ?.internal.example.com certificates, I might choose, as the domain holder, to set up my infrastructure as ?.corp.example.com, for which there are no such certificates.

It would certainly be possible to address this issue by suggesting that, at any point in time, a domain holder may request the full and public disclosure of any redacted certificates for their domain, within a minimum timeframe, but now that becomes a more nuanced policy, with tradeoffs. And that may be a viable solution to the problem I outlined, but I do want to underscore that the problem itself does show that there are cases where eTLD+1 is demonstrably worse than eTLD+2, and why this is an important thing to "get right".
 
Nor does redaction at any level impact monitors... Only a site owner can monitor use of its own domain and the act of redacting necessarily requires a smarter monitor at any level of redaction.
Here again, I think we disagree. Anyone can monitor a domain; only a site owner can determine misissuance.

This is a very powerful and important distinction, and goes back to the previous example I provided. Researchers in the community, whether they be researchers at large Internet organizations', academics, or market analysts, and examine the CT database and examine for aberrations and anomalies, and from there, contact the site operator for further clarification and context, indicating the potential of misissuance. A certificate such as ?.example.com provides too little signal to noise to make such a statement, while a certificate of ?.internal.example.com provides significant signal.

Redaction, whether at eTLD+1 or eTLD+2 (or really, any blanket redaction policy or opt-out policy), removes the ability to monitor CT for specific hosts by default, thus providing less ability for monitors to assist sites - they would have to monitor (at a full eTLD+1 level) if there is any redaction occurring.

- A policy of redaction unless CAA present saying no redaction favors less transparency, provides the functionality to sites that do wish to redact, but causes harm to those that don't want to redact.

Agreed. Again, we would advocate for MUST log by default for all CAs. We're not trying to promote redaction but make it available for customers who want privacy for their domains... and not create a technical burden to get that privacy.

The problem with this is that it places full trust in the CA to do the right thing, or that auditors will measure. I do hope you can understand why I have a hard time with this, and why I have trouble seeing how this could strike the right balance.

For example, one could successfully argue, using the criteria you set out, that a CA might 'log by default' - but have a big bright checkbox that says "Please click here to continue and not redact your certificate", along with a tiny link buried in a footnote "Or click here to continue with logging".

One can imagine many scenarios that a CA could game, for example, and while I don't wish to attribute malice to it, as it may simply be a matter of the CA's incentives, it does suggest that such language is both technically and procedurally unenforceable as a MUST.

The net result of this is, of course, less redaction, which I believe is bad for the ecosystem.

Further, consider what the above proposal implicitly states - which is that full redaction is the default, and if you want to be secure, you have to do more work. Unfortunately, that philosophy is very much at odds with how we view things for Chromium. Our goal is to ensure things are secure by default, while recognizing, at times, there may need to be an escape hatch for necessary cases. There's ample evidence of this philosophy, from past efforts such as blocking active mixed content, phasing out NPAPI plugins, requiring affirmative consent for powerful features (and more recently, the use of secure browsing contexts).

This is why the appeal of "No redaction, unless the domain holder has explicitly opted in" is a far more appealing balance. It avoids the risk of procedural misissuance - such as when the user of cdn.example.com chooses to redact the certificate, even though they were not authorized to make that decision (but were authorized to issue the certificate) - which avoids the need or risk of revocation. It sets the right standard that redaction is the exception, rather than the norm, in that it requires technical action.

For those enterprises that require redaction, it provides them a means to achieve it, but it's certainly true that they will need to take an appropriate action to truly indicate that consent. This, in turn, allows them to make a value-based economic decision, which is whether the potential cost (of such a configuration) is worth the potential value of redaction.

Overall, this seems far better overall - for sites by default (which have not thought about redaction), for those that have thought about it, and for those who may be led or coerced by their CA to redact without understanding the implications.
 
The issue here is handling those benefits for public sites vs. the needs for private sites (where most of these benefits don't apply). While I certainly like the idea of better phishing protection, getting CT adopted everywhere to enable orgs to monitor their domains to detect misissuance should be the primary objective... redaction support that's easy to implement will help achieve that. 

This implies that redaction is a hard-blocker. I don't believe it is.

Under a "No redaction" policy, for example, it might be that these sites are untrusted by default. If they truly are for internal purposes, for which they should not be publicly visible, then we can also presume this is an enterprise use case. In which case, the use of enterprise configuration flags (if and only if the user contents, or if the device is owned by the enterprise) might be adequate here, to indicate clients should, for example, ignore the absence of CT information for "internal.corp.com" (or, alternatively, examine an in-house CT log rather than a public CT log).

However, if site is not for internal purposes, and in fact, clients on the Internet at large may be trying to connect to topsecret.example.com, well, then the cat's out of the bag the moment it hits DNS (given no client supporting DNS over TLS yet), and it's a suggestion that even though there is a REQUEST for redaction, there isn't a NEED for it. Instead, the public good from having full disclosure may outweigh the benefits to the domain holder for redaction.
 
Not suggesting a CAA requirement at all as part of CT redaction. Just eTLD+1 along with a BR requirement to log by default and provide customers the ability to choose the level of any desired redaction.

OK, thanks for clarifying. I don't think this will be viable for us to consider, for the reasons outlined over this thread. It leaves too much room for abuse, and places too much trust in the private and hidden practices and activities of entities, for which CT exists precisely because of the need for for transparency and openness.

My hope is that though this is not acceptable, we can work and iterate to find a solution that balances the many complex tradeoffs I've outlined - for which CAA as an opt-out mechanism gets much closer to, it would seem, compared to any of the proposals yet.
 
Yes... and looking at the various stakeholders, the party that is impacted by the redaction policy is limited to an org that chooses to redact its own information. 

As initially explained, and restated here again above, I don't believe this is the case.

Peter Bowen

unread,
Apr 2, 2016, 12:14:34 PM4/2/16