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

[Eric Rescorla <[e-mail]>]

On Thu, Feb 2, 2017 at 8:32 PM, Ryan Sleevi <[e-mail]> wrote:

>
>
> On Thu, Feb 2, 2017 at 11:33 AM, Eric Rescorla <[e-mail]> wrote:
>
>> 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.
>>
>
> 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."
>

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.



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

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