Subject: Re: [Trans] Update on 6962-bis issues raised by Richard Barnes and EKR

From: "Salz, Rich" <[email-masked]>
Date: Wed, 1 Feb 2017 14:03:00 +0000

> 1. CAs make mistakes but aren't malicious.
> 2. CAs are malicious but logs are not
> 3. CAs and logs are both malicious

The original focus was mainly about catching wrong certs, which was really a focus on CA mis-issuance.  Logs were intended to be a check on that, and monitors and auditors were layers on top that would catch erroneous logs.

Have you read the threat model doc?  I assume yes, but it never hurts to ask.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Feb 2017 20:33:39 +0100

I thought it might be useful to elaborate on what I meant about
threat model and technology for CT. As I mentioned, I think there
are three primary threat models one might be concerned about:

1. CAs misissue but aren't malicious.
2. CAs are malicious or otherwise fail to log but logs are not
3. CAs and logs are both malicious

In threat model #1, what is mostly required is merely that CAs submit
certificates to logs. As long as every CA submits their certs to a
common log than misissuance can be detected without any client side
behavior at all. This is effectively CT as it is implemented for DV
today and as Ben indicates, it has detected misissuance already.

If CAs do not log (either maliciously or through mistake), then it is
necessary for RPs to refuse to accept certificates which are not
logged. However, as long as we believe that the logs behave correctly
(specifically, they never sign an SCT that they don't then log) then
all that is required is that a certificate contain SCTs from some set
of logs and that RPs check that. This is roughly CT as Chrome
proposes to implement as of end-of-2017.  Note that the Merkle tree
infrastructure is not needed here at all.

The final case is the one where logs are also malicious and collude
with a malicious CA to issue an SCT for a certificate but not to log
it. In order to detect this, you need to ensure that RPs have the same
view of the log structure as auditors do, because otherwise the CA can
issue a certificate which will be acceptable to the RP but will never
be audited [0]. The general notion for current CT is that there is
some notion of getting global consensus on the state of the log and
then the auditors and the RPs can know that they are checking the same
thing. This is where the Merkle tree infrastructure comes in (though
as I indicated previously, Richard and I do not believe it adequately
addresses this case).

Note that these are *all* detection use cases, but just detection
under particular threat models.

So, I think the question is: which threat model is this document
intended to address? It seems to me that the charter pretty clearly
comes down on #3, because it talks about "verifiable" logs and defines
verifiable in a way that seems to include log misissuance. But perhaps
I have misunderstood.

-Ekr

[0] This is just about avoiding TOCTOU bugs.

On Wed, Feb 1, 2017 at 7:51 AM, Eric Rescorla <[email-masked]> wrote:

>
> On Tue, Jan 31, 2017 at 7:50 PM, Salz, Rich <[email-masked]> wrote:
>
>> > We don't have consensus.  We're deadlocked and we're not getting
>> > sufficient input from the working group to break the deadlock.
>>
>> Well, yeah, that's why you get paid the big bucks, right? :)
>>
>> > Paul and I can make a decision on the particular question that's a
>> problem but
>> > it probably means an appeal and further delay.
>>
>> That's the process.
>>
>> > Frankly, this working group was chartered under the assumption that the
>> > goal was detection, not prevention.
>>
>> That's my perception as well.  Is there anyone who thinks prevention was
>> part of the scope?
>>
>
> I think this is painting with a bit too broad a brush. One needs to talk
> about
> detection under a specific threat model, as I indicated previously.
> Specifically,
> there seem to be a number of potential threat models:
>
> What technological solution is adequate to detect misissuance depends on
> which
> of these three threat models you think applies.
>
> -Ekr
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Feb 2017 20:33:57 +0100

On Wed, Feb 1, 2017 at 3:03 PM, Salz, Rich <[email-masked]> wrote:

> The original focus was mainly about catching wrong certs, which was really
> a focus on CA mis-issuance.  Logs were intended to be a check on that, and
> monitors and auditors were layers on top that would catch erroneous logs.
>

Yes, I have. I think it does a pretty good job of analyzing the various
cases.

-Ekr

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 2 Feb 2017 20:32:37 -0800

> infrastructure is not needed here at all.

I believe you meant end-of-2016, but given that Chrome hasn't made the
statement you're attributing, it's not fair to say "proposes to implement
as of end-of-2017."

> as I indicated previously, Richard and I do not believe it adequately

It's unclear to me, from your remarks and Richard remarks earlier, whether
you believe this goal is explicitly not achieved under the current
proposals. It seems that you accept the current proposal actually does
address this, but that you're unhappy with there being any window between
issuance and global consensus. That is, there's agreement that the current
model provides detection under a certain set of bounded constraints, but
you want to reduce that.

The rest of Richard's message seems to focus on whether the system is
believed to be sufficiently scalable, but I don't know that there's
consensus with Richard's assertion - that is, that CT is too inefficient to
be deployed at scale. Indeed, much of the calculation seems to be based on
an assumption of a design that tightens the detection window, rather than
alternatives; the point being that the inefficiency Richard notes is itself
an issue with Richard's proposal, not an intrinsic property.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Feb 2017 05:49:06 -0800

> statement you're attributing, it's not fair to say "proposes to implement

I am referring to this statement:
https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/78N3SMcqUGw/ykIwHXuqAQAJ

"This past week at the 39th meeting of the CA/Browser Forum, the Chrome
team announced plans that publicly trusted website certificates issued in
October 2017 or later will be expected to comply with Chrome’s Certificate
Transparency policy in order to be trusted by Chrome. "

As I understand that policy, certificates will be required to contain SCTs
from some
set of logs and Chrome will check that. I apologize if I have
misrepresented the situation
and I would appreciate any corrections or clarifications you may have.

> an issue with Richard's proposal, not an intrinsic property.

It might be better to debate this under the thread where Richard and I
explicitly laid out our concerns
or on the conference call which I understand the chairs to be arranging.
The purpose of this parenthetical
was merely to note those in the context of my understanding of the purpose
of the various components of
the system.

With that said, I don't think that this is quite how I would state my
concern. Even ignoring the question
of detection window, it's not clear to us that there is a scalable story
that actually provides public
verifiability to clients.

-Ekr