Policy Discussion: Name Redaction

[Ryan Sleevi]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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