Re: [Ilc] Clarifications and thoughts purpose of ILC list

[Ben Laurie <[e-mail]>]

On 28 February 2017 at 02:22, David Mazieres
<[e-mail]> wrote:
> Ben Laurie <[e-mail]> writes:
>
>>> The canonical guide is of course the whitepaper, which is probably hard
>>> to read:
>>>
>>>         https://www.stellar.org/papers/stellar-consensus-protocol.pdf
>>>
>>> Maybe the most accessible rendition right now is my Google tech talk:
>>>
>>>         http://www.scs.stanford.edu/~dm/20160606-scp-talk.pdf
>>>         https://www.youtube.com/watch?v=vmwnhZmEZjc&feature=youtu.be
>>
>> OK, this was very helpful.
>>
>> I was struck by your remark that enumerating the set of bad things
>> that might happen to you is exponential time. At least, I think you
>> said that. That doesn't seem like a great security property.
>
> I don't remember exactly what I said, but this is a general property of
> threshold systems.  For example, in f-out-of-3f+1 PBFT, the number of
> failure modes is going to be approximately (3f+1)!.  But that's okay
> because there's a symmetry to it.  Similarly, if you say, "I'm
> vulnerable if every bank at which I have deposits and 2/3 of the other
> big banks act maliciously," that might be a reasonable policy even if
> it's hard to enumerate all the subsets matching that criterion.
>
> Another thing I might have said is that if you got a global snapshot of
> arbitrary quorum slice choices and wanted to decide if there was quorum
> intersection, that would be akin to deciding satisfiability (best known
> algorithm exponential).  But A) quorum slices shouldn't be arbitrary,
> and B) not all forks are bad from ever individual node's
> perspective--the important thing is to avoid being forked from people
> you consider important.
>
> That said, the stellar-core sotware does have some options like
> "--inferquorum", "--checkquorum", and "--graphquorum" that print a
> sample quorum or show quorums based on actual history (which is
> obviously much smaller than every hypothetical potential history).  Such
> options are useful to spot-check one's intuition about policy, but they
> aren't comprehensive.
>
>>> My understanding of CT may be out of date, but I thought CT was a
>>> disjunctive system, as in any log can vouch for a certificate.  As I
>>> envision Internet-level consensus, you could insist on, say, 7 out of 10
>>> log authorities signing off something that guarantees publication of the
>>> certificate.
>>
>> In practice, this is how CT works - Chrome has a policy on what logs
>> must be used, for example. Full details here:
>> https://www.chromium.org/Home/chromium-security/certificate-transparency.
>>
>> Obviously, if you are Joe Random, you can insist on some other policy.
>> But the world is unlikely to provide it for you.
>
> What you say necessary for certificate transparency because CT has to
> "fail open" in the sense that logging is required while auditing the
> logs is optional.  That is absolutely the correct design for TLS
> certificates right now.
>
> However, there are other potential applications where auditing should be
> mandatory.  If is, then it becomes possible for Joe Random to insist on
> another policy.
>
> Here's an example:  Suppose RedHat and Debian start keeping logs of
> every package they release, including package revocation messages for
> packages found to have a vulnerabilities after they are released.
> Furthermore, RedHat and Debian collaborate on some Internet-level
> consensus to guarantee that their logs are append only.  Now suppose Joe
> Random doesn't trust either RedHat or Debian.  Fortunately, the EFF
> unilaterally decides to participate in consensus to help validate these
> package logs.  By trusting a conjunction of RedHat, Debian, and the EFF,
> Joe Random can gain greater assurance that he is not installing some
> secret Trojan package that wasn't part of a mainstream Debian or RedHat
> release.

OK, but that seems equally doable with a CT-like mechanism. The EFF
either constructs its own version of the RedHat and Debian logs, or,
much more efficiently, keeps a log of their log heads...

>
>>> Well, in my ideal world the browser vendors would ship some reasonable
>>> default, but if I'm paranoid, I can add the ACLU and EFF, etc.  More
>>> importantly, it should not be a pure disjunction where any CA can issue
>>> any certificate, but rather should require some threshold.

Thinking about this again, I'm not quite sure what you mean here: a
threshold of what? Logs of certificate issuance? I don't see how that
would prevent a CA issuing any cert it wants?

>>>  Here we are
>>> veering into CT 2.0 territory, because that's not how certificates
>>> currently work, but there are other transparency applications that could
>>> use such a threshold model from the start.
>>
>> OK, I am up for some kind of pluggable "what is the consensus"
>> infrastructure, but what you propose here is a major departure from
>> how things work right now. Such departures are hard.
>
> To be clear, the last thing I am arguing for is in any way holding back
> or changing the current design and deployment of CT.  However, for other
> applications with fewer legacy requirements, it would be possible to get
> stronger consensus.  And if such a consensus infrastructure works out,
> it might be something appealing to CT in the future, or maybe some
> auditing facility implemented on top of CT.  That's what I mean by the
> vague term "CT 2.0."

Global consensus would help CT by providing a mechanism that prevents
CT logs forking.

>>> What consensus mechanism does Trillian plug into?  I had assumed
>>> Trillian was what an individual authority would do, but I could probably
>>> use some education about the bigger picture.
>>
>> You are correct that Trillian is infrastructure. My vision is that
>> logs would log each other's tree heads. Obviously this is unlikely to
>> be universal, so is in some way the dual of your quorum slices.
>
> So again, without advocating actually changing current CT efforts, what
> if at some point we wanted to standardize not just the logging of
> certificates but their auditing.  The idea would be that if, say, Google
> legitimately obtains a second certificate from a different CA such as
> TurkTrust before their first certificate expires, they submit to the
> audit infrastructure a message signed by their old key saying that this
> was a valid second certificate.  Otherwise, the auditing facility flags
> the new certificate in such a way that browser users get a nasty pop-up
> saying "Either this domain has a new owner, or they lost their key, or
> this is a MITM attack."

This screws people who lost their keys, though - and, as you say, new
owners of domains. And since those will be the usual cases, the only
person it doesn't screw is the MITM.

And is pretty much orthogonal to consensus (other than the log forking problem).

> This would obviously be a very long-term project, but it could improve
> security over the status quo, and by letting any organization replicate
> the auditing process, would allow Joe Random to customize his choice of
> trusted auditors to some conjunction of parties he trusts and the rest
> of the world trusts.
>
> David