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

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

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]

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]

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]

On Fri, Apr 1, 2016 at 11:53 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Fri, Apr 1, 2016 at 11:10 PM, Michael Klieman <Michael...@symantec.com> wrote:
>
> 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.
>

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

I think you have identified a separate but related issue with the
current Baseline Requirements. There is no requirement that a CA
cooperate with a Domain Name Registrant to get information on existing
certificates or to take their concerns into account. I think that it
would be reasonable to require all CAs to 1) provide a copy of the
full issued certificate to those who can show they control the domain,
2) revoke a certificate if requested by the domain registrant (even if
the registrant is not the Subscriber), and 3) allow registrants to
restrict who may successfully apply for a certificate. These are all
missing today and should be resolved.

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

I think it would be good to set a tenet up front: A domain owner
should be not be forced to expose more of their domain configuration
than they otherwise would just because they want security. It would
really bad if someone is having to seriously consider leaving things
unencrypted as a result of certificate policy. Yet that is a very real
possible outcome from this conversation.

It seems there is an expectation of a bright line where such a line
simply does not exist for many scenarios. Split horizon DNS at the
registered domain level is very common. That is where
'www.example.com' is a valid hostname on the public Internet but
'intranet.example.com' is not. However if you connect to the
corporate network both names exist because the resolvers on the
corporate network have different copy of the example.com zone. You
suggest using "enterprise configuration flags" as some sort of
solution, but this completely ignores the reality of Bring Your Own
Device and the limited resources many small and medium size businesses
have for IT. Providing corporate laptops and desktops with standard
OS images (meaning what was received from the hardware vendor) is very
common. Add the fact that, even when they do have central management,
a surprising number of applications do things like carry around their
own trust store. This effectively means that it is necessary to get
certificates containing names not on the public Internet from CAs that
are broadly trusted.

Yes, it would be ideal to have a rule which says "all names in public
certificates must be in public DNS" or maybe a rule that says "public
domains shall only be used for public purposes", but those don't
exist. What we have is a global registry used to deconflict private
namespaces and users who expect that this deconfliction allows
services, including CAs, to simultaneously operate in a private and
global manner. We also have a public namespace where enumeration of
the namespace is explicitly not a design goal. Very few DNS servers
support unauthenticated AXFR these days and NSEC3 was explicitly
developed to help make it harder to enumerate zones. We are not in a
world where the Enterprise Network is air-gapped from the Internet and
where never the twain shall meet. There is privacy in the domain name
system.

Therefore, I think redaction is critical if we are to avoid making
customers decide between privacy and security. There is a single DNS
root (and this is a good thing) so it is reasonable that customers can
expect single trust anchor list that aligns with this rooot. To make
this happen, similar policies need to work for names in certificates
that work for DNS itself. This means the person controlling the
domain namespace needs to be able to choose how much to include in
data accessible on the public Internet, which might be just the
registered domain name.

Thanks,
Peter

[Ryan Sleevi]

On Sat, Apr 2, 2016 at 9:14 AM, Peter Bowen <pzb...@gmail.com> wrote:

I think you have identified a separate but related issue with the
current Baseline Requirements.  There is no requirement that a CA
cooperate with a Domain Name Registrant to get information on existing
certificates or to take their concerns into account.  I think that it
would be reasonable to require all CAs to 1) provide a copy of the
full issued certificate to those who can show they control the domain,
2) revoke a certificate if requested by the domain registrant (even if
the registrant is not the Subscriber), and 3) allow registrants to
restrict who may successfully apply for a certificate.  These are all
missing today and should be resolved.

I think it's fairly deeply related to the discussion we're having, in as much as, in the absence of these things, what are the tradeoffs being asked?

For example, should we allow redaction in the absence of these three (although it would seem the first two are perhaps more relevant)? What are the risks if we do - as a general principal, what are the risks to those who want redaction and those who don't?

That's a big motivation for this discussion - understanding what the balance needs to be struck, and what the dependencies are that need to be met in order to ensure a robust and secure system. Obviously, there's one dependency (of sorts), which is the finalization of RFC 6962-bis; a significant portion is trying to understand what 'the rest' needs to look like.

 

I think it would be good to set a tenet up front: A domain owner
should be not be forced to expose more of their domain configuration
than they otherwise would just because they want security.  It would
really bad if someone is having to seriously consider leaving things
unencrypted as a result of certificate policy. Yet that is a very real
possible outcome from this conversation.

An alternative way to think about it is that in order for there to be public trust, there needs to be some degree of public disclosure.

The challenge is that we want to fully empower and trust domain holders, as they are the domain operators. Whatever policies they set, that's their prerogative. If they want privacy, in an ideal world, it should be there.

At the same time, we don't want to implicitly trust CAs - that's been a significant and repeated challenge in the ecosystem. So we want to find an appropriate technical level that sets an equal playing field and allows for some degree of trust.

So this is where the tension comes from; if name redaction were solely at the hands of the domain holders, I would agree, there's no problem. But name redaction is held instead by third parties, who may or may not be trustworthy to execute the domain holders wishes. That's why we need to explore the balance - what means can we fine that doesn't allow for CAs to act against domain holders wishes. Further, because the actions of a single CA affect all domain holders, how can we ensure that the needs of one domain holder don't negatively affect those of another?

 

Therefore, I think redaction is critical if we are to avoid making
customers decide between privacy and security.  There is a single DNS
root (and this is a good thing) so it is reasonable that customers can
expect single trust anchor list that aligns with this rooot.  To make
this happen, similar policies need to work for names in certificates
that work for DNS itself.  This means the person controlling the
domain namespace needs to be able to choose how much to include in
data accessible on the public Internet, which might be just the
registered domain name.

I totally agree that the person controlling the domain namespace should be able to make decisions about their operation. The problem and challenge is that, in the case of redaction, we don't have just the domain holder in the equation, as we do with say NSEC3 or unauth'd AXFR - we have the CA, who is claiming to represent the wishes of the domain holder. However, we have CT in large part because of CAs' inabilities to represent accurately and completely the wishes of the domain holder, and CT exists to provide a check and balance to ensure that the CA is respecting those wishes.

I'm extremely fond of the "no redaction without CAA" approach, because it provides a means to require that domain holders' wishes are clearly and accurately expressed and it sets the policy expectation which thus ensures that CAs obtain that consent in a consistent manner (e.g. don't mislead the users as to the tradeoffs, which has and does happen). Much like enabling NSEC3, disabling promiscious AXFR, or configuring a split zone, it does require some changes, but not insurmountable, and leaves the control with the domain holder.

So if we set that as an 'end goal' - domain holders empowered with the same privileges they have today, provided appropriate configuration, with CAs needing to be observant to domain holders wishes - what do interim solutions look like, and how much trust do they confer on the CA?

The interim solution is ONLY relevant in the case of Symantec and CNNIC - everything else it would seem we can allow to mature to 6962-bis, and there's no problem, because there's no downsides to not logging. One option is to say there is no interim solution - if you want to avoid logging your name to CT, you should ask your CA not to log to CT. If your CA is one that is expected to log to CT, well, your certificate won't be trusted then. You can always go to another CA, or you can request your certificate be logged, but you can't have redaction and use a CA that is required to be transparent due to a loss of faith in the CA's controls. But that's only an issue if you're obtaining a certificate from Symantec and CNNIC - and is that an appropriate balance of the tradeoffs?

Alternatives, like eTLD+1/eTLD+2, effectively confer a degree of trust upon the CA to do the right thing, and don't set up criteria for how the consent should be obtained. Is this the right balance, on the whole, for the community? I'm not sure. Hence the tradeoffs.

[Richard Salz]

If a domain holder is concerned, monitoring for redacted entries in their domain isn't enough?

[Peter Bowen]

On Sat, Apr 2, 2016 at 11:07 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
> I totally agree that the person controlling the domain namespace should be
> able to make decisions about their operation. The problem and challenge is
> that, in the case of redaction, we don't have just the domain holder in the
> equation, as we do with say NSEC3 or unauth'd AXFR - we have the CA, who is
> claiming to represent the wishes of the domain holder. However, we have CT
> in large part because of CAs' inabilities to represent accurately and
> completely the wishes of the domain holder, and CT exists to provide a check
> and balance to ensure that the CA is respecting those wishes.
>
> I'm extremely fond of the "no redaction without CAA" approach, because it
> provides a means to require that domain holders' wishes are clearly and
> accurately expressed and it sets the policy expectation which thus ensures
> that CAs obtain that consent in a consistent manner (e.g. don't mislead the
> users as to the tradeoffs, which has and does happen). Much like enabling

> NSEC3, disabling promiscuous AXFR, or configuring a split zone, it does

> require some changes, but not insurmountable, and leaves the control with
> the domain holder.
>
> So if we set that as an 'end goal' - domain holders empowered with the same
> privileges they have today, provided appropriate configuration, with CAs
> needing to be observant to domain holders wishes - what do interim solutions
> look like, and how much trust do they confer on the CA?

I agree that placing the policy in DNS is ideal as it allows the
subject of the policy and the policy to live together. And I think
that CAA is the best choice for record type, as it could allow
specifying the redaction policy issuer in addition to or in
alternative to a default policy. However far too many DNS providers
do not yet support CAA records. For example, Google Cloud DNS
(https://cloud.google.com/dns/what-is-cloud-dns#supported_record_types)
and Google Domains (https://support.google.com/domains/answer/3251147)
both do not support CAA. In order to make permission based redaction
work, based on those docs, the policy will need to be encoded in a TXT
record.

The other thing that needs to be considered is what happens to
existing certificates when the policy record changes. The already
existing pre-certificates that relied on the old policy clearly still
exist and were not mis-issued, but an observer viewing the
pre-certificate months later could think they were if comparing for
the policy. So there is still a reliance on the CA to accurately
follow the policy which is hard to verify months later.

Thanks,
Peter

[Ryan Sleevi]

On Apr 2, 2016 1:01 PM, "Richard Salz" <rich...@gmail.com> wrote:
>
> If a domain holder is concerned, monitoring for redacted entries in their domain isn't enough?

It makes a fairly substantial set of tradeoffs in practice, for the reasons outlined in the initial and subsequent messages. The question is whether accepting those tradeoffs (on the whole) is acceptable for the limited benefit of those who would redact.

[Ryan Sleevi]

On Apr 2, 2016 2:03 PM, "Peter Bowen" <pzb...@gmail.com> wrote:
>
> In order to make permission based redaction
> work, based on those docs, the policy will need to be encoded in a TXT
> record.

Let's be clear: When you say "In order for it to work," what you mean is, "In order for it to work without requiring any changes," which is a very different thing. We can certainly make it work with CAA, which would seem the clear and logical place.

If domain services don't support CAA, and you wish for name redaction, you can switch providers/software.

Does that mean more work? Yes, absolutely. But would it work as CAA? Of course.

The argument for avoiding CAA is that services don't support it, and services don't support it because customers don't ask for it, and customers don't ask for it because CAs aren't obligated to respect it, and because it is hard to put a value on security to justify a change. If privacy is of value to these sites, it leads to pressure to support CAA, which improves the entire ecosystem (not just for redaction, but for restricting misissuance)

I appreciate the perspective as to where things stand today, but I don't think that should dissuade us from doing the engineering in a sound way. The same argument you bring up here is no different than the original discussions of CAA vs TXT during CAAs standardization, and I'm not sure the argument has improved? It certainly seems CAA is the sound engineering choice, and the TXT record is only if we want to be lazy?

> The other thing that needs to be considered is what happens to
> existing certificates when the policy record changes.  The already
> existing pre-certificates that relied on the old policy clearly still
> exist and were not mis-issued, but an observer viewing the
> pre-certificate months later could think they were if comparing for
> the policy.  So there is still a reliance on the CA to accurately
> follow the policy which is hard to verify months later.

There's a difference, however, between not being able to verify at all (e.g. eTLD+1 redaction at the CA's discretion, as Michael effectively proposed) and not being able to verify substantially after the fact. This permits continuous monitors making observations (which will happen within one MMD), which is better than nothing.

I suppose if we want to talk about other challenges with this, is the ability of CAs to use previously validated information (up to 39 months old) prior to issuing a certificate. If we accept the CAA method, a CA could observe no redaction restrictions (in the absence = permission Michael advocated), and use that to continue issuing redacted certificates for up to 39 months after - including after the domain has changed ownership, and even after the domain holder has prohibited redaction.

This seems to suggest a policy of opt-in to redaction better favors sites - opting-in can take place immediately, while opting out can take up to 39 months - rather than the opt-out model, where to even opt-out initially it can take 39 months. Of course, an alternative would simply be require the record checked before every certificate is issued - a far safer bet period, but which I anticipate some CAs to oppose, because it means they have to make changes in order to keep users safe.

[Peter Bowen]

On Sat, Apr 2, 2016 at 3:07 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
>
> On Apr 2, 2016 2:03 PM, "Peter Bowen" <pzb...@gmail.com> wrote:
>>
>> In order to make permission based redaction
>> work, based on those docs, the policy will need to be encoded in a TXT
>> record.
>
> Let's be clear: When you say "In order for it to work," what you mean is,
> "In order for it to work without requiring any changes," which is a very
> different thing. We can certainly make it work with CAA, which would seem
> the clear and logical place.

I should been clearer. In order for it to work as the "interim
solution", as you phrased it, CAA records are not viable. CAA records
are more viable if the TXT or CAA records can be used until date X,
after which point only CAA records can be used. Maybe X is the date
that a new RFC is published defining the property that goes in a CAA
record.

Thanks,
Peter

[Ryan Sleevi]

On Apr 2, 2016 3:17 PM, "Peter Bowen" <pzb...@gmail.com> wrote:
>
> I should been clearer.  In order for it to work as the "interim
> solution", as you phrased it, CAA records are not viable.  CAA records
> are more viable if the TXT or CAA records can be used until date X,
> after which point only CAA records can be used.  Maybe X is the date
> that a new RFC is published defining the property that goes in a CAA
> record.

Thanks for clarifying.

I'm not sure I'd agree though, in the case of the interim solution (in which there will still be wide and ample opportunity from a variety of CAs to obtain non-redacted, non-disclosed certificates), that it necessarily requires the TXT solution.

I totally appreciate that the argument in favor of such an approach is that it allows Symantec and CNNIC customers a path to redaction, but it seems like they would already have a rather sizable alternative path available.

My concern, of course, is that introducing yet another timeline or sunset would add more to complexity and confusion, as opposed to there being only one sanctioned way, hopefully technically sound, to do things.

[Peter Bowen]

On Thu, Mar 31, 2016 at 7:19 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> 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".

After some more thought, I think that any rule for redaction needs to
allow for the left most label to be redacted to avoid creating a
perverse incentive that pushes customers to wildcard certificates.
Wildcards already allow "redaction" of the left most label by covering
all possible labels. I would also suggest that it might make sense to
set a rule that wildcard labels (the "*") cannot be redacted, but I'm
not sure if 6962-bis covers that (e.g. *.corp.us.example.com could be
*.?.us.example.com). The only exception should be where the only
unredacted part is an effective TLD, but any rule needs to take into
account the new spec13/.brand gTLDs. If *.google is allowable, then
?.google should also be allowable.

Thanks,
Peter

[Nick Lamb]

On Sunday, 3 April 2016 05:17:43 UTC+1, Peter Bowen wrote:

After some more thought, I think that any rule for redaction needs to
allow for the left most label to be redacted to avoid creating a
perverse incentive that pushes customers to wildcard certificates.
Wildcards already allow "redaction" of the left most label by covering
all possible labels.

Just because a subscriber was able to obtain a certificate for a particular name does not mean they would also have been able (or at least, that they should have been able) to obtain a certificate for a different name in the same domain, nor for a wildcard.

We can see this most obviously for 2LDs today. Facebook getting a certificate for facebook.com doesn't raise an eyebrow, them obtaining one for *.com or for amazon.com should and you've spotted that we shouldn't allow either to be reacted to ?.com

But the same is true further into the domain hierarchy. Maybe Bob really does have authority to get issued staging1.example.com and staging2.example.com, even though they're visible to the outside world, but only Alice ought to be managing www.example.com so she's going to be really unhappy when Bob's team sneakily gets a "test" certificate issued for www.example.com, it's redacted to ?.example.com so that it's not flagged up as a problem and some bozo from Bob's team ends up showing that they've got working private keys for the www.example.com name on their laptop at a conference for which all the PR blowback lands on Alice.

Peter you've argued previously that CT shouldn't impose any additional name exposure beyond that required already by DNS. But there are already TLDs which you can't enumerate. So on that basis you'd actually be arguing for ?.example style redactions. Which in fact you've acknowledged are a step too far. On the other hand, once we accept that CT must impose additional exposures beyond DNS to be effective, why draw the line at 2LDs (or their moral equivalents in .co.uk and similar) ? The same benefit that all registrants in COM get from not redacting to ?.com is also given to registrants in EXAMPLE.COM by not redacting to ?.example.com.

[Adam Langley]

As Peter notes, organisations can already "redact" topsecret.example.com by using a wildcard. So there's no outcome of this discussion that will result in an organisation being unable to keep the label "topsecret" private if they wish.

However, prompting organisations to spread wildcard certs around isn't great.

If we allow redaction above eTLD+1 (i.e. "?.example.com") then we have the issue that the IT dept sees such a cert in the log and has no idea if they should be worried. (In contrast the owner of just testfoo.example.com hopefully wouldn't be able to get a wildcard for *.example.com.)

However, many of these worries arise because the redacted name is something common and generally meaningful, like www, mail, mx, ns, etc. We could attempt to enumerate these names and forbid redaction of these labels.

Adherence to these rules cannot be externally checked unless the resulting cert is publicly visible, but CA auditors with a sample of certificates can check it.

If such an enumeration seems impossible, we could say that the authorisation in DNS (e.g. carried in a CAA record) must contain a public key and that a reacted pre-cert must contain an encrypted blob that contains the real values of the reacted labels. That solves that problem at the costs of complexity: we have to specify the encryption, an X.509 extension, and people have to generate public keys which they'll lose and/or use example keys by mistake.

It doesn't help when one takes over a domain name and thus doesn't know the key and so cannot decrypt the redacted names in old certs.

(The public-key could come from a time-rotating, identity-based encryption scheme, which solves several of the problems but adds a huge one that we need to setup a central IBE authority which vends the private keys after authorisation. That's probably a non-starter.)

It's not possible for audits to confirm that the encrypted names are well formed either unless we include a zero-knowledge proof of correct construction, but that's probably exceeding the implementation ability of CAs.

I dislike the complexity of the "public-key in CAA" option but also dislike the idea that secret names get wildcard certs. A "do not redact" list is messy and needs to be mostly uniform across root programs, but might be the best solution here. (I could also live with eTLD+2 and letting wildcards handle the rest.)

Cheers

AGL

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

Surely all proposals rely on revocation? How else will you deal with an overly-redacted cert, regardless of definition of "overly-redacted"?

 

[Ryan Sleevi]

On Apr 4, 2016 3:37 AM, "Ben Laurie" <be...@google.com> wrote:
>
> Surely all proposals rely on revocation? How else will you deal with an overly-redacted cert, regardless of definition of "overly-redacted"?

You have options such as removing the CA's ability to redact (on a go-forward basis or retroactively), or removing that CA.

What I mean is that relying on the revocation of end-entities, as seemed suggested, is as unacceptable as allowing CAs to issue SHA-1 and expecting browsers to blacklist leaves or intermediates. We want our policies to be such that revocation is both rare and significant, not a core assumption.

[Håvard Molland]

Thanks for raising many good points about private/public IP option.

A quick recap and my personal evaluation:

To variants:

1) Only allow SCTs with redaction on private networks.

2) Like 1, but add a critical "local-only" extension

#1 means that redacted certs on public network would only fail in clients supporting CT, while #2 means that redacted certs would not work in clients not supporting CT (or not supporting at that least the extension). Overall it can result in failures on private networks if public IPs are used internally. Additionally #2 gives problems with client compatibility.

Also, as Nick mentions, changing certificate validation policies based on IP addresses is quite unprecedented in general, and might have some other unforeseen effects.

What seems good about the suggestion (with #2) is that redaction would not (unless I miss something) affect the public network at large. Thus, all problems, both potential security issues caused by redaction, and compatibility issues caused by this policy are limited to private networks (since redacted certs should not exist on public networks).

It makes sense to evaluate this relatively to what other option would be chosen if this suggestion didn't exist.

Compared to Option 1, to not allow redaction at all, it seems better to allow redaction for private networks only. That is, companies may opt to use redaction and risk having to change their system and clients such that they are compatible. If a company cannot make this work, it's like being back to Option 1. They can avoid redaction, or use wild card certificates instead.

Comparing to Option 3 (with or without CAA to control TLD+X) is more difficult as the consequences are very different. It allows private networks to redact TLD+1 domains, with the cost of possible network and compatibility issues. Like above, requiring private networks limits redaction on private networks such that certs for google.other.evil.com will not be seen on the public Internet without being logged. I don't see that TLD+x stops that. However, Option 3 or using CAA records does not seem to cause any network issues, apart from possibly having to rename domains.

On Fri, Apr 1, 2016 at 9:13 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Fri, Apr 1, 2016 at 10:53 AM, Nick Lamb <tiala...@gmail.com> wrote:

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.

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. 

--
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/CACvaWvYB8PD6_dv2%3DvZymPHosTn%3DHHwUsm4ThSU3Z11MKNcHsw%40mail.gmail.com.

[Peter Bowen]

On Thu, Mar 31, 2016 at 7:19 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> 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.

After reviewing the contents of the "private" section of the Public
Suffix List, I think there are arguments for 3b. Notable the Public
Suffix List is designed to set domain boundaries for cookies. While
many of the domain boundaries are also registration boundaries, this
is not universally true. For example, there are a number of blogspot
and s3.amazonaws domains in the private portion of the list; these are
content hosting services, not private registries. Both already have
wildcard certificates, so clearly that method of redaction is
acceptable. As I said in another email, I don't think it is ever
appropriate to tell a domain owner that they can get a wildcard that
covers a name but that they cannot get a non-wildcard with a redacted
precertificate for the same name. So some private names should allow
redaction based on the public public suffix only.

Thanks,
Peter

[Jacob Hoffman-Andrews]

I prefer option 1: No name redaction allowed at all. I think it's the
best balance of interests, given that wildcards and name constrained
subordinates are available.

Redacted precertificates introduce considerable complexity into the CT
ecosystem, and complexity is the enemy of security. Clearly there's a
cost- but who should bear it? Who receives the benefit?

Enterprises that want to use the public Web PKI for their internal
infrastructure benefit. They have access to affordable offerings from
many CAs and easier management of endpoints, while keeping their
internal hostnames secret.

CAs that want to offer name redaction benefit. They can offer an
appealing product to those enterprises.

The public benefits not at all, and bears a cost because CT becomes more
complex and more difficult to enforce.

Enterprises can start using wildcard certificates today with no
infrastructure changes. That does bring a cost in terms of reduced
internal security for the enterprise. But this is balanced by the
benefit they are receiving.

CAs can operate name constrained subordinates for those enterprises,
again with no infrastructure changes for the enterprise. That may bring
a cost to the CA, if they are currently offering name constrained
subordinates as a high-cost premium product, since it reduces the
ability to price segment. However, it also brings a benefit to the CA in
offering a more appealing "private" product to enterprises.

For Let's Encrypt: We've issued 1.5 million publicly trusted DV
certificates, logging all of them voluntarily to CT. We would not
implement redaction of certificates we submit to CT, even if it was
allowed by 6962-bis.

[Ryan Sleevi]

On Mon, Apr 4, 2016 at 10:16 AM, Jacob Hoffman-Andrews <js...@eff.org> wrote:

I prefer option 1: No name redaction allowed at all. I think it's the
best balance of interests, given that wildcards and name constrained
subordinates are available.

Just to clarify: Are you suggesting that a "Must be logged in CT" should not be enforced for name-constrained subordinates?

That is, there are two components:

1) What's an appropriate policy for permitting RFC 6962-bis style redaction (both in the case of opt-in and if/when CT is required for all certificates)

2) What's an appropriate policy for permitting redaction in the interim until RFC 6962-bis (This only applies for those who MUST log prior to the completion of 6962-bis)

While 6962-bis defines how name-constrained subCAs CAN be used for redaction, it doesn't permit redaction intrinsically. That is, a valid policy is to say "You can't use 6962-bis redaction" - especially since the other technical means of redaction (label substitution) has the issues identified.

When I put forward Option 1, my intent was

1) Regardless of technical means being available, no redaction is available

2) No interim policy is permissible

There's certainly been concerns raised regarding 1, by multiple people (Michael, Sanjay, Peter, Adam) - which is that a policy like one means that the only means of redaction is the pseudo-redaction of wildcard certificates. Would this encourage wildcard certificates then? Would this create a riskier system?

However, it seems like you're suggesting some variation, and I'd like to understand that more.

 

CAs can operate name constrained subordinates for those enterprises,
again with no infrastructure changes for the enterprise. That may bring
a cost to the CA, if they are currently offering name constrained
subordinates as a high-cost premium product, since it reduces the
ability to price segment. However, it also brings a benefit to the CA in
offering a more appealing "private" product to enterprises.

See above, because I'm not sure what technical vision you see, for both cases.

[Rob Stradling]

On 01/04/16 17:14, Ryan Sleevi wrote:
> On Fri, Apr 1, 2016 at 5:37 AM, Ben Laurie wrote:
<snip>
> 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.

I'd like to resurrect a previous idea from Peter Bowen for discussion:
http://www.ietf.org/mail-archive/web/trans/current/msg00148.html

The basic idea is to change the construction of the redaction label:
instead of using a "?", the CA would apply a one-way function to the
actual label(s). This would enable different teams of monitors to
determine whether or not a particular redaction label belongs to one of
the actual labels under their control. Result: a reduction in false alarms.

It would be trivial to mount a dictionary attack on obvious labels (e.g.
"www", "mail"), but ISTM that the obvious labels are usually the ones
that won't need to be redacted.

Would folks be happy with permitting eTLD+1 redaction if labels were
redacted in this manner?

(Changing the redaction mechanism would obviously require changes to
6962-bis, which is due to enter WGLC imminently. So let's make this a
quick discussion :-) )

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

[Rob Stradling]

I forgot to mention that adding some salt would help. Perhaps something
like...

redacted_label = hash(actual_label + cert_serial_number).

[Ryan Sleevi]

On Tue, Apr 5, 2016 at 8:56 AM, Rob Stradling <rob.st...@comodo.com> wrote:

On 05/04/16 16:33, Rob Stradling wrote:

I'd like to resurrect a previous idea from Peter Bowen for discussion:
http://www.ietf.org/mail-archive/web/trans/current/msg00148.html

The basic idea is to change the construction of the redaction label:
instead of using a "?", the CA would apply a one-way function to the
actual label(s).  This would enable different teams of monitors to
determine whether or not a particular redaction label belongs to one of
the actual labels under their control.  Result: a reduction in false
alarms.

It would be trivial to mount a dictionary attack on obvious labels (e.g.
"www", "mail"), but ISTM that the obvious labels are usually the ones
that won't need to be redacted.

I forgot to mention that adding some salt would help.  Perhaps something like...

redacted_label = hash(actual_label + cert_serial_number).

I'm assuming you meant PRF(cert_serial_number + actual_label) or MAC(cert_serial_number, actual_label)? If you've got a length-extendable hash, then it doesn't really complicate the dictionary attack (e.g. I could still determine if it's "www" by just precomputing the state for "www" and plugging in the serial).

This seems like a variant of what Adam proposed - it is something "verifiable" embedded in the precert, where if you have knowledge of the thing to expect, you can reverse it, but if you don't, you gain no information. Adam suggested using a public/private key scheme as one option, or IBE, or a zero-knowledge proof scheme. It seems what you've proposed is just another variant of that, but with different crypto.

Is this a fair summary?

[Sanjay Modi]

As described earlier the use cases we heard from our  large enterprise and SMB customers in  financial, technology, and retail industries  are:

1.     Internal websites used by employees using same Web PKI that they would use to access internet

2.     Development, QA, UAT systems that want to use the same consistent standards as production systems for deployment efficiency

3.     Matter of company policy where privacy – internal and customers' – is very important

4.     We generally hear that the same team manages the DNS infrastructure where all subdomains are controlled by the same organization and operator

Allowing name redaction only up to eTLD + 2 labels will require changes in DNS setup for these customers which involves time and cost – particularly looking at June 1 timeline. 

This will also incentivize customers to collapse their DNS hierarchies and use wildcards; and because wildcards are not allowed in EV, customers will be incentivized to move from EV to DV/OV.

As there is still good discussion going on for a balanced redaction policy and until that is finalized we propose:

 

1. Permit redaction up to the level of effective TLD + plus one label with a sunset timeline based on when a public redaction policy (to eTLD+2 or whatever) is finalized.

  

On CAA implementation, Symantec offers customers instructions to configure CAA records through our knowledge base where our customers typically reach out for help. We will also look into your feedback in adding this to CPS, although we’re not aware of any customers that look to our CPS for operational guidance.

[Ryan Sleevi]

On Tue, Apr 5, 2016 at 2:27 PM, Sanjay Modi <sanja...@symantec.com> wrote:

This will also incentivize customers to collapse their DNS hierarchies and use wildcards; and because wildcards are not allowed in EV, customers will be incentivized to move from EV to DV/OV.

I realize you may see this as a downside, but I'm not sure either of these are bad things for the community as a whole.

Switching to wildcards means the site makes a decision to trade the site's security for the site's privacy, as opposed to asking the entire ecosystem to subsidize the site's privacy by sacrificing the ecosystem's security. On the whole, that seems like a better, more aligned incentive system than a blanket allowance.

As for switching from EV to DV/OV, that's a misdirect - Chrome already doesn't allow EV for redaction, so any customer who switches from EV is one who didn't have privacy already.

 

As there is still good discussion going on for a balanced redaction policy and until that is finalized we propose:

 

1. Permit redaction up to the level of effective TLD + plus one label with a sunset timeline based on when a public redaction policy (to eTLD+2 or whatever) is finalized.

I'm not sure that strikes the right balance.

Given redaction is a reduction of information, all things being equal, the bias will be to allow less redaction, not more, unless and until a suitable policy can be found.

[Rob Stradling]

On 05/04/16 21:08, Ryan Sleevi wrote:

Yes. Good point.

> This seems like a variant of what Adam proposed - it is something
> "verifiable" embedded in the precert, where if you have knowledge of the
> thing to expect, you can reverse it, but if you don't, you gain no
> information. Adam suggested using a public/private key scheme as one
> option, or IBE, or a zero-knowledge proof scheme. It seems what you've
> proposed is just another variant of that, but with different crypto.
>
> Is this a fair summary?

Yes, that's a fair summary. (Sorry, I only skim-read most of this
thread whilst on holiday last week; I'd forgotten about Adam's post).

Redaction is only a "best effort" thing. Anyone who encounters the
actual certificate (that is associated with a redacted precert) may
choose to log it. So ISTM that whichever 'something "verifiable"'
variant is simplest (both to understand and to implement) would be the
best way forward, even if it's "less secure" than the more complex variants.

[Peter Bowen]

On Tue, Apr 5, 2016 at 2:43 PM, Ryan Sleevi <rsl...@chromium.org> wrote:
> On Tue, Apr 5, 2016 at 2:27 PM, Sanjay Modi <sanja...@symantec.com wrote:
>>
>> This will also incentivize customers to collapse their DNS hierarchies and
>> use wildcards;
>

> Switching to wildcards means the site makes a decision to trade the site's
> security for the site's privacy, as opposed to asking the entire ecosystem
> to subsidize the site's privacy by sacrificing the ecosystem's security. On
> the whole, that seems like a better, more aligned incentive system than a
> blanket allowance.

I think that this is a decision that sites should not have to make.
Privacy and security are both important and there is a clear path to
supporting both -- allowing redaction of the label that is permitted
to be a wildcard. The argument against such seems to be that there
will be domains where the domain owner will notice the redaction, be
OK with the redaction, but not bother to find out what is behind the
redaction and instead assume all is good. This seems like a tenuous
case at best. The more likely case is that the domain owner notes
that issuer is an unexpected CA or that they don't request their CA do
any redaction yet the precert is redacted.

From my perspective, the threat that CT is attempting to mitigate is
misbehaving CAs. This is an important threat to mitigate but should
not come at the expensive of domain owners ability to have security
for their own certificates and privacy for their zones. There is zero
advantage to having "*.example.com" logged over "?.example.com". They
both give the same amount of data to anyone independent of the domain
owner and CA. But, for the domain owner, wildcards are massive
security tradeoff for many of the same reasons that eTLD+2 was
suggested as the initial policy, so I think any action that drives
customers that direction is a poor decision.

Thanks,
Peter

[Ryan Sleevi]

On Apr 6, 2016 8:07 AM, "Peter Bowen" <pzb...@gmail.com> wrote:
> I think that this is a decision that sites should not have to make.
> Privacy and security are both important and there is a clear path to
> supporting both -- allowing redaction of the label that is permitted
> to be a wildcard.  The argument against such seems to be that there
> will be domains where the domain owner will notice the redaction, be
> OK with the redaction, but not bother to find out what is behind the
> redaction and instead assume all is good.  This seems like a tenuous
> case at best.  The more likely case is that the domain owner notes
> that issuer is an unexpected CA or that they don't request their CA do
> any redaction yet the precert is redacted.

No, there's meaningful differences between redaction and a wildcard. For example, a site can use CAA to restrict the issuance of wildcards today. Even without the broader support if the CA ecosystem, it is certainly sufficient, today, for the transitional needs until the finalization of 6962-bis AND any proposed improvements to the CAA pipeline.

And I don't agree that it's an accurate summary of the issue with redaction - that is, that the site sees it and doesn't bother to find out what's behind it. Rather, if we allow redaction as proposed, *without any other policy changes*, then there's no means to either prevent it or discover what's behind it, but there are those for wildcards.

That's why I think most of the conversation has shifted from being less about the purely technical means, and being also a discussion about what policies are necessary to accompany those technical means, as the tech itself cannot purely solve the issues and tradeoffs.

> From my perspective, the threat that CT is attempting to mitigate is
> misbehaving CAs.  This is an important threat to mitigate but should
> not come at the expensive of domain owners ability to have security
> for their own certificates and privacy for their zones.  There is zero
> advantage to having "*.example.com" logged over "?.example.com". 

See above for why, today, these are meaningfully distinct.

> They
> both give the same amount of data to anyone independent of the domain
> owner and CA.  But, for the domain owner, wildcards are massive
> security tradeoff for many of the same reasons that eTLD+2 was
> suggested as the initial policy, so I think any action that drives
> customers that direction is a poor decision.

It would seem your argument is that there should be no tradeoffs for site operators between privacy and security, and you believe there is no added ecosystem value for transparency as a principle?

I suspect this is where our disagreement lies, but I do want to make sure I understand. 

[Jacob Hoffman-Andrews]

> While 6962-bis defines how name-constrained subCAs CAN be used for
> redaction, it doesn't permit redaction intrinsically. That is, a valid
> policy is to say "You can't use 6962-bis redaction" - especially since
> the other technical means of redaction (label substitution) has the
> issues identified.

This is a good point. I had been taking for granted that the policy plan
was to allow for unlogged certificates issued from a name-constrained
subCA. After re-reading the spec and the conversation, it sounds like
that is on the table too.

My general feeling is to permit the fewest special redaction options
possible. So that would mean wildcards would become the only way to
redact. As I said earlier, I think that puts the security burden in the
right place.

My only hesitation here is about whether a strict "no redaction" policy
would drive more enterprises to use private PKI for their internal
domains, and whether that's a bad thing. The disadvantage of more
enterprises using private PKI is that more employers would develop the
technical ability to intercept non-work browsing traffic from their
employees. The advantage of enterprises moving to private PKI for their
internal domains is that it frees up the public web PKI to work more
transparently in the public interest.

[Eric Mill]

I share Jacob's view. Name redaction isn't worth it, and will lead to a messy technical ecosystem that it will be difficult to undo later.

While the political gain of name redaction is obvious (it will make more CAs and large customers comfortable with CT), the practical gain seems very low for the level of complexity it will add to the spec, to CA software, and to browsers and other clients that incorporate SCTs as part of their validation path.

In addition to the complexity, I think it incentivizes the worst behavior out of enterprises. Though I am *not* representing the position of the US government or GSA in this email, I can say that from my personal experience working for the largest bureaucracy in the history of mankind, I fully expect many enterprise IT shops to just quickly shut hostname disclosure down, vigorously adopt whatever opt-out mechanisms are available to avoid it, and to never think about it again. 

I expect that we'll get all of the downsides of a complicated opt-out name redaction mechanism, with few upsides in terms of better ecosystem data. The only reason this hasn't happened for censys.io (which lets owners opt out), for example, is that very few IT shops of the sort I'm talking about are aware of its existence. (And the one federal agency who I know is aware of censys.io has, in fact, opted out.) 

But as CT expands, and CAs notify customers (and answer questions about opt-out options), IT shops will definitely become aware and take action. And my experience strongly suggests that this will exacerbate the current situation, where each decentralized component blinds the larger organization, in a misguided attempt to blind an abstract adversary who somehow really just needed to know a hostname to start being adverse.

Though I very much understand and respect the idea of domain owners being sovereign over their DNS, and don't think it's this (or any) group's ethical responsibility to take care of unthoughtful enterprises, we are discussing organizational incentives and their likely behavior on this thread. That's why there's an ETLD+2 proposal instead of earlier ETLD+1 proposals, so that we have better defaults. And not allowing name redaction would hardly be the first time that the internet community made a user-focused design decision that forced organizations to expose more of their inner workings than they would otherwise choose.

I really like Ryan's point:

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

Of all the pieces of metadata worth drawing a line in the sand over, and asking the internet PKI to distort itself over, hostnames don't feel like the one. As others have already brought up:

* Wildcard certificates can effectively perform redaction, with a security tradeoff the domain owner is in a position to evaluate, and whose risks are solely absorbed by the domain owner.

* There are many novel ways to detect hostnames used in the wild anyway -- there's reverse DNS, there's DNSSEC domain walking, there's straight zmap over IPv4 (like censys.io), and ways to blend SNI with zmap to poke beyond the default certificates presented by given IPs.  

* And like Ryan said, DNS requests are public, and will be seen by anyone with sufficient access to network logs (a set of actors that seems to grow by the year).

I'm certainly aware that preventing a hostname's practical disclosure is possible with enough effort, especially if it only needs to stay private for a defined period of time. 

But given that there are already mechanisms for organizations to do this, such as wildcards, name redaction could end up mostly being a way for organizations to keep pretending that they are not on the internet, or believing that their perimeter is inviolable. There are places to draw lines, and to develop global infrastructure to support those lines. Misissuance of certificates seems like one of them -- disclosure of hostnames does not.

-- Eric

--
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/5702A16D.5050302%40eff.org.

--

konklone.com | @konklone

[Richard Salz]

I think Jacob raises an important new point.  Will removing redaction drive enterprises to a private CA and therefore expose more people to MITM?  It might be worth it for the global sake, but it should be considered.

[Ryan Sleevi]

On Wed, Apr 6, 2016 at 4:30 PM, Richard Salz <rich...@gmail.com> wrote:

I think Jacob raises an important new point.  Will removing redaction drive enterprises to a private CA and therefore expose more people to MITM?  It might be worth it for the global sake, but it should be considered.

I think to argue that position, you'd need to understand a threat model/use case.

Are these devices consumers have? Or are they enterprise-owned devices?

If they're enterprise-owned devices, they're already exposed to MITM through ample means.

If they're user-owned devices, well, then I think the push by OS manufacturers to reduce the ease of that (via iOS MDM profiles or Android N's changes to trust verification) will serve as the stopgap, and perhaps the only reasonable stop-gap from 'self-inflicted' MITM. 

[Tom Ritter]

On 6 April 2016 at 18:50, Ryan Sleevi <rsl...@chromium.org> wrote:
> If they're enterprise-owned devices, they're already exposed to MITM through
> ample means.

I think there's a difference between "We need to push new software to
all of users devices" and "We need to change this setting on our
firewall right here." (And the number of times I go into an org and
find a not-at-all-secured enterprise root makes me long for the
differentiation of 'this is a MITM cert' and 'This is an internal
domain signing cert'.)

I'm not sure where I stand on redaction right now. I think Jacob
brings up good points about 'who bears the cost' vs 'who gets the
benefit'. And Adam's (hopefully satirical) examples of 'We _could_
solve this with an internet-wide central IBE authority' are what I
take as cues to revisit from step one and start thinking sideways.

The complexity makes me unhappy, but I tend to lean towards 'let
domain owners control redaction' - preference to do so seems to be via
CAA. One thing I'm not sure I saw was how to solve the problem of
"When I issued this certificate, the CAA record said I could redact;
but now it says I can't." In *theory* couldn't one embed a DNSSEC
chain of the CAA record in something (SCT extension most likely?) to
prove correct permission to redact? Requires everyone to have DNSSEC
of course.[0]

The 'hash the redacted label and stick it in an extension' proposal
c/should provide equivalent security to NSEC3.

-tom


[0] Something I think about more and more is DNSSEC Transparency
combined with potentially-unpublished DS records to enable a site
operator to operate their own domain-wide signing 'pki-like thing'.

[Ryan Sleevi]

On Apr 6, 2016 9:05 PM, "Tom Ritter" <t...@ritter.vg> wrote:
>

> The complexity makes me unhappy, but I tend to lean towards 'let
> domain owners control redaction' - preference to do so seems to be via
> CAA.  One thing I'm not sure I saw was how to solve the problem of
> "When I issued this certificate, the CAA record said I could redact;
> but now it says I can't." In *theory* couldn't one embed a DNSSEC
> chain of the CAA record in something (SCT extension most likely?) to
> prove correct permission to redact? Requires everyone to have DNSSEC
> of course.[0]

To be honest, I'm not even sure how much I attach to the post-issuance audit that the CA was following redaction policies; I would ALMOST trust the auditors there. However, that is only true if the default is to deny redaction, unless the CAA record is present. If the default allows redaction, then I don't trust CAs to do the due diligence to check for the existence of the don't redact, nor do I think it helps the ecosystem, as Jacob and Eric have mentioned.

A simpler form of control wouldn't even require the DNSSEC bits - the hypothetical CAA property could include virtually anything as a challenge, and the CA could include that in the precert. If anyone complained about over redaction, the burden would be on the CA to show they followed policies and that the challenge was fresh/correct. Alternatively, the domain holder could just demand the certificate be revealed.

That's why I favor a default deny, with an opt-in. It gives the domain holder control to do private issuance, favors an open ecosystem, and provides a means to correct overredaction without requiring revocation.

[Tom Ritter]

On 6 April 2016 at 23:44, Ryan Sleevi <rsl...@chromium.org> wrote:
>
> On Apr 6, 2016 9:05 PM, "Tom Ritter" <t...@ritter.vg> wrote:
>>
>
>> The complexity makes me unhappy, but I tend to lean towards 'let
>> domain owners control redaction' - preference to do so seems to be via
>> CAA. One thing I'm not sure I saw was how to solve the problem of
>> "When I issued this certificate, the CAA record said I could redact;
>> but now it says I can't." In *theory* couldn't one embed a DNSSEC
>> chain of the CAA record in something (SCT extension most likely?) to
>> prove correct permission to redact? Requires everyone to have DNSSEC
>> of course.[0]
>
> To be honest, I'm not even sure how much I attach to the post-issuance audit
> that the CA was following redaction policies; I would ALMOST trust the
> auditors there. However, that is only true if the default is to deny
> redaction, unless the CAA record is present. If the default allows
> redaction, then I don't trust CAs to do the due diligence to check for the
> existence of the don't redact, nor do I think it helps the ecosystem, as
> Jacob and Eric have mentioned.
>
> A simpler form of control wouldn't even require the DNSSEC bits - the
> hypothetical CAA property could include virtually anything as a challenge,
> and the CA could include that in the precert. If anyone complained about
> over redaction, the burden would be on the CA to show they followed policies
> and that the challenge was fresh/correct. Alternatively, the domain holder
> could just demand the certificate be revealed.

Auditors could only check the policy if it hasn't changed in DNS
though. Consider domain D wants a redacted cert, but doesn't want it
to be a normal policy. They put it in CAA, get a cert, everyone's
happy, then remove the CAA record. Later some auditor comes along and
says "Hey, CA C issued a cert for Domain D that shouldn't be
redacted." The onus is on the CA _and_ the domain to come forward and
say "Oh, no, that's okay." Variations could create a lot of false
positives, to the point that auditors can't effectively police
unpermissioned redactions, so they don't try.

The onus moves to the domains themselves to work with a monitor and do
the checking themselves. I think that's probably okay - the onus is
always on domain owners to look for misissued certs of course. It just
seems unfortunate that we have 85% of the system that could allow
auditors to check correct CA operation for redaction, and we can't get
it to 100%.

-tom

[Ryan Sleevi]

On Wed, Apr 6, 2016 at 10:10 PM, Tom Ritter <t...@ritter.vg> wrote:

Auditors could only check the policy if it hasn't changed in DNS
though. Consider domain D wants a redacted cert, but doesn't want it
to be a normal policy. They put it in CAA, get a cert, everyone's
happy, then remove the CAA record. Later some auditor comes along and
says "Hey, CA C issued a cert for Domain D that shouldn't be
redacted."  The onus is on the CA _and_ the domain to come forward and
say "Oh, no, that's okay."  Variations could create a lot of false
positives, to the point that auditors can't effectively police
unpermissioned redactions, so they don't try.

Yes, but arguably, that's true anyways for most of the domain validation components of issuance. For example, the auditor can't (independently) validate whether or not the CA used an email address from the WHOIS information in the domain (as permitted in Section 3.2.2.4 of the BRs; method 3, although ostensibly method 2 falls into this as well)

It is a valid question as to whether or not this is a 'good' thing, I agree, but it almost seems as if the solution there is... DNS transparency ;)

 

The onus moves to the domains themselves to work with a monitor and do
the checking themselves. I think that's probably okay - the onus is
always on domain owners to look for misissued certs of course. It just
seems unfortunate that we have 85% of the system that could allow
auditors to check correct CA operation for redaction, and we can't get
it to 100%.

Yes indeed.

For what it's worth, and why it doesn't cause me to lose too much sleep, is that I'm also interested in exploring ways for CAA to control the domain authorization methods (as listed in 3.2.2.4) may be validated. I think this is especially important with respect to the ongoing work the CA/B Forum's Validation WG is doing in expanding the 'officially sanctioned' methods of causing issuance (and removing the current method 7, which is, in effect, "Whatever the CA feels is secure enough" - which rarely is).

That is, imagine a policy which said "You must validate all of these domains by using the information provided in WHOIS"? This would help an organization that wanted to prevent misissuance / ensure everything complied with the central security team / had preexisting 'bulk issuance' contracts with CAs always "do the right thing".

In both cases - this for redaction and that for issuance - or for CAA in general - you have the risk that the CA will be accused of misissuance. You have two scenarios here:

1) Subscriber has no CAA record. CA issues certificate that does Y. Subscriber adds CAA record after the fact that says do X. Subscriber accuses CA of misissuance. The burden of proof lies with the CA to show that no such CAA record existed at the time.

2) Subscriber has a CAA record that says does X. CA issues certificate that does Y. Subscriber accuses CA of misissuance. The burden of proof lies with the CA to show that it checked CAA and that the CAA record permitted Y.

With CAA, in general, the power, and assumption of truth, lies with the domain holder, and the CA has to show it was acceptable.

So when I think of a default-deny for redaction, the CA has to show that redaction was permitted, otherwise, it's misissuance. So CAs will be VERY motivated, I would hope, to come up with a scheme that allows them to avoid that hassle and provide the burden of proof.

But the problems here - with redaction controlled via CAA (or any other DNS record) - don't seem unique in the PKI ecosystem, because we already have that problem with CAA (as it is today), and we already have that problem with any form of domain-based proof (such as WHOIS), or for email-based authorization. Heck, even methods like those used by LetsEncrypt (whether the DNS TXT record, TLS SNI, or .well-known), all put the burden of proof on the CA that IF the domain holder challenges the certificate they issued, they have to bear the burden of proof to show due diligence and authorization.

[Matt Palmer]

I don't think lack of redaction will push anyone to move from "we won't
MitM" to "yeah, that sounds like a great idea!". While a lack of redaction
may encourage some people to use private PKI, and some of those people may
do it poorly and open up a cooperating subset of the Internet population to
security risks, I don't think "some people might decide to do dumb things"
is a strong argument in favour of redaction.

For the record, I'm strongly against redaction, as it is contrary to the
fundamental spirit of transparency, and it is also a *massive* increase in
complexity for the specification and implementers, all for a miniscule
benefit to a very small subset of certificate holders. It's just not worth
it.

- Matt

[Ryan Sleevi]

So, it seems like activity has died down on this thread, and I wanted to make sure I accurately captured a summary of the various view points and concerns raised.

It seems there's two dimensions here in the discussion - capturing intent (of the domain holder) to allow redaction, and what the scope of that permissible redaction should be once intent was captured. They're closely related, and in some cases inseparable, but that's not necessarily an intrinsic property.

On the scale of intent, we really have two options - implicit intent (e.g. the CA self-reports that the user requested redaction) or explicit intent (e.g. some technical means for the domain holder to signal their intent). The implicit case is self-obvious; it relies wholly on the CA obtaining consent for redaction, and while we might debate the question about 'default on' vs 'default off', the ability to independently evaluate that is unfortunately not applicable. It can be argued that it has the benefit of supporting a wide variety of means of obtaining consent, namely with respect to how Section 3.2.2.4 of the Baseline Requirements (not simply based on a technical change to the DNS), but has the downside in that it may allow an expansion of the scope of authorization of the applicant (either under Item 7, under the current BRs, or under the proposed changes, which would allow a demonstration of control of a file on a webserver be used as a substitute to speak authoritatively for the entire DNS registration space).

For explicit case, it seems like we've discussed at least two options, but perhaps there are more - TXT records and CAA records. CAA records seem to fit logically and consistently with the topic of discussion here - they reflect a CA's issuance practices, there's an defined algorithm for determining the scope/applicability (including things such as name redirection via CNAME/DNAME). Unfortunately, CAA recordtypes are not widely supported on a number of systems, and a new specification would need to be produced to define how this behaviour should work. TXT records benefit in that they're widely deployable today, but at the cost of needing to define exactly how they should be processed and handled, even though they don't necessarily need a specification.

Also on the dimension of explicit intent is whether the default should be 'allow' or 'deny'. We've heard arguments for both cases - whether redaction should be permissible unless opted out, or forbidden unless opted in. Here, the question as to which should be the default largely depends, it seems, on the perceived value of redaction for security/privacy vs the ecosystem benefits of transparency.

The question of scope is related, but separate, to the question of intent. Scope ranges from not being permissible at all, being permissible for any domain (that may set a record), being permissible at the registerable domain (aka "eTLD+1"), or being permissible at the second level (aka "eTLD+2")

Not permitting redaction at all only partially solves the "intent" problem; it provides a means for people to opt out (everyone is opted out), but no means for a domain holder to opt in, and several have raised concerns about that denying domain holders privileges they already hold.

Permissibility for any domain is likely tightly coupled with the explicit, technical means of consent; that is, a brand TLD (*.google) might want to allow redaction at that level, while you wouldn't necessarily want a gTLD (*.com) to have that same property. There are possibly ways to spec this slightly clearer (for example, the registration policies of the ccTLD), but it does introduce the TLD operator into the threat-model for domain holders. For example, if I have a domain of example.com, but a default-deny redaction policy is used, then I won't have any CAA records for example.com. As such, .com could set a "permit redaction" CAA record on .com, perhaps under legal compulsion by the US government, and thus enable the misissuance of an example.com certificate without my consent.

Redaction at the eTLD+1 would perhaps solve this, because it would only permit redaction of ?.example.com, independent of the means of consent. However, it would also, presumably, prohibit redaction of secretproject.google (or any other .brand TLD). Here, the question of how consent is obtained is critical, judging by the replies, since there are concerns how how to safely allow some redactions.

Redaction at the eTLD+2 largely seems to be a compromise for the 'consent' problem; it replaces the implicit/explicit means of obtaining consent by a technical hurdle, requiring domain holders restructure their domain namespace to indicate consent for redaction. This has the benefit of not requiring the same degree of specification and nuance as the TXT/CAA solution, or of the implicit trust of the implicit means, but at the downside of raising costs to the end user.

Regarding the question of whether to accept redaction at all, the main argument seems to be on the basis that DNS information isn't private. However (and I'm kinda sad no one checked me on this when I put it forward as a strawman), there are active efforts to ensure DNS privacy, such as via DNS-over-TLS. Similarly, using methods like HTTP Alt-Svc and Encrypted SNI (in TLS 1.3), it's conceivable to imagine a world where a domain may not necessarily be leaked to a network observer other than the intended endpoint/trusted parties. If we do not permit any redaction at all, it would seem to be suggesting that such efforts are not worthwhile; alternatively, it may be suggesting that they're not worthwhile yet - but then sets up the hard time on how to judge if and when redaction should be permitted.

There's also the question of what to do in the interim solution, on the way towards a final goal. Here, the question of consent is most critical - can an appropriate means of obtaining consent be specified, in a timely fashion, that balances the various parties concerns - either implicitly or explicitly? If consent is obtainable, in an acceptable way, and with suitable defaults, it would seem that redaction to the eTLD+1 would be acceptable, if redaction is to be permitted at all.

Finally, one last concern that was raised is with respect to the domain holders privileges. It seems like there is at least universal agreement that, for any certificate that is redacted, the present domain holder should be able to obtain an unredacted version from the issuing CA. The failure to present an unredacted version upon request would be a violation of the CA's obligation, and reasonable grounds for taking action, up to and including distrusting that CA. However, it's unclear how that should be specified. For example, consider a CA that exclusively employs Item 7 of Section 3.2.2.4, in which they require their customers to demonstrate authorization for the domain namespace by setting a custom DNS record type that only that CA recognizes (or, for that matter, requires the use of CAA). If the domain holder should determine a certificate for their domain was excessively redacted, would it be reasonable for the CA to demand they demonstrate that control? It's entirely possible that the current domain holder is not the same as the old domain holder (who may have had that technical ability), or that the current domain holder, in lacking the ability to modify their systems with such a custom record type, believes the certificate was misissued (as there was no way for that certificate to have been legitimately authorized by their systems).

Under this threat model, what should be the expectations for CAs that redact, and how they ascertain that an 'unredact request' is authorized? Should they be required to permit authenticating 'unredact requests' using any method of Section 3.2.2.4 of the BRs? Are there concerns with that?

I hope this fully summarizes the discussion to date, and I'm curious if there's any options I've missed, threats raised that weren't captured, or nuances or relationships that are important to consider.

[Eric Mill]

On Tue, Apr 19, 2016 at 6:40 AM, Ryan Sleevi <rsl...@chromium.org> wrote:

Regarding the question of whether to accept redaction at all, the main argument seems to be on the basis that DNS information isn't private. However (and I'm kinda sad no one checked me on this when I put it forward as a strawman), there are active efforts to ensure DNS privacy, such as via DNS-over-TLS. Similarly, using methods like HTTP Alt-Svc and Encrypted SNI (in TLS 1.3), it's conceivable to imagine a world where a domain may not necessarily be leaked to a network observer other than the intended endpoint/trusted parties. If we do not permit any redaction at all, it would seem to be suggesting that such efforts are not worthwhile; alternatively, it may be suggesting that they're not worthwhile yet - but then sets up the hard time on how to judge if and when redaction should be permitted.

Fortunately, these are not in tension. To the extent DNS-over-TLS and Encrypted SNI protect privacy, they are designed to ensure DNS privacy for users, not to protect knowledge of the existence of the services. 

(Perhaps someone has raised the point of protecting the existence of services somewhere, I can't claim to be aware of everything -- but the overwhelming body of discussion and justification I've seen for these efforts are for user protection.)

It is definitely possible to imagine a world with universal CT, no name redaction, and fully confidential hostname interactions per-connection.

-- Eric

[Richard Salz]

It is definitely possible to imagine a world with universal CT, no name redaction, and fully confidential hostname interactions per-connection.

It is also possible to imagine a world where every name and phone number is published.

I don't want to live in *that* world either.  Are you sure you want to live in the first?

[Eric Mill]

They're not equivalent pieces of information, and wildcards already allow an existing redaction mechanism that doesn't involve the complexity of CT-based name redaction and client enforcement.

-- Eric

--

konklone.com | @konklone

[Richard Salz]

To a fairly close approximation they are VERY equivalent: both have a name and a number.  DNS might have more.  Wildcards are a very heavy hammer.  Maybe that's enough, but let's make sure the choice is a conscious one.

Do we know what the 'rules' are for wildcard and specific DNS names?  If a browser has seen www.example.com; will *.example.com going to the same host upset it?

[Ryan Sleevi]

On Tue, Apr 19, 2016 at 9:27 AM, Richard Salz <rich...@gmail.com> wrote:

Do we know what the 'rules' are for wildcard and specific DNS names?  If a browser has seen www.example.com; will *.example.com going to the same host upset it?

I'm not sure I understand the question? I'm not aware of any browser that has any checks with respect to wildcards, beyond:

- How HTTP/2 connection pooling behaves (e.g. a positive behaviour)

- Whether or not the wildcard is set for the "eTLD" (Firefox/Chrome, but not any other browser, and Firefox may still be in a measure-only mode) 

[Matt Palmer]

On Tue, Apr 19, 2016 at 12:03:53PM -0400, Richard Salz wrote:
> > It is definitely possible to imagine a world with universal CT, no name
> > redaction, and fully confidential hostname interactions per-connection.
>
> It is also possible to imagine a world where every name and phone number is
> published.

You mean like in a phone book, and voter registration rolls, and in
innumerable data breaches?

- Matt

--
Ruby's the only language I've ever used that feels like it was designed by a
programmer, and not by a hardware engineer (Java, C, C++), an academic
theorist (Lisp, Haskell, OCaml), or an editor of PC World (Python).
-- William Morgan

[Richard Salz]

> > It is also possible to imagine a world where every name and phone number is
> > published.
>
> You mean like in a phone book, and voter registration rolls, and in
> innumerable data breaches?

Which is a negligible part of the global population and we hate it, so you agree with me. :)

Why can't DNS names be private? Because of a few bad or incompetent parties? Is that the right trade-off to make?

[Matt Palmer]

On Tue, Apr 19, 2016 at 07:27:46PM -0400, Richard Salz wrote:
> > > It is also possible to imagine a world where every name and phone
> number is
> > > published.
> >
> > You mean like in a phone book, and voter registration rolls, and in
> > innumerable data breaches?
>
> Which is a negligible part of the global population and we hate it, so you
> agree with me. :)

WHY DO YOU HATE DEMOCRACY?

> Why can't DNS names be private? Because of a few bad or incompetent
> parties? Is that the right trade-off to make?

DNS names *are* private. Want to keep them that way? Don't use the global
web PKI to secure your private stuff.

- Matt

[Jacob Hoffman-Andrews]

> Wildcards are a very heavy hammer. Maybe that's enough, but let's
make sure the choice is a conscious one.

I think wildcards are the right tradeoff. The usefulness of
participating in the public Web PKI outweighs the detriments. And
enterprises always have the option of using non-wildcard certificates,
at the cost of accepting that some internal hostnames become public.


Another argument against redaction: Until now it's been the case that
anyone can submit any certificate to a CT log, so long as it chains up
to a recognized root. This has been very useful. a researcher is free to
download the Censys.io scans and upload them to a CT log. An individual
is free to record every certificate their browser sees, for later uploading.

If a researcher uploads an unredacted copy of a certificate for
secret.example.com, and that certificate was previously logged in
redacted form, is example.com going to consider that a breach of their
privacy? Right now the implicit assumption in CT is that there is no
expectation of privacy in publicly trusted certificates. Adding an
explicit notion of privacy for some DNS names introduces uncertainty
regarding what kind of certificates are fair game for uploading.

[Matt Palmer]

On Tue, Apr 19, 2016 at 06:10:20PM -0700, Jacob Hoffman-Andrews wrote:
> privacy? Right now the implicit assumption in CT is that there is no
> expectation of privacy in publicly trusted certificates. Adding an
> explicit notion of privacy for some DNS names introduces uncertainty
> regarding what kind of certificates are fair game for uploading.

I'd go further and say that the implicit assumption is in X.509, or the very
concept of "public key certificates". Dragnet scanning for SSL certificates
isn't new, and plenty of systems cough up trusted certs with "interesting"
names without being asked for that name specifically (and that's even
without considering the info leakage of multi-sAN certs).

I like Eric Mill's observation that redaction permits "organizations to keep
pretending that they are not on the internet". The Web PKI is "on the
Internet". If you want to be "on the Internet", and that decision comes
with tradeoffs, one of which is that the names you use will probably, one
way or another, end up public knowledge. Embrace reality, and move on.

Oh, and I just realised I didn't explicitly answer a previous question posed
by Rich Salz:

> Why can't DNS names be private? Because of a few bad or incompetent
> parties? Is that the right trade-off to make?

Yes. Yes, it is the right trade-off to make.

- Matt

--
<FreeFrag> The most secure computer in the world is one not connected to the
internet. Thats why I recommend Telstra ADSL.
-- bash.org/?168859

[Fabrice Gautier]

Two comments on this scenario:

1) Such process would have to be done with intent, rather than be the by product of using a "normal" browser, or such browser risk being accused of violating users privacy.

2) A researcher that has authorized access to such supposedly private servers would likely be violating some kind of agreement by disclosing them. And obviously would not really need CT to perform such disclosure.


This brings me to another question: assuming an entity somehow set up it's own private web PKI infrastructure, which is not leaking information through DNS or otherwise, would Chromium support such private web PKI in any way?

It seems like today, if you exclude the CT bits, Chrome (and other browsers) do work with such a private web PKI as long as such private PKI is anchored by a public CA.
But with CT added to the mix it becomes difficult, it seems.

-- Fabrice

> --
> 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/5716D6FC.2020708%40eff.org.

[Peter Bowen]

On Tue, Apr 19, 2016 at 3:40 AM, Ryan Sleevi <rsl...@chromium.org> wrote:
> For explicit case, it seems like we've discussed at least two options, but
> perhaps there are more - TXT records and CAA records. CAA records seem to
> fit logically and consistently with the topic of discussion here - they
> reflect a CA's issuance practices, there's an defined algorithm for
> determining the scope/applicability (including things such as name
> redirection via CNAME/DNAME). Unfortunately, CAA recordtypes are not widely
> supported on a number of systems, and a new specification would need to be
> produced to define how this behaviour should work. TXT records benefit in
> that they're widely deployable today, but at the cost of needing to define
> exactly how they should be processed and handled, even though they don't
> necessarily need a specification.

[snip]

> I hope this fully summarizes the discussion to date, and I'm curious if
> there's any options I've missed, threats raised that weren't captured, or
> nuances or relationships that are important to consider.

I think you missed one additional item: name constrained CAs. Maybe
it is assumed that because 6962-bis covers this it doesn't need to be
said, but I think certificates issued by a name constrained CA should
not be required to be logged directly. Alternatively a name
constrained CA should be prima facie evidence that redaction is
explicitly permitted for subtrees covered by the constraints.

Thanks,
Peter

[Kane York]

On Tue, Apr 19, 2016 at 9:19 PM Fabrice Gautier <fabrice...@gmail.com> wrote:

On Apr 19, 2016, at 18:10, Jacob Hoffman-Andrews <js...@eff.org> wrote:

>> Wildcards are a very heavy hammer.  Maybe that's enough, but let's
> make sure the choice is a conscious one.
>
> I think wildcards are the right tradeoff. The usefulness of
> participating in the public Web PKI outweighs the detriments. And
> enterprises always have the option of using non-wildcard certificates,
> at the cost of accepting that some internal hostnames become public.
>
>
> Another argument against redaction: Until now it's been the case that
> anyone can submit any certificate to a CT log, so long as it chains up
> to a recognized root. This has been very useful. a researcher is free to
> download the Censys.io scans and upload them to a CT log. An individual
> is free to record every certificate their browser sees, for later uploading.
>
> If a researcher uploads an unredacted copy of a certificate for
> secret.example.com, and that certificate was previously logged in
> redacted form, is example.com going to consider that a breach of their
> privacy? Right now the implicit assumption in CT is that there is no
> expectation of privacy in publicly trusted certificates. Adding an
> explicit notion of privacy for some DNS names introduces uncertainty
> regarding what kind of certificates are fair game for uploading.
>

Two comments on this scenario:

1) Such process would have to be done with intent, rather than be the by product of using a "normal" browser, or such browser risk being accused of violating users privacy.

2) A researcher that has authorized access to such supposedly private servers would likely be violating some kind of agreement by disclosing them. And obviously would not really need CT to perform such disclosure.

I think it's worth bringing up here that the HTTPS Everywhere extension is working on a feature to submit all seen (publicly trusted, no private roots) certificates into CT.

In Chrome, the only way to prevent your users from turning that feature on would be to blacklist the entire extension using Group Policy, but if GP was viable you could just deploy a private root for those names, so I'm going to assume that's not viable.

Under that set of situations, it is impossible to prevent an employee using Chrome on their own device from switching on the feature in the extension and automatically submitting the certificate to a CT log.

 

This brings me to another question: assuming an entity somehow set up it's own private web PKI infrastructure, which is not leaking information through DNS or otherwise, would Chromium support such private web PKI in any way?

It seems like today, if you exclude the CT bits, Chrome (and other browsers) do work with such a private web PKI as long as such private PKI is anchored by a public  CA.
But with CT added to the mix it becomes difficult, it seems.

-- Fabrice


> --
> 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/5716D6FC.2020708%40eff.org.

--

You received this message because you are subscribed to a topic in the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/ct-policy/vsTzv8oNcws/unsubscribe.
To unsubscribe from this group and all its topics, 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/43E6D4E2-5F3A-4B51-9597-03413745B273%40gmail.com.

[Fabrice Gautier]

Yes, but there would be some form of "intent" there for the user to install the extension and enable the feature.

There is indeed nothing one can do to prevent willful disclosure. But there are various things one can do to prevent accidental disclosure, from just explicit policies (i.e.: employees are not allowed to use that extension or that feature of the browser) to actively blocking submissions to CT logs (from within the internal network) or other measure to discourage use of a browser/extension to access internal/private sites. 

If the model is that Chrome only support the public web PKI, I can almost see it leading to a world where Chrome would be the "public internet app" and some other browser (or a special version or mode of Chrome) would be the "private intranet app" with its own set of policies around Trust, CAs, CT...

-- Fabrice

[Ryan Sleevi]

On Tue, Apr 19, 2016 at 2:47 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

I'm not aware of any beyond the normal potential botching of pinning (not sure if you meant to send to the list, but feel free to re-CC)

I mean, yes, that issue can arise if you pinned the leaf, but that's one of the MANY reasons we STRONGLY discourage anyone from ever pinning the leaf. If you're going to change the cert (e.g. to send users in class A to a wildcard, and users in class B to a specific), you have to set your pins appropriately.

Although, arguably, if you have a wildcard, I don't know why you wouldn't always use that for users in class A and B if you're terminating at the same endpoint, but ... I'm not aware of any, you should be ok, unless you intentionally do something stupid (like pin the leaf, or use separate intermediates and only pin one of the intermediates, etc)

On Tue, Apr 19, 2016 at 11:13 AM, Richard Salz <rich...@gmail.com> wrote:

Are there any strange interactions with browser going to www.example.com and cert pinning and seeing a cert for www.example.com at some times, and perhaps at other times seeing *.example.com?  Or perhaps it's www and ww2, for example.

The answer could well be "not aware of any" and/or "probably will be okay" but I think it prudent to ask.

[Ryan Sleevi]

On Tue, Apr 19, 2016 at 9:19 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

It seems like today, if you exclude the CT bits, Chrome (and other browsers) do work with such a private web PKI as long as such private PKI is anchored by a public  CA.
But with CT added to the mix it becomes difficult, it seems.

What gives you that impression? So far, the presumption has been that this only affects publicly trusted certificates; only publicly-trusted certificates have global interest and significant, only publicly trusted certificates can be logged to publicly trusted logs (implicitly now, although that policy still needs to be formally codified). So even in a CT world, such systems would work, simply without logging. 

[Ryan Sleevi]

On Tue, Apr 19, 2016 at 9:37 PM, Peter Bowen <pzb...@gmail.com> wrote:

I think you missed one additional item: name constrained CAs.  Maybe
it is assumed that because 6962-bis covers this it doesn't need to be
said, but I think certificates issued by a name constrained CA should
not be required to be logged directly.  Alternatively a name
constrained CA should be prima facie evidence that redaction is
explicitly permitted for subtrees covered by the constraints.

Thanks Peter, I did indeed forget to include that dimension.

I wasn't assuming 6962-bis covers it; I think it speaks to the policy as to whether such certificates will be exempt from needing to be logging. Right now, Chrome makes no distinction for technically constrained sub-CAs, and at least, with the BRs as written, technically constrained sub-CAs still need to adhere to the Baseline Requirements (with the 3% audit performed by the issuing CA)

So I think even with my accidental omission, it still seems to fit in the framework that I discussed. I agree that it could argue for permission of redaction (unless such a TCSC was misissued...) 

[Ryan Sleevi]

On Tue, Apr 19, 2016 at 9:19 PM, Fabrice Gautier <fabrice...@gmail.com> wrote:

1) Such process would have to be done with intent, rather than be the by product of using a "normal" browser, or such browser risk being accused of violating users privacy.

While I can understand that position, it's only a violation of user's privacy if there's a reasonably statistically significant proof that a user visited the site. You can imagine that if gossip (of SCTs) is possible to be done in a privacy preserving manner, then gossip (of publicly trusted certificates) should be similarly accomplishable. 

[Peter Bowen]

Ryan,

I am a little confused and concerned when it comes to understanding
how Chrome views 6962-bis. Today Chrome implements RFC 6962 and has
qualified logs that follow 6962. My expectation is that, once
6962-bis is published, most 6962 logs will shutdown and be replaced
with 6962-bis compliant logs (or the existing logs will do some
transition to -bis). I also assume that Chrome will adopt -bis.

6962-bis right now is fairly clear on how redaction works and has a
whole section (https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14#section-4.3)
on name constrained subordinate CAs. In the client section of -bis it
says "the TLS client MUST attempt to validate it against the server
certificate and against each of the zero or more suitable
name-constrained intermediates (Section 4.3)".

If you feel that Chrome is not going to be able to follow the 6962-bis
as written, then I would strongly suggest that you raise this in the
IETF TRANS group sooner than later. I would hate to see an early and
high profile client implementation fail to follow the standard.

Thanks,
Peter

[Fabrice Gautier]

My point: If Chrome only trusts certs from public CAs that have been logged, an intranet whose certs are not logged would not work in Chrome.

-- Fabrice. 

[Ryan Sleevi]

On Wed, Apr 20, 2016 at 7:31 AM, Fabrice Gautier <fabrice...@gmail.com> wrote:

My point: If Chrome only trusts certs from public CAs that have been logged, an intranet whose certs are not logged would not work in Chrome.

I'm aware that's your interpretation, but I'm saying nothing has been said supports that interpretation.

"Chrome only trusts certs from public CAs that have been logged" is being incorrectly parsed as "Chrome does not trust certs from non-public CAs". No such statement has been made.

Rather, what's been stated that, "for certificates from public CAs to be trusted, they must be logged" - that is, it makes no statements for certificates from non-public CAs. 

[Ryan Sleevi]

On Wed, Apr 20, 2016 at 7:10 AM, Peter Bowen <pzb...@gmail.com> wrote:

Ryan,

I am a little confused and concerned when it comes to understanding
how Chrome views 6962-bis.  Today Chrome implements RFC 6962 and has
qualified logs that follow 6962.  My expectation is that, once
6962-bis is published, most 6962 logs will shutdown and be replaced
with 6962-bis compliant logs (or the existing logs will do some
transition to -bis).  I also assume that Chrome will adopt -bis.

6962-bis right now is fairly clear on how redaction works and has a
whole section (https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-14#section-4.3)
on name constrained subordinate CAs.  In the client section of -bis it
says "the TLS client MUST attempt to validate it against the server
certificate and against each of the zero or more suitable
name-constrained intermediates  (Section 4.3)".

If you feel that Chrome is not going to be able to follow the 6962-bis
as written, then I would strongly suggest that you raise this in the
IETF TRANS group sooner than later.  I would hate to see an early and
high profile client implementation fail to follow the standard.

Peter,

I strongly object to the suggestion that it would be "not following the standard". A Chromium implementation could entirely follow the standard, including recognition of redaction. However, it would be a matter of policy that, though it technically supports redaction, it does not recognize such certificates as conforming to policy.

This is no different than Chromium's recognition of a certificate as being "suitably logged" as one that complies with the Chromium CT policy. Nor is it different than Chromium policy that sets expectations on logs - such as not having an MMD greater than 24 hours - even though neither 6962 nor 6962-bis state (to my knowledge) what the MMD value should be. Further, it is not any different than a Chromium policy that requires CAs to log certificates (such as EV certificates), or prohibitions against CAs violating the Baseline Requirements. This is a policy question as to what forms of SCTs will be accepted as complying with policy.

I have no objections to specifying the technical means for redaction. And I'm actually supportive of the MUST that says "In order to comply with 6962-bis, you MUST understand X, Y, and Z". But there is no such prohibition that, as a matter of policy, you can validate Y and Z, but reject them as being inconsistent with policy.

In this same way, Chromium could set a policy that requires that the only SCTs that are recognized are those in pre-certificates, even though RFC 6962 describes three methods of SCTs, and sets a MUST that all three must be supported. It's perfectly fine for Chromium to support them but, as a matter of policy, choose to not use those results.

So that's why I object to the characterization as "not following the standard". This is a question of policy. And while I would love to contribute actionable feedback to TRANS on this matter, what that feedback should be is in large part a consideration about what the policies should appropriately be. But I do want to reiterate, I have no objection to technical specifications that detail how redaction could or should work.

As a last comparison, consider that 6962-bis doesn't specify how many labels can be redacted, nor should it necessarily (especially if that would incur a dependency on the public suffix list). However, even if the technical means for redaction were fully supported, it could be a viable policy to only allow redaction to the eTLD+1 - or only allow TCSC to an eTLD+1.

Hopefully that clarifies things further.

[Fabrice Gautier]

OK, clarifying my points then:

1) Today an organization can build a seemingly private intranet, using
a public CA (non EV), by not logging the certs.
In the future, such certs would be rejected by Chrome as the certs
are not logged.

2) One alternative then would be that an organization would use a
private CA, and have their users install that CA on their systems so
Chrome accepts those intranet certs.

Excluding other possible alternatives that redaction could provide, is
that a fair interpretation ?


-- Fabrice

[Ryan Sleevi]

On Wed, Apr 20, 2016 at 9:39 AM, Fabrice Gautier <fabrice...@gmail.com> wrote:

OK, clarifying my points then:

1) Today an organization can build a seemingly private intranet, using
a public CA (non EV), by not logging the certs.
 In the future, such certs would be rejected by Chrome as the certs
are not logged.

2) One alternative then would be that an organization would use a
private CA, and have their users install that CA on their systems so
Chrome accepts those intranet certs.

Excluding other possible alternatives that redaction could provide, is
that a fair interpretation ?

Correct. 

[Richard Salz]

Is there a timetable for when Chrome will require CT for everything, not just EV?

[Ryan Sleevi]

On Wed, Apr 20, 2016 at 9:54 AM, Richard Salz <rich...@gmail.com> wrote:

Is there a timetable for when Chrome will require CT for everything, not just EV?

That's a separate conversation. We've not announced a timetable yet, although we encourage everyone to log everything they can (with precertificates). As I've mentioned in the CA/Browser Forum, the challenges here are ensuring the ecosystem is robust enough to support truly vendor-neutral policies, and to ensure that the major painpoints of CAs and log operators have been either reasonably addressed or have adequate solutions moving towards completion.

[Fabrice Gautier]

I have not followed the gossip protocols development close enough to
have an informed opinion on the privacy implications, but yes I can
imagine that there is some way to make it anonymous enough for most
users of the public internet.

But I also wonder if the same methods would apply equally to users of
a private intranet.

Thats another discussion I guess...

-- Fabrice

[Peter Bowen]

On Tue, Apr 19, 2016 at 6:10 PM, Jacob Hoffman-Andrews <js...@eff.org> wrote:
> Another argument against redaction: Until now it's been the case that
> anyone can submit any certificate to a CT log, so long as it chains up
> to a recognized root. This has been very useful. a researcher is free to
> download the Censys.io scans and upload them to a CT log. An individual
> is free to record every certificate their browser sees, for later uploading.
>
> If a researcher uploads an unredacted copy of a certificate for
> secret.example.com, and that certificate was previously logged in
> redacted form, is example.com going to consider that a breach of their
> privacy? Right now the implicit assumption in CT is that there is no
> expectation of privacy in publicly trusted certificates. Adding an
> explicit notion of privacy for some DNS names introduces uncertainty
> regarding what kind of certificates are fair game for uploading.

I think you are confusing compelled disclosure with voluntary
disclosure. As I understand it, the topic of this discussion is "a
world in which all certificates 'must' be logged", where "all" means
all certificates that have any chain to a public CA. Given that
Chrome has made it clear that the direction of the browser is to
require TLS for full functionality, this means that anyone wanting to
build public websites that offer a modern high quality user experience
must get a certificate from a public CA and that certificate will be
logged. The question is whether they have to disclose the existence
of that site on their schedule or if it will be compelled to be
disclosed prior to use. Once it is live on the Internet, then they
are voluntarily disclosing it and there should be no expectation of
privacy.

On the other hand there are many cases where certificates are issued
with globally scoped DNS names that are not public. I am aware of very
large networks where the hostnames end in a publicly registered domain
but they are physically disconnected from the Internet. These
networks may use IP addresses listed as reserved or they may use IPs
assigned to the operating organizations. They are cross-organization
networks so using CAs that ship by default in browsers and operating
systems allows interoperability that would otherwise not be practical.
I don't see a compelling value in compelling disclosures for these
certificates.

Thanks,
Peter

[Eric Mill]

On Wed, Apr 20, 2016 at 1:44 PM, Peter Bowen <pzb...@gmail.com> wrote:

On the other hand there are many cases where certificates are issued
with globally scoped DNS names that are not public. I am aware of very
large networks where the hostnames end in a publicly registered domain
but they are physically disconnected from the Internet.  These
networks may use IP addresses listed as reserved or they may use IPs
assigned to the operating organizations.  They are cross-organization
networks so using CAs that ship by default in browsers and operating
systems allows interoperability that would otherwise not be practical.
I don't see a compelling value in compelling disclosures for these
certificates.

While I might agree about compelling disclosures in that case, I think the burden here is on the other side: Is there such a compelling value to preserving secrecy for those certificates that it justifies incorporating a name redaction apparatus into the web PKI and client validations?

The folks here arguing against name redaction aren't, I think, saying that the internet's valid hostnames must all be public. They're saying that name redaction imposes costs that aren't worth the perceived benefits, especially when there are other simpler potential tradeoffs (like wildcards).

On wildcards being a heavy hammer, it's also possible to imagine organizations moving their hostnames around so that their use of wildcards is limited to a special fourth-level or higher domain used for private domains. This wouldn't be very different from what an eTLD+2 redaction proposal would ask enterprises to do.

-- Eric

--

konklone.com | @konklone

[Nick Lamb]

On the other hand there are many cases where certificates are issued
with globally scoped DNS names that are not public. I am aware of very
large networks where the hostnames end in a publicly registered domain
but they are physically disconnected from the Internet.  These
networks may use IP addresses listed as reserved or they may use IPs
assigned to the operating organizations.  They are cross-organization
networks so using CAs that ship by default in browsers and operating
systems allows interoperability that would otherwise not be practical.
I don't see a compelling value in compelling disclosures for these
certificates.

To choose the rules for the web PKI, you need a compelling case for the web's users. That ought to stand to reason. If your private network wants to take the risk that an undisclosed certificate has been issued for a key name and is then abused, that's a risk for the private network, not one to be thrust on the web at large for the convenience of the private network.

The All-England Club grounds ("Wimbledon") are completely unsuitable for playing league soccer. Perhaps to a soccer team this is a compelling reason to enlarge the courts and knock down structures which get in the way. Unsurprisingly the All-England Club is of the opinion that instead soccer players should use one of the dozens of neighbouring soccer pitches, not the tennis club...

[Ryan Sleevi]

I'm going to take one more stab at attempting to summarize the discussion so far, and to share what we've been mulling for the past week since discussion died down. I do want to thank EVERYONE for their participation and the concerns they've expressed, and viewpoints they've shared. This has all been incredibly helpful and enlightening, even where disagreements exist.

Without trying to present strawman summaries, it does seem that on one side, we have heard compelling arguments that DNS, as it functions today, and with improvements in the future, provides a number of means to hide, even from active network observers, the set of records and hierarchy. Even when these technologies are not fully utilized, DNS generally requires an active observation - that is, knowing one name doesn't immediately map out all names, and knowing a name in the past doesn't reveal a name in the future.

On the other hand, we've heard compelling arguments for simplicity and transparency. Beyond the obvious first-order benefits of certificate transparency - such as evaluating whether or not a CA is complying with its stated and expected policies for issuance [independent of hostnames] - there's also benefits to present and future domain holders to know the space of certificates out there for their names, how they've been issued, and who they've been issued to.

We've discussed matters of consent - such as CAA or TXT records, click through agreements, trust the CAs - and of scope - whether it's sufficient at the registerable domain (eTLD+1), whether to impose additional scoping restrictions (eTLD+2), or something more complex.

As we've been thinking about this conversation internally, one area that we continue to struggle with is if there is a path of balance. That is, is there a way to allow redaction while encouraging and promoting transparency. I'm going to term this "recourse" - that is, if we allow transparency at all, we have to solve consent and scope. So far, all of the solutions proposed are largely dependent upon the issuing CAs properly following policies - if they fail to do so, which, unfortunately, I think we must accept they inevitably will, whether through misconfig or malice, what options do there exist to correct the solution? If there are no options to correct these mistakes, then we're clearly sacrificing transparency, since once it happens, well, it happened, and there's nothing we can do about it. If we don't allow it at all, we remove the opportunity for mistakes, but also restrict the freedom for domain holders to configure their domains as they wish. Whether either is objectively a bad thing has been a topic of great discussion, but we haven't really explored the middle ground on the list.

Consider the case of example.com, and a policy that requires an opt-in (via CAA record) to be present, and no such record is present. A certificate is logged, by a CA, that is redacted as ?.example.com. What options exist for the domain holder of example.com? Hence, the term "recourse".

Similarly, consider again the case of example.com, with any form of policy for redaction. The present holder of example.com does not desire redaction, but they purchased example.com recently - previously, it was held by a separate entity ("Foo Corp"). Foo Corp had issued a vast number of redacted certificates - ?.example.com, ?.?.example.com, etc. All of these complied with the redaction policy, all were validly issued. The current holder of example.com would like to understand what steps they can take to assess the risk and take action with these. Hence, the term "recourse"

Consider the case of example.com, with any form of policy. The domain holder has opted-in, but their intent is to only opt-in for certificates managed by their certificate team. However, because the BRs allow for a practical demonstration of control (e.g. a file on a webpage) to cause issuance, a certificate for ?.example.com is issued. The certificate team has no idea about who issued the certificate, or what domain it was for, and thus want to obtain the unredacted copy to determine what the name was, and thus who might have authorized it. Hence, the term "recourse"

So this is the scenario set, for which we try to figure out what options. Here on the Chromium CT team, we've internally struggled to find a good balance between the needs and the risks, and unfortunately, haven't been able to. So we'd like to present it to the community as a problem, to see if there's a path forward. My hope and belief is that, if we can solve the "recourse" problem, then perhaps there's a path that can satisfy both camps. However, if we can't, then it would seem we're forced to make a tough choice that, no matter what, people will be unhappy with, and worse, no matter what, will likely introduce new risks even as it closes old risks. That will be a dangerous calculus to evaluate - if the new risks are, on the balance, less than the old, whatever the solution.

Here's some the scenarios we've identified that we're concerned about:

* A CA issues a redacted certificate, to some party, but is unable to provide the original certificate.

  - There's a question about why this would be the case. Compromise is one possibility, but so is misconfiguration (e.g. a CA is not following the BRs in maintaining a write-once log of the certificates they've issued)

  - What is the expected recourse here? Is the domain holder expecting that trust in the CA will be removed? That applications will blacklist?

  - Is this fundamentally different from other forms of misissuance - and the response to it?

* A CA is shutting down operations (e.g. going out of business, acquisition)

  - Whatever agreements the CA had with root store operators might become null, so what policy lever is there?

  - Should all redacted certificates become public as part of the shutdown? If we accept that redaction is for security purposes, does such a policy mean the shutdown of a CA is a security incident?

  - Is the expectation that trust in the CA will be removed if they can't provide these services after they shut down - such as by contracting with an external party?

* A CA decides to actively ignore any policy imposed on it via redaction

  - Let's say the CA becomes combative, which certainly some have in the past when called out for misissuance. What options does the domain holder have then for redaction, when the only leverage is held by browsers?

  - Is the expectation that the CA will be distrusted? What if that doesn't happen equally across the ecosystem of trust store operators, since some might not hold the same regard for the rights of domain holders, and thus not see non-disclosure as an event that should result in a CAs distrusting?

But now let's also step back a level, and think about how we might establish the domain holder's right to request unredaction. The positive use cases for this are addressed above, and hopefully non-controversial; they are all met by not allowing any redaction at all. But now let's consider the 'attack' scenarios in a world where we accept redaction on the basis of security grounds.

* If we only require a practical demonstration of control over a domain, then an attacker who can temporarily obtain control (such as of a webpage) could potentially request that all the rightfully-redacted certificates be unredacted, mapping out the domain tree. This is in addition to being able to cause misissuance of potentially-redacted certificates.

* If we require domain-based proof of control, then an attacker who can temporarily obtain control (such as a fraudulent zone transfer or state-sponsored attack) could potentially request that all the rightfully-redacted certificates be unredacted, mapping out the domain tree.

* Consider the case where example.net ("Foo Corp") purchases example.com ("Bar Corp") as part of a merger. As part of that, all of Bar Corps' systems are integrated with Foo Corp, eventually such that a domain of internal.corp.example.com is now hosted as internal.corp.example.net. If "Foo Corp" allows their registration of example.com to lax, and a new domain holder purchases it, they could request the unredaction of certificates, potentially obtaining a live map to "Foo Corps" network, based on what had been issued to "Bar Corp" back when it was the registrant.

There's also the question of how to practically demonstrate control of the domain from the CA's perspective.

* Consider a CA which only issues OV certificates, and has added significant internal controls prior to issuing certificates to domain holders (above and beyond the Baseline Requirements). Would it be desirable/correct/fair for them to impose those same standards on someone who requested the unredaction of a certificate? Would the new/present domain holder be able to meet those requirements? What recourse if they couldn't?

* Consider a CA which only uses Domain Authorization Documents, and is suspected of misissuing a ?.example.com certificate. Would the present holder have to obtain/produce a DAD? Is that desirable/correct/fair? What recourse if they couldn't?

As I indicated, we haven't really found a viable policy here that might allow for the 'un'redaction of certificates, short of observing them in the wild. This definitely leaves significant risks in the ecosystem, both for current and future domain holders, and makes it challenging to support redaction. I'll note that many of these 'attacks' here apply not just to the 'un'redaction of certificates, but also to the revocation of them. That is, even if we don't allow for unredaction, and the only recourse is to request revocation, there's no set of policies that clearly govern whether CAs must honor that request, how they must, etc. Section 4.9.1.1 of BRs 1.3.4, Item 6, partially addresses this, but not for all the scenarios highlighted. We aren't sure that simply doing s/revoke/unredact/ on that section would meaningfully address the concerns.

We're curious what the community feels about these scenarios - in particular, fundamentally trying to ask "What should happen when a potential redaction policy goes wrong". If we can't answer that, then it makes it very difficult to imagine supporting a system for which we don't know what the failure mode should or might be.

If you've made it this far, thanks for reading, and I look forward to constructive comments, proposals for how to address this problem, or criticisms of the concerns put forward.

[Kane York]

Thank you for this, Ryan. These are hard questions, and I don't have any answers right now, but I still wanted to thank you for taking the time to write this.

~Kane York

--

You received this message because you are subscribed to a topic in the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/ct-policy/vsTzv8oNcws/unsubscribe.
To unsubscribe from this group and all its topics, 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/CACvaWvakEbx%3Dkc--F7KOR2FaVx8Z3YU1s23ikLLTpM%2B7c7bK5g%40mail.gmail.com.

[Tom Ritter]

Yea these are hard problems. Is the answer 'more cryptography'? (Most
of this borrowed from Adam's email.)

Imagine a DNSSEC-based solution, which I'm going to use because it
simplifies the 'do I trust this key' problem somewhat (but not
entirely, because DNSSEC transparency doesn't exist.) If you don't
like DNSSEC you can replace it with something else if you solve key
authenticity.

The CAA (or whatever) record indicates whether and to what extent
redaction is allowed. The DNSSEC chain is included in a SCT extension
to prove that the certificate was authorized to be redacted. If this
chain cannot be validated, it's considered misissuance by the CA, and
can be detected near-immediately (either by the log before giving a
SCT or by auditors shortly thereafter).

DNS also provides a public key to encrypt the unredacted label to -
companies who set up redaction publish one or more keys there. The
encrypted label is included in the precertificate. (What stops the CA
from encrypting a false label? They also encrypt a nonce, and include
H(label||nonce) in the precertificate. Possession of the precert
doesn't enable a brute force attack, but enables the owning domain to
confirm the label+nonce matches the hash. The nonce and hash are
included in the real certificate, and when validating the SCT you
ensure the precert SCT is valid (hashes match) and that the
label+nonce hashes to the value specified.) The domain owner can
optionally include log keys for unredaction there to enable logs to
validate the validity of the redaction label before issuing a SCT. If
they do - logs are able to fully validate the correctness of
validation. If they don't, the domain owner assumes responsibility for
this.


This system should, in theory, solve many of the problems (I think):
- A CA cannot 'refuse to provide' or be 'unable to provide' an unredacted cert
- A CA can shut down without problems
- Logs can refuse to give SCTs to certs that do not show a valid CAA
authorization path - this can prevent combative CAs
- It is not enough to temporarily control a domain in any way to
unredact certs - you have to steal their key(s)
- It is not enough to temporarily control a domain's DNS to let
redaction occur - you also have to have signed DNSSEC records
- A domain never has to 'prove it's ownership' of a domain for a CA
for unredaction purposes

It introduces problems:
- Complexity (at least 2 x509 extensions, plus a SCT extension? plus
lots of logic)
- Keys people can lose
- (Biggest) DNSSEC

The main problem I see if that it's a lot to ask an organization to
commit to DNSSEC for their entire hierarchy just for redaction - which
is what validating a DNSSEC chain would require. I'm not sure if
there's an easy way around that...

-tom