TLS Certificates Used by Log Endpoints

[Andrew Ayer]

Presently, the GDCA log (ctlog.gdca.com.cn) uses a certificate chaining
to a GDCA root for its HTTPS endpoint. This root is not trusted by NSS,
which means it is not trusted by virtually any Linux system. How should
users of this log (monitors, auditors, submitters, and even people
running curl commands) communicate with the GDCA log from Linux?

1. Disable certificate validation? Arguably, TLS is not needed because
all responses are ultimately signed by the log's key (except the get-roots
response). However, it seems rather irresponsible to suggest that
certificate validation ever be disabled in a production system. It would
be leaving a potential trap in the codebase: if you disable validation on
an HTTPS client handle, there's a risk of later reusing it by accident for
a different connection that needs validation.

2. Ship extra trust anchors along with a log's meta data, and use them
when connecting to the log? This requires extra work of client implementers.
Do all HTTPS client libraries provide an easy way to use additional
trust anchors for a particular connection?

3. Should Chrome/Mozilla log policy require that logs use a widely-trusted
certificate for their HTTPS endpoint? How would "widely-trusted"
be defined? Even if popular root programs have accepted a root, some
clients might have an out-of-date trust store. How much accommodation
would be provided to clients with out-of-date trust stores?

Regards,
Andrew

[Ryan Sleevi]

Thanks for bringing up these questions, Andrew. It's something I've wondered about too, but not wanted to proactively prescribe policy for until we better understood the ecosystem and the impact.

On its face, I'm inclined to believe #2 is more valuable/consistent/open, with the log self-attesting the set of CA(s) it uses. That opens a whole can of policy worms - such as how many CA(s) can be listed, how frequently can/should that list change, etc - and I don't have a good answer for that. We could restrict it to a single key - that is, effectively treating the TLS session as a public-key authenticated (not certificate-authenticated) exchange, with a public key that remains valid for the life of the log, and treated with similar sensitivity as the log's STH-signing private key. However, that ignores the difference in threat models - an STH-signing key can be kept in a reasonably air-gapped network, while a TLS private key would have to be on the 'edge' (whether HSM protected or not)

A natural exploration of #3 is to treat it as a trust-store/CT-log-consumer specific policy (i.e. within the Mozilla and Chrome CT policies, individually), with the natural expansion of that being that you could imagine Mozilla requires that the certificate come from a Mozilla-recognized root, Google requiring from a Google-recognized root, etc. The downside with this approach is both in bootstrap and in distrust.

In a bootstrap scenario, especially imagining a 'post-CT world' (of mandatory CT, perhaps within the BRs, though I'm loathe to imagine that for various reasons), a CA applying for inclusion needs to provide a valid/expired/revoked cert. To provide that, they need to issue the cert. If they're required to issue that cert complying to some program's CT policies, then they (effectively) need to have their CA recognized by another log. However, if the logs' CA inclusion policy is that the CA needs to be included within a root store (e.g. as a defense against spam submissions), then you've got a circular dependency: they can't be included in a root store until included by CT logs, and they can't be included by CT logs until included by a root store. 

In a distrust scenario, the act of distrusting a CA may have the corresponding effect of distrusting one or more CT logs using certificates from that CA, and then you're again into a problem of intersectional dependencies that ideally you wouldn't have. There's not an intrinsic reason to distrust a CT log simply because the issuing/operating CA is distrusted, given the difference in threat models and requirements, but such a policy could have that effect.

This is why I'm inclined to believe #2 is better, and it's a matter of exploring the policies related to it, and the threat models the TLS requirement is meant to address.

Exploring a little bit on the threat model of client->CT log interactions, the concern is less with authenticating the responses of the CT log, since those responses are (... generally) protected by the signed STH. However, there are some exceptions to that, excluded from the overall STH signature, that you do want to make sure are genuine and authentic. I'm not sure to what extent RFC6962-bis has added authentication for responses, but I'd honestly be surprised if this wasn't still the case. However, perhaps more importantly, clients want to ensure confidential connections to the CT log, so that the requests for which certificates (which might be sensitive requests) are not necessarily revealed to on-path adversaries. For this model, a general 'pubkey-only' solution is (probably) sufficient - but then you get into all the normal practical considerations of key management/rotation, and the PKI part becomes convenient, and the support for multiple independent anchors becomes convenient.

I'm curious if you have any personal leanings or concerns, or if there are dimensions to this problem space that haven't been addressed in the above. I certainly don't have any good solutions ready, but I'm curious to explore it - since part of the purpose of the present policies is to promote positive practice.

[Gervase Markham]

On 19/12/16 20:42, Ryan Sleevi wrote:
> Thanks for bringing up these questions, Andrew. It's something I've
> wondered about too, but not wanted to proactively prescribe policy for
> until we better understood the ecosystem and the impact.

Yes - this is indeed a good question.

> On its face, I'm inclined to believe #2 is more
> valuable/consistent/open, with the log self-attesting the set of CA(s)
> it uses. That opens a whole can of policy worms - such as how many CA(s)
> can be listed, how frequently can/should that list change, etc - and I
> don't have a good answer for that. We could restrict it to a single key
> - that is, effectively treating the TLS session as a public-key
> authenticated (not certificate-authenticated) exchange, with a public
> key that remains valid for the life of the log, and treated with similar
> sensitivity as the log's STH-signing private key. However, that ignores
> the difference in threat models - an STH-signing key can be kept in a
> reasonably air-gapped network, while a TLS private key would have to be
> on the 'edge' (whether HSM protected or not)

Yes, I think a single key would be problematic. Instead, might it work
to have the metadata contain a single root/intermediate (the "Metadata
Cert") which directly signs the EE cert? This might be less problematic,
particularly if the Metadata Cert is controlled by the log owner and can
be kept offline even if the EE certificate cannot kept offline.

So in other words, people interacting with logs who are validating the
certificate validate that a) it's for the right hostname, and b) it was
directly issued by the Metadata Cert. If it passes those two checks,
that's OK.

This allows you both to rotate the EE cert, and to validate the "chain"
in most HTTPS libraries my importing the Metadata Cert as a trust
anchor. There's no requirement for the Metadata Cert to be publicly
trusted, so it can be special-purpose if the log operator finds that
convenient.

How about that?

Gerv

[Andrew Ayer]

Hi Ryan,

I may be misunderstanding, but this strikes me as a different problem,
related to what roots a log accepts, rather than what root the log's
HTTPS certificate chains to.

> In a distrust scenario, the act of distrusting a CA may have the
> corresponding effect of distrusting one or more CT logs using
> certificates from that CA, and then you're again into a problem of
> intersectional dependencies that ideally you wouldn't have. There's
> not an intrinsic reason to distrust a CT log simply because the
> issuing/operating CA is distrusted, given the difference in threat
> models and requirements, but such a policy could have that effect.

Already there are two types of policy violations: those which require
distrust (e.g. conflicting STHs), and those which do not, especially if
they are corrected promptly. Temporarily using a TLS certificate from a
recently-distrusted CA certainly falls into the latter category, and I
don't see this being a problem considering the many instances of policy
violations over the past year that did not lead to log distrust.

> This is why I'm inclined to believe #2 is better, and it's a matter of
> exploring the policies related to it, and the threat models the TLS
> requirement is meant to address.
>
> Exploring a little bit on the threat model of client->CT log
> interactions, the concern is less with authenticating the responses
> of the CT log, since those responses are (... generally) protected by
> the signed STH. However, there are some exceptions to that, excluded
> from the overall STH signature, that you do want to make sure are
> genuine and authentic. I'm not sure to what extent RFC6962-bis has
> added authentication for responses, but I'd honestly be surprised if
> this wasn't still the case.

6962 and 6962-bis are the same: all responses are signed by the log key
or can be verified against an STH, except for get-roots/get-anchors and
unsuccessful responses (e.g. errors, bad proofs, and get-entries responses
that don't correspond to an STH).

Something to consider is that most of the open source CT client code
I've seen does not attempt to verify signatures and therefore relies
entirely on the security of the TLS connection. I'm not sure to what
extent we want to accommodate clients like this.

> However, perhaps more importantly,
> clients want to ensure confidential connections to the CT log, so
> that the requests for which certificates (which might be sensitive
> requests) are not necessarily revealed to on-path adversaries. For
> this model, a general 'pubkey-only' solution is (probably) sufficient
> - but then you get into all the normal practical considerations of
> key management/rotation, and the PKI part becomes convenient, and the
> support for multiple independent anchors becomes convenient.

It would be helpful to hear from log operators about their requirements.
Could they use a single TLS key for the lifetime of their log? If not,
how often do they need to change the root CA to which their certificate
chains? How much notice can they provide of that change?

Note that of the three HTTP client libraries with which I'm familiar
(libcurl, Go's net/http, and libwww-perl), only libwww-perl provides
an easy way to validate an HTTPS connection using a public key, whereas
all three provide an easy way to configure trust anchors.

Gerv's suggestion of requiring logs to commit to a single issuing certificate
seems to address all the problems of the public-key-only proposal while
retaining its benefits of policy simplicity.

> I'm curious if you have any personal leanings or concerns, or if
> there are dimensions to this problem space that haven't been
> addressed in the above. I certainly don't have any good solutions
> ready, but I'm curious to explore it - since part of the purpose of
> the present policies is to promote positive practice.

Practically speaking, I probably have no choice but to ship trust anchors
with Cert Spotter, as I want it to work out-of-the-box and I expect
people will want to run it on Debian systems with criminally-outdated
root stores. So I'll probably end up doing the same amount of work for
both #2 and #3.

However, I'm concerned with the amount of work others have to do to
get started with CT. It would strike me as unfortunate if people
couldn't point their favorite HTTP library in its default configuration
at a log endpoint and have it just work. Also, I frequently use
the curl command to make ad-hoc queries against a log, something that
would become harder if logs didn't use a widely-trusted certificate.

Meanwhile, the policy problems with #3 don't seem serious. Considering
the huge amount of overlap in certificates between root programs, it
shouldn't be hard for a log to be compliant with multiple browsers' log
programs even if each one required use of a certificate trusted by their
own root program.

Thus, I am currently leaning towards #3. My second choice is Gerv's
suggestion of a fixed issuing CA. I do not like any of the other options
so far.

Regards,
Andrew

[Ryan Sleevi]

On Wed, Dec 21, 2016 at 8:17 AM, Andrew Ayer <ag...@andrewayer.name> wrote:

> In a bootstrap scenario, especially imagining a 'post-CT world' (of
> mandatory CT, perhaps within the BRs, though I'm loathe to imagine
> that for various reasons), a CA applying for inclusion needs to
> provide a valid/expired/revoked cert. To provide that, they need to
> issue the cert. If they're required to issue that cert complying to
> some program's CT policies, then they (effectively) need to have
> their CA recognized by another log. However, if the logs' CA
> inclusion policy is that the CA needs to be included within a root
> store (e.g. as a defense against spam submissions), then you've got a
> circular dependency: they can't be included in a root store until
> included by CT logs, and they can't be included by CT logs until
> included by a root store.

I may be misunderstanding, but this strikes me as a different problem,
related to what roots a log accepts, rather than what root the log's
HTTPS certificate chains to.

Well, I see them as related, in as much as a CA who is faced with the challenge of no (existing) logs accepting their certificate would be inclined to spin up their own log. However, if their own log was unable to use a certificate from their CA (because their CA is not trusted), it creates the circular dependency that leads to the situation I described.

More concretely, Honest Achmed wants to get into the CA business, but (assuming the world of CT log root acceptance criteria is not changed), is unable to find any log willing to log Honest Achmed's certificates. If we also presume a world where, in order to issue a certificate, Honest Achmed must log the certificate, then Honest Achmed is now in a bind. We might also presume under this model that Google's logs may not take Achmed's certificates until Achmed's roots are trusted, but Achmed's roots aren't trusted until Achmed issues certificates complying to the BRs. The solution to Achmed's problem would be for Achmed to run a CT log which would accept Achmed's certificates, which would allow them to bootstrap logging for the good/expired/revoked, which would then allow Achmed to get included in root stores, which would then allow Achmed to log (to both Google and to Achmed), and the problem is sorted.

However, if Achmed needs to use another CA for the CT logs' TLS certificate, then we have a potential problem.

There are many, many ways to solve this problem by cutting the loop throughout, and most importantly, it presumes a world that some CAs have requested, in which CT logging becomes part of the BRs. Hopefully scenarios like this explain my historic recalcitrance at codying this in the BRs.

This is no doubt a convoluted scenario, but highlights the sort of 'holistic view of the problem' that I try to advocate - by working through all the other ecosystem impacts that a given change might have, so we can better understand what changes might need to be coupled with/accompany the matter.

 

Already there are two types of policy violations: those which require
distrust (e.g. conflicting STHs), and those which do not, especially if
they are corrected promptly.  Temporarily using a TLS certificate from a
recently-distrusted CA certainly falls into the latter category, and I
don't see this being a problem considering the many instances of policy
violations over the past year that did not lead to log distrust.

It seems I was not clear. In requiring a CT log to use a certificate from a 'trusted' CA, if that CA is distrusted, it could have the corresponding impact of distrusting the log 'in practice' if the connections to the log were simply authenticated using the trust store.

Or, put differently:

Imagine a CT client that uses the NSS library (including its trust store) to TLS authenticate to the CT log.

The CA who issued the CT logs certificate is distrusted, due to the CA's actions.

The CT client now has the 'practical' effect of distrusting the CT log, even though the log remains trusted, because the underlying library no longer trusts the CA.

This is why I was more inclined to suggest not coupling the CT log communications to the CA trust store, but instead using metadata associated with the log.

 

Something to consider is that most of the open source CT client code
I've seen does not attempt to verify signatures and therefore relies
entirely on the security of the TLS connection.  I'm not sure to what
extent we want to accommodate clients like this.

Really?! o_O That seems incredibly... bad... to me.

 

Note that of the three HTTP client libraries with which I'm familiar
(libcurl, Go's net/http, and libwww-perl), only libwww-perl provides
an easy way to validate an HTTPS connection using a public key, whereas
all three provide an easy way to configure trust anchors.

Oh, to be clear, I was suggesting certificates as the communication mechanisms of that pubkey - just that the associated certificate metadata wasn't relevant to the security model - just the pubkey.

 

Gerv's suggestion of requiring logs to commit to a single issuing certificate
seems to address all the problems of the public-key-only proposal while
retaining its benefits of policy simplicity.

Indeed.

 

However, I'm concerned with the amount of work others have to do to
get started with CT. 

Me too. This is a very large concern of mine, and why I'm really glad that there's greater involvement here on ct-policy@ so that we can find ways - both in implementation and policy - to try to simplify. There are, quite frankly, a lot of externalities involved (as there are with any protocol changes), and while I doubt we'll get everything right the first try (which is why Google has been VERY cautious in increasing dependencies on CT over the past 5 years), I do want to make sure we're not simply layering on complexity without checking for where we can simplify.

 

Meanwhile, the policy problems with #3 don't seem serious.  Considering
the huge amount of overlap in certificates between root programs, it
shouldn't be hard for a log to be compliant with multiple browsers' log
programs even if each one required use of a certificate trusted by their
own root program.

Hopefully the above clarifications better explain my concerns with #3, as a practical matter. It seems like it'd be introducing a risk that would only happen when things went bad, but when they went bad, could go real bad.

On the other hand, I'm also totally accepting of the argument that the risk/implications would be low, as long as we practically identify and are aware of the risks when making that decision. I'm much better at risk modeling than risk assessment here :)

[Andrew Ayer]

This is the part I don't understand - why is it a problem for a CA to
use another CA for their log's TLS certificate? After all, non-CA log
operators have to get a TLS certificate from someone else.

I think I understand now. This is essentially the same problem we have
today, where the GDCA log is in practice not trusted by TLS clients
using the NSS root store.

Let's say Mozilla required use of a TLS certificate trusted by the
NSS root store, Google required use of a TLS certificate trusted by
a Google-maintained root store, and so on. Furthermore, let's say
that use of an untrusted certificate counted against the log's uptime
requirement, which seems sensible since use of an untrusted certificate
means TLS clients can't connect to it.

Under this policy, a log using a certificate from a CA that becomes
distrusted by NSS will be induced to switch to a different CA in a
timely manner. The outage to CT clients using the NSS store would be
no worse than any other unscheduled log outage. This doesn't seem bad.
Have I missed some aspect of this?

> This is why I was more inclined to suggest not coupling the CT log
> communications to the CA trust store, but instead using metadata
> associated with the log.
>
>
> > Something to consider is that most of the open source CT client code
> > I've seen does not attempt to verify signatures and therefore relies
> > entirely on the security of the TLS connection. I'm not sure to
> > what extent we want to accommodate clients like this.
> >
>
> Really?! o_O That seems incredibly... bad... to me.

Maybe. Consider a service which just wants to discover certificates from
any source possible, including Internet scans, and isn't interested in
auditing logs for proper behavior. Perhaps it's not so terrible for
this service to just make calls to get-entries without checking they
match a verified STH.

Of course, I'd prefer clients always check signatures, particularly
since there are ecosystem benefits to detecting misbehaving logs, which
is why Cert Spotter checks signatures and verifies get-entries responses.

Regards,
Andrew

[Ryan Sleevi]

On Wed, Dec 21, 2016 at 1:30 PM, Andrew Ayer <ag...@andrewayer.name> wrote:

> However, if Achmed needs to use another CA for the CT logs' TLS
> certificate, then we have a potential problem.

This is the part I don't understand - why is it a problem for a CA to
use another CA for their log's TLS certificate?  After all, non-CA log
operators have to get a TLS certificate from someone else.

It increases the inter-CA dependency. You can see from Gerv's policy proposals that quite a few CAs are concerned with that. A non-CA log operator may not be seen as a 'competitor' to a CA, while a CA log operator may be. Contrary to the direction Mozilla appears to be going (whether intentionally or not), I'm concerned about introducing any inter-org dependencies when it's possible to be avoided.

That said, it's fully about risk and cost management. It may be that the ecosystem cost of having log-specified CAs far exceeds the ecosystem risk of having CA log operators need to obtain certificates for their log from another CA (in the admittedly convoluted scenario I described). I see it more as discussing the con, and why I'm disinclined for it, not suggesting it's being ruled out.

 

Under this policy, a log using a certificate from a CA that becomes
distrusted by NSS will be induced to switch to a different CA in a
timely manner.  The outage to CT clients using the NSS store would be
no worse than any other unscheduled log outage.  This doesn't seem bad.
Have I missed some aspect of this?

There's a broader set of concerns about how you measure and quantify that. For example, would a log operator only have 24 hours (or whatever their outage budget may be) to get a certificate from another CA? What about jurisdictions that require additional vetting as part of issuance or mandates the use of specific CAs (e.g. the discussions in eIDAS in Europe, Kazakhstan, Russia, China, etc). Do you measure it by release date of a particular version?

What if a log operator used a CA that was only included in the bleedingest-of-edge releases? Is that an outage? Or if they switched to a 'fresh' CA the moment a particular version hit stable - despite the fact that there were and are clients on an older version of stable?

In particular, I think any form of coupling is non-ideal: CT, as an ecosystem, should generally be able to bootstrap and support itself independent of activities in these other spheres. Whether or not that is an achievable goal is, in some part, what we're discussing - but I've been loathe to introduce additional coupling, because the greater coupling, the greater the systemic risks, both practically and policy wise.

[Richard Salz]

> It increases the inter-CA dependency. You can see from Gerv's policy proposals that quite a few CAs are concerned with that. A non-CA log operator may not be seen as a 'competitor' to a CA, while a CA log operator may be.

Yes, I strongly agree with this; it feels like coercion, and regardless of the commercial considerations, I would be surprised if it stood up to any kind of legal challenge, if it came to that.

As all the important data is signed and timestamped, what is the risk of using plaintext or unqualified certs for a log?

[Ryan Sleevi]

On Wed, Dec 21, 2016 at 2:58 PM, Richard Salz <rich...@gmail.com> wrote:

As all the important data is signed and timestamped, what is the risk of using plaintext or unqualified certs for a log?

Hi Rich,

If you read previous in the thread, this was explained in my very first reply. It'd be useful to know if you disagree with that threat model or would like to extend it.

[Richard Salz]

If you read previous in the thread, this was explained in my very first reply. It'd be useful to know if you disagree with that threat model or would like to extend it.

I tried to read all the messages, and I think you're referring your message where you said "thinking about the threat model"...

I understand the confidentiality concern but I dont see it as a high risk.  The risk is that a rogue, in the trust store, CA could issue a bogus cert for the log, and that the client can then be directed to the attacker.  The mitigation for this, until the TLS cert for the log, and the log, is trusted, is for that CA to tell its customers to staple the SCT's.  Right?

[Andrew Ayer]

On Wed, 21 Dec 2016 14:12:16 -0800
Ryan Sleevi <rsl...@chromium.org> wrote:

> On Wed, Dec 21, 2016 at 1:30 PM, Andrew Ayer <ag...@andrewayer.name>
> wrote:
> >
> > > However, if Achmed needs to use another CA for the CT logs' TLS
> > > certificate, then we have a potential problem.
> >
> > This is the part I don't understand - why is it a problem for a CA
> > to use another CA for their log's TLS certificate? After all,
> > non-CA log operators have to get a TLS certificate from someone
> > else.
> >
>
> It increases the inter-CA dependency. You can see from Gerv's policy
> proposals that quite a few CAs are concerned with that. A non-CA log
> operator may not be seen as a 'competitor' to a CA, while a CA log
> operator may be. Contrary to the direction Mozilla appears to be
> going (whether intentionally or not), I'm concerned about introducing
> any inter-org dependencies when it's possible to be avoided.

Thanks for clarifying this point. It seems to me that these
inter-organization dependencies already exist and are practically
impossible for a brand-new CA to avoid. For example, new CAs often
obtain cross-signatures from existing CAs. https://www.cnnic.cn uses a
certificate issued by DigiCert, and https://www.letsencrypt.org uses a
certificate issued (directly) by IdenTrust. I imagine that both
organizations chose to do this so people could access their websites
while their own CAs were not widely trusted.

> That said, it's fully about risk and cost management. It may be that
> the ecosystem cost of having log-specified CAs far exceeds the
> ecosystem risk of having CA log operators need to obtain certificates
> for their log from another CA (in the admittedly convoluted scenario
> I described). I see it more as discussing the con, and why I'm
> disinclined for it, not suggesting it's being ruled out.
>
>
> > Under this policy, a log using a certificate from a CA that becomes
> > distrusted by NSS will be induced to switch to a different CA in a
> > timely manner. The outage to CT clients using the NSS store would
> > be no worse than any other unscheduled log outage. This doesn't
> > seem bad. Have I missed some aspect of this?
> >
>
> There's a broader set of concerns about how you measure and quantify
> that. For example, would a log operator only have 24 hours (or
> whatever their outage budget may be) to get a certificate from
> another CA? What about jurisdictions that require additional vetting
> as part of issuance or mandates the use of specific CAs (e.g. the
> discussions in eIDAS in Europe, Kazakhstan, Russia, China, etc). Do
> you measure it by release date of a particular version?

I'm not very concerned by these scenarios. I see the TLS certificate
as just one of many services which a log operator must obtain in order
to operate a log, alongside hosting, Internet transit, etc. If one of
the log operator's providers has a failure which the log operator
cannot recover from in time, the log is at risk of distrust.
Certainly, running a high-availability service on the Internet requires
that you have a backup certificate ready in case your primary
certificate fails.

However, your point about this being an inter-dependency is well taken.
In that way, a TLS certificate from a trusted CA is not like other
services and therefore may deserve special consideration.

> What if a log operator used a CA that was only included in the
> bleedingest-of-edge releases? Is that an outage? Or if they switched
> to a 'fresh' CA the moment a particular version hit stable - despite
> the fact that there were and are clients on an older version of
> stable?

Yeah, I alluded to this in my initial email. It's a tricky question
and I don't have a good answer.

I wonder what other folks here think about the tradeoffs.

Regards,
Andrew

[Ryan Sleevi]

On Wed, Dec 21, 2016 at 3:19 PM, Richard Salz <rich...@gmail.com> wrote:

If you read previous in the thread, this was explained in my very first reply. It'd be useful to know if you disagree with that threat model or would like to extend it.

I tried to read all the messages, and I think you're referring your message where you said "thinking about the threat model"...

Right. The signed nature of the responses gives us assurances of authenticity from the log, but does not offer any confidentiality for the client.

 

I understand the confidentiality concern but I dont see it as a high risk. 

Do you see it as high impact though? I was trying to imply it is - a low risk, low impact event is hard to get out of bed for. A high risk, high impact event is enough to doom something. A low risk, high impact event is something we should think through, and a high risk, low impact event is... business as usual.

 

The risk is that a rogue, in the trust store, CA could issue a bogus cert for the log, and that the client can then be directed to the attacker. The mitigation for this, until the TLS cert for the log, and the log, is trusted, is for that CA to tell its customers to staple the SCT's.  Right?

This feels like you're moving goalposts, so I must not have understood you before. Previously, you asked "what is the risk of using plaintext or unqualified certs for a log?" - and the risk was one that was previously highlighted - to the confidentiality for the client.

It seems like you're now moving the discussion to presume a mandate of TLS (as currently required) - but it's unclear if you're imagining that requirement being to use publicly-trusted certificates (for some ill-defined value of that, as I tried to capture in response to Andrew), whether you're imagining it using self-attested certs (as Gerv suggested and Andrew noted as Option 3), or some other variation. I'm not sure I can make sense of the rest of your message, but I'm hoping that with a little clarification it can make more sense.

[Gervase Markham]

On 21/12/16 22:12, Ryan Sleevi wrote:
> It increases the inter-CA dependency.

It does, although in a fairly minor way. Once the CA concerned has
bootstrapped, in your scenario, they can switch to using a cert from
their own CA.

The CAB Forum website has a cert from only one of its members. So does
the CASC website. Using a cert issued by someone else for a machine or
two, for technical reasons, doesn't seem to be the worst thing in the
world.

But I'd still like to see more explanation of my "metadata contains next
intermediate up" proposal, which I think might solve this.

Gerv

[Richard Salz]

On 21/12/16 22:12, Ryan Sleevi wrote:
> It increases the inter-CA dependency.

It does, although in a fairly minor way. Once the CA concerned has
bootstrapped, in your scenario, they can switch to using a cert from
their own CA.

It is not minor.  Imagine that Mozilla updates had to be signed by an Apple Safari key, or other browser.  Imagine that a CDN-run log managed by CloudFlare had to use a cert from Akamai.  Or any vice-versa.

The CAB Forum website has a cert from only one of its members. So does
the CASC website. Using a cert issued by someone else for a machine or
two, for technical reasons, doesn't seem to be the worst thing in the
world.

Those analogies don't hold.  That's a consortium using one of its members.  You are potentially requiring someone to directly use a competitor's services for some period of time.  I can't imagine most business going for that.  Seriously.  I can envision the conversation, going up to the VP level:  "For the good of the internet, we're going to have to use XXX's cert on our website for 90 days."  "No."

[Matt Palmer]

On Thu, Dec 22, 2016 at 09:50:35AM -0500, Richard Salz wrote:
> You are potentially requiring someone to directly use a competitor's
> services for some period of time. I can't imagine most business going for
> that. Seriously. I can envision the conversation, going up to the VP
> level: "For the good of the internet, we're going to have to use XXX's
> cert on our website for 90 days." "No."

That would be a persuasive argument if it weren't for the fact that that is
*exactly* how every CA already gets started, except they depend on their
competitor for a lot longer than 90 days, and in a far more intimate (and
hard-to-change) manner than "I got a DV cert from competitor XXX".

- Matt

--
"After years of studying math and encountering surprising and
counterintuitive results, I came to accept that math is always reasonable,
by my intuition of what is reasonably is not always reasonable."
-- Steve VanDevender, ASR

[Ryan Sleevi]

On Thu, Dec 22, 2016 at 3:59 PM, Matt Palmer <mpa...@hezmatt.org> wrote:

That would be a persuasive argument if it weren't for the fact that that is
*exactly* how every CA already gets started, except they depend on their
competitor for a lot longer than 90 days, and in a far more intimate (and
hard-to-change) manner than "I got a DV cert from competitor XXX".

While I appreciate the point you're trying to make - there's zero mandate to acquire such a certificate. Whatever practical or business considerations may exist, they're just that - at the discretion of the CA. This is materially different.

[Eran Messeri]

I'd like to revive this thread in light of a CT log inclusion request by SHECA (https://bugs.chromium.org/p/chromium/issues/detail?id=712069).

Said log is using a certificate issued by SHECA itself, which isn't in the root store on the platform I'm currently using.

It seems to me that option #2 from Andrew's original email (shipping extra trust anchors) is an agreed-upon way of dealing with such logs, given Gerv's suggestion of shipping the a single root certificate that'll directly certify the EE cert used by each log (providing flexibility for the log operator to rotate EE certs and keys).

As Andrew and Ryan point out re option #3, defining "widely-trusted certificate" is tricky - for Chrome, I'd like to suggest defining that as a certificate that would be considered valid on one of the platforms Chrome ships on (that is, an SSL connection to the CT log using Chrome from one of these platforms would yield a successful certificate validation).

That has the benefit of setting some bar for CT log operators and would only require Log Clients to rely on the extra trust anchors for a limited amount, since (I assume) such trust anchors will make their way into all major trust stores and so would be picked up by SSL libraries eventually.

Opinions? I'm happy to go with option #2 as-is, but for simplicity would prefer knowing that the need to add a trust anchor for the purpose of monitoring a CT log is temporary, since the trust anchor is making its way into "widely-used" root stores.

As a side note, it seems to me that EE certs used by logs do not have to comply with the CT policy (i.e. have SCTs) since they're not commonly connected to by web browsers (i.e. not hosted on the same host that serves web traffic).

[Ryan Sleevi]

On Fri, Apr 21, 2017 at 9:59 AM, Eran Messeri <er...@chromium.org> wrote:

As Andrew and Ryan point out re option #3, defining "widely-trusted certificate" is tricky - for Chrome, I'd like to suggest defining that as a certificate that would be considered valid on one of the platforms Chrome ships on (that is, an SSL connection to the CT log using Chrome from one of these platforms would yield a successful certificate validation).

That has the benefit of setting some bar for CT log operators and would only require Log Clients to rely on the extra trust anchors for a limited amount, since (I assume) such trust anchors will make their way into all major trust stores and so would be picked up by SSL libraries eventually.

Opinions? I'm happy to go with option #2 as-is, but for simplicity would prefer knowing that the need to add a trust anchor for the purpose of monitoring a CT log is temporary, since the trust anchor is making its way into "widely-used" root stores.

I'm not a fan of that definition, as the person responsible for managing that set. Option #2 is better in every way from my perspective as a Chromium maintainer :) The assumption you're making doesn't hold (e.g. different stores policies on government CAs) nor is it easily quantified (e.g. certificates which are restricted)

[Eran Messeri]

Understood, I wasn't aware of those, thanks for pointing it out.

Do I understand correctly that if we go with option #2 as-is, then the policy change would be to require each Log Operator to specify the root that'll be used to directly certify the end-entity certificates that their log will use?

If so, how do we avoid burdening log operators who use CAs that are widely-trusted? Would Log Operators be required to inform Chrome that they are changing a CA?

(I'm not saying they should; I'm looking for a way to formalize the requirement without burdening operators).

[Ryan Sleevi]

On Fri, Apr 21, 2017 at 12:35 PM, Eran Messeri <er...@chromium.org> wrote:

Understood, I wasn't aware of those, thanks for pointing it out.

Do I understand correctly that if we go with option #2 as-is, then the policy change would be to require each Log Operator to specify the root that'll be used to directly certify the end-entity certificates that their log will use?

Define "directly certify"? With or without intermediates? ;)

 

If so, how do we avoid burdening log operators who use CAs that are widely-trusted? Would Log Operators be required to inform Chrome that they are changing a CA?

(I'm not saying they should; I'm looking for a way to formalize the requirement without burdening operators).

I think that is the logical consequence, and I think it'd have implications for monitors, so we'd want to strive for some form of notice period except for exigent circumstances.

[Eran Messeri]

On Fri, Apr 21, 2017 at 5:59 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Fri, Apr 21, 2017 at 12:35 PM, Eran Messeri <er...@chromium.org> wrote:

Understood, I wasn't aware of those, thanks for pointing it out.

Do I understand correctly that if we go with option #2 as-is, then the policy change would be to require each Log Operator to specify the root that'll be used to directly certify the end-entity certificates that their log will use?

Define "directly certify"? With or without intermediates? ;)

Seems to me "with intermediates" would be OK?

That would simplify implementation by allowing log clients to simply add the trust anchor to the underlying SSL library and have it validate the certificate chain presented in the connection to the log.

 

If so, how do we avoid burdening log operators who use CAs that are widely-trusted? Would Log Operators be required to inform Chrome that they are changing a CA?

(I'm not saying they should; I'm looking for a way to formalize the requirement without burdening operators).

I think that is the logical consequence, and I think it'd have implications for monitors, so we'd want to strive for some form of notice period except for exigent circumstances.

Explicitly stating to see I got it right:

- Log operators would have to state which trust anchor will be used to issue certificates for the log itself.

- Log operators would have to notify if that trust anchor changes.

Questions:

- Can log operators refer to an existing trust anchor, for example by specifying issuer + serial number or by a crt.sh link?

- Can log operators provide this information using CAA records?

Eran

[Ryan Sleevi]

On Mon, Apr 24, 2017 at 7:23 AM, Eran Messeri <er...@chromium.org> wrote:

If so, how do we avoid burdening log operators who use CAs that are widely-trusted? Would Log Operators be required to inform Chrome that they are changing a CA?

(I'm not saying they should; I'm looking for a way to formalize the requirement without burdening operators).

I think that is the logical consequence, and I think it'd have implications for monitors, so we'd want to strive for some form of notice period except for exigent circumstances.

Explicitly stating to see I got it right:

- Log operators would have to state which trust anchor will be used to issue certificates for the log itself.

- Log operators would have to notify if that trust anchor changes.

Yup.

 

Questions:

- Can log operators refer to an existing trust anchor, for example by specifying issuer + serial number or by a crt.sh link?

As opposed to? Explicitly stating it, right?

 

- Can log operators provide this information using CAA records?

CAA is meant for a different purpose. For example, it just includes the domain name. Did you mean for TLSA records? Seems more desirable for this to be explicit across the board. 

[Alex Gaynor]

FWIW, as someone writing tooling which interacts with ~arbitrary trusted logs (as listed in log_list.json); needing to deal with certificates that aren't Broadly Trusted (tm) is moderately inconvenient. (I ran into this with WoSign this past week; their log, which is trusted, uses a WoSign certificate, which isn't). At a minimum if the decision is made to allow logs to use certificates, it'd be great if the log_list.json schema was expanded to include the root cert.

Alex

--
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+unsubscribe@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/CACvaWvao4-Wbj06nfzEhj%2BhMmMpeJtmKe9dHso50dRM0VpCW0w%40mail.gmail.com.

[Ryan Sleevi]

I filed https://github.com/GoogleChrome/ct-policy/issues/2 to make sure we don't lose sight of this issue.

I'd like to keep discussion on the list, but we can then track the resolution and conclusion there :)

[Eran Messeri]

(and yes, I meant TLSA record. But that seems to add more complication, on second thought)

On Monday, April 24, 2017 at 9:54:06 PM UTC+1, Alex Gaynor wrote:

FWIW, as someone writing tooling which interacts with ~arbitrary trusted logs (as listed in log_list.json); needing to deal with certificates that aren't Broadly Trusted (tm) is moderately inconvenient. (I ran into this with WoSign this past week; their log, which is trusted, uses a WoSign certificate, which isn't). At a minimum if the decision is made to allow logs to use certificates, it'd be great if the log_list.json schema was expanded to include the root cert.

That's what I was alluding to - a log operator could either be required to include the exact root certificate that the log's certificate chain will chain to, or can be allowed to refer to it by crt.sh link, etc.

[Andrew Ayer]

For Cert Spotter, I'm OK with Option #2. However, since sending
my original email, I have written ct-honeybee-chrome[1], a Chrome
extension that periodically fetches STHs from logs and uploads them to
STH pollination endpoints. The goal is to look for split views from many
different vantage points. As far as I can tell, the Chrome extension
API, as well as Mozilla's WebExtensions API, provide no way to either
use custom roots or disable certificate validation. Option #3 is the
only option that would work in this environment.

I think there are some interesting possibilities for extension-based
CT log clients. Browser extensions provide a nice way to distribute
software, and a CT monitor packaged as a browser extension could make
CT accessible to more people. It would be a shame to preclude the use
of extension-based CT clients.

Regards,
Andrew

[1] https://chrome.google.com/webstore/detail/certificate-transparency/gjhaoajepbfhhlgchgmohmpkngehjhgn

[Ryan Sleevi]

On Tue, Apr 25, 2017 at 12:01 PM, Andrew Ayer <ag...@andrewayer.name> wrote:

For Cert Spotter, I'm OK with Option #2.  However, since sending
my original email, I have written ct-honeybee-chrome[1], a Chrome
extension that periodically fetches STHs from logs and uploads them to
STH pollination endpoints.  The goal is to look for split views from many
different vantage points.  As far as I can tell, the Chrome extension
API, as well as Mozilla's WebExtensions API, provide no way to either
use custom roots or disable certificate validation.  Option #3 is the
only option that would work in this environment.

I think there are some interesting possibilities for extension-based
CT log clients.  Browser extensions provide a nice way to distribute
software, and a CT monitor packaged as a browser extension could make
CT accessible to more people.  It would be a shame to preclude the use
of extension-based CT clients.

I agree, there's interesting possibilities, but using that as the standard creates a circular dependency that seems worse.

That is, if we use the standard that "Browser must be able to contact the Log using extensions", then it implies all Logs must have certificates accepted by the Browser, and compliant with the Browser policy - including that of, for example, a requirement to log the certificates for the Log.

This might be solved iff all logs were required to accept all Roots, because then as long as there were sufficient N logs, that policy could always be reasonably met.

However, it also introduces the coupled-dependency that distrusting a CA (or limiting its issuance) would also have the impact of disqualifying/distrusting a log (or at least requiring it rotate certificates). I can see this as either desirable or undesirable, depending on your threat model. If a Log Operator finds themselves unable to get a certificate from another CA, and they're distrusted/disqualified, then we've just killed a Log.

Is the value of ct-honeybee-chrome worth that tradeoff? Are there different ways to address the split view problem for browser clients? It seems Richard Barnes had started exploring that idea on TRANS.

For this specific case, my own thinking about the priorities of constituencies are:

1) Optimize for CAs (so they can log precerts & OCSP responses) & their ease & clarity

2) Optimize for servers (so they can do the TLS extension method of SCTs)

3) Optimize for Monitors (so they can watch for certs) & their ease & clarity

4) Optimize for Auditors (so they can watch the behaviour)

In this case, priorities 1&2&3 seem to strongly benefit from explicit certs, and only a subset of #4 are impacted.

[Andrew Ayer]

I haven't seen anything proposed that would eliminate the need for STH
observation and gossiping.

> For this specific case, my own thinking about the priorities of
> constituencies are:
> 1) Optimize for CAs (so they can log precerts & OCSP responses) &
> their ease & clarity
> 2) Optimize for servers (so they can do the TLS extension method of
> SCTs)
> 3) Optimize for Monitors (so they can watch for certs) & their ease &
> clarity
> 4) Optimize for Auditors (so they can watch the behaviour)
>
> In this case, priorities 1&2&3 seem to strongly benefit from explicit
> certs, and only a subset of #4 are impacted.

A subset of monitors could be impacted also, should someone want to
distribute a CT monitor as a browser extension. I also wouldn't say that
monitors "strongly" benefit from explicit certs as opposed to option #3.

I suppose there is a fourth option, although it would run contrary to RFC6962:
require logs be accessible over unencrypted HTTP, much like how OCSP and AIA
must work over unencrypted HTTP to avoid circular dependencies.

Regards,
Andrew

[Ryan Sleevi]

On Tue, Apr 25, 2017 at 12:54 PM, Andrew Ayer <ag...@andrewayer.name> wrote:

I haven't seen anything proposed that would eliminate the need for STH

observation and gossiping.

The proposal to required stapled proofs to STHs, and those STHs being blessed, reduces the general observation/gossip into a much more narrower set of participants. That is, the proposal relied on, for example, there being a 'blessed' or 'authentic' view provided by Mozilla, Google, Apple, etc - and that proofs must be included to those blessed places.

The ability of a split tree view can then be quantified against that.

 

> For this specific case, my own thinking about the priorities of
> constituencies are:
> 1) Optimize for CAs (so they can log precerts & OCSP responses) &
> their ease & clarity
> 2) Optimize for servers (so they can do the TLS extension method of
> SCTs)
> 3) Optimize for Monitors (so they can watch for certs) & their ease &
> clarity
> 4) Optimize for Auditors (so they can watch the behaviour)
>
> In this case, priorities 1&2&3 seem to strongly benefit from explicit
> certs, and only a subset of #4 are impacted.

A subset of monitors could be impacted also, should someone want to
distribute a CT monitor as a browser extension. 

While possible, I think that would be unwise, both from a performance and reliability view, so that doesn't seem like a particularly exciting use case. That is, I can see nothing good from having a billion clients all trying to mirror logs. You can see that reflected in the majority of decisions made re: Chrome's implementation.

 

I also wouldn't say that
monitors "strongly" benefit from explicit certs as opposed to option #3.

I suppose there is a fourth option, although it would run contrary to RFC6962:
require logs be accessible over unencrypted HTTP, much like how OCSP and AIA
must work over unencrypted HTTP to avoid circular dependencies.

Right, it's good to note that as an option, but as noted on past threads, that doesn't really achieve much from privacy of clients, so doesn't really seem at all useful or desirable, especially when dealing with the aspects of unsigned messages. 

[Eran Messeri]

Ryan's circular dependency argument seems pretty convincing to me - If I understand correctly, the implication is that SSL certificates used by CT Logs are exempt from the Chrome CT policy for certificates. 

Comparing the problem of circular dependency vs. supporting the use-case of a CT monitor as a browser extension, it seems to me that avoiding circular dependency is the more important goal as it simplifies the overall ecosystem.

As a side note, I think allowing Logs to be accessible over HTTP is not a good idea for two reasons:

* Confidentiality: Log Clients ask Logs questions that contain private information. It's important that they can do so confidentially.

* Integrity: monitors would like to know that a 4xx/5xx response received from a log was indeed generated by the log itself, not an attacker on the path that introduces noise.

Eran  

--

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+unsubscribe@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/CACvaWvZNTrbBLi4WKfBdOf-notgo%2BuqxVUKc-9y1STTAOSdgOg%40mail.gmail.com.

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 8:56 AM, Eran Messeri <er...@chromium.org> wrote:

Ryan's circular dependency argument seems pretty convincing to me - If I understand correctly, the implication is that SSL certificates used by CT Logs are exempt from the Chrome CT policy for certificates. 

I'm not sure that sounds correct, but perhaps you meant in the context of #2. That is, if explicitly provided as part of log metadata/inclusion request, yes.

 

Comparing the problem of circular dependency vs. supporting the use-case of a CT monitor as a browser extension, it seems to me that avoiding circular dependency is the more important goal as it simplifies the overall ecosystem.

As a side note, I think allowing Logs to be accessible over HTTP is not a good idea for two reasons:

* Confidentiality: Log Clients ask Logs questions that contain private information. It's important that they can do so confidentially.

* Integrity: monitors would like to know that a 4xx/5xx response received from a log was indeed generated by the log itself, not an attacker on the path that introduces noise.

Yup. I seem to recall a discussion (either on ct-policy@ or TRANS) regarding the property being obtained here via HTTP 

[Eran Messeri]

On Wed, Apr 26, 2017 at 2:06 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Wed, Apr 26, 2017 at 8:56 AM, Eran Messeri <er...@chromium.org> wrote:

Ryan's circular dependency argument seems pretty convincing to me - If I understand correctly, the implication is that SSL certificates used by CT Logs are exempt from the Chrome CT policy for certificates. 

I'm not sure that sounds correct, but perhaps you meant in the context of #2. That is, if explicitly provided as part of log metadata/inclusion request, yes.

To avoid the circular dependency described (where a CT log may struggle to bootstrap itself because it needs other logs to log its own SSL certificate and issue SCTs), does it not mean that the entire chain used by the Log (from the trust anchor declared by the Log Operator, to the end-entity certificate presented in connections to the log itself) not contain SCTs?

What am I getting wrong here?

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 9:56 AM, Eran Messeri <er...@chromium.org> wrote:

On Wed, Apr 26, 2017 at 2:06 PM, Ryan Sleevi <rsl...@chromium.org> wrote:

On Wed, Apr 26, 2017 at 8:56 AM, Eran Messeri <er...@chromium.org> wrote:

Ryan's circular dependency argument seems pretty convincing to me - If I understand correctly, the implication is that SSL certificates used by CT Logs are exempt from the Chrome CT policy for certificates. 

I'm not sure that sounds correct, but perhaps you meant in the context of #2. That is, if explicitly provided as part of log metadata/inclusion request, yes.

To avoid the circular dependency described (where a CT log may struggle to bootstrap itself because it needs other logs to log its own SSL certificate and issue SCTs), does it not mean that the entire chain used by the Log (from the trust anchor declared by the Log Operator, to the end-entity certificate presented in connections to the log itself) not contain SCTs?

What am I getting wrong here?

There's no reason that it _not_ contain SCTs. Simply that it isn't required to, if the root is explicitly specified.

There's a big difference between "MUST NOT" and "MAY" :)