Hey Al, Thanks for chipping in. I'm not surprised to hear that this stuff is not novel :)
Since I've got you here, here's one thing I'm confused about: Why don't you have the same reliability problems with SCTs? Before you issue the SCT, you've got to be really sure that you've got that cert and it's going to make it into the log. The only difference we're talking about here is that in addition to that append operation, you also have a read operation. Either way, you have a stack of things you're appending to, either a stack of just certs or a stack of (cert, frontier) pairs. In the SCT case, you have to reliably push a cert onto the stack. In the no-MMD case, you have to peek at the top of the stack to get the last frontier, then push the new (cert, frontier) pair. That does extend the scope of the transaction a bit, but it certainly doesn't seem like it should take you from "effectively instantaneous" to "we'll get back to you tomorrow". Am I misunderstanding how reliability works for SCTs? If you have a reliability problem with updating the tree in this way, don't you already have a reliability problem with SCTs? --Richard On Fri, Mar 3, 2017 at 5:19 AM, Al Cutter <[email protected]> wrote: > I thought I'd throw a few things into the discussion... > > So, I think what Richard, Nick and Zakir have reinvented, is more or less > the original plan for how CT was going to work; chains would be submitted, > and the caller would be told either a) here's your inclusion proof+STH, or > b) come back and try again in a bit. > At that time, CAs were understandably wary of blocking their issuance on > processes with an unbounded (or at least slightly hand-wavy) deadline. > Enter SCTs, which we we all know and, um, love. > (You all probably knew that already, and if you've been following or > involved with CT for a while also probably know a lot of the trade-offs > that we made in our Google log implementation, mostly swapping speed and > comfort for quite paranoid levels of redundancy.) > > As I said during the talk Pierre and I gave at the start of the CT policy > days about running logs at scale, personally, I really like the idea of > serving proofs directly (I think I said something along the lines of it > holding a special place in my heart) and I suspect that's at least in part > what's triggered this to resurface. > > To detour for a moment, Richard's right in that you certainly can update > Merkle trees in real time, and very quickly - in fact, if you forgo the > full-fat Merkle tree and use what we term a "compact" merkle tree (see > github [1] for details - I believe this is what Richard describes as his > "frontier" tree), then you can update it at many hundreds of thousands of > qps, when you start trying to actually store and sign things it slows down > a fair bit, but depending on storage layer/layout/and whatnots you could > still reasonably expect to be able to do many thousands per second. > Obviously as you crank the hypothetical lever away from "low reliability" > (perhaps not really useful* in the current CT system, but impressively > fast) over to "reliable and globally consistent" things slow down further, > but our recent experiences with Trillian suggest that you can still do this > sort of thing at multiple hundreds to a couple of thousand qps if you're > willing to batch a bit (Trillian has levers too, in particular to trade off > between throughput, scale, and low integration latency, but we need to do > more testing to better understand the full implications.) > > Back to the policy day; the next thing I said after sharing my wistful > dreams, was that I felt that in order for anything like those dreams to > become reality there would need to be changes in the ecosystem, the ones I > called out in particular were that we'd need to have many logs, and that > they'd need to be open. The reason for this, which I think I didn't go > into any detail about and Ryan has touched on above, is because cold hard > operational reality has a habit of crashing through the door whenever > there's something I'd like to have - things like machines failing, software > updates (even rolling ones), bugs, master elections, network partitions, > and Stuff, all mean that you will not *always* be able to have your > throughput, and there *will* be stretches of time you are completely unable > to update your tree (I'm assuming the local/global level is pulled over > towards the global side here). If the ecosystem has sufficient open logs > and CAs were all attempting to log in parallel to sufficiently large subset > of those, they maybe that's fine and it turns out to be overwhelmingly > likely that there are enough logs not having a bad day for the world to > roll on. > > I think none of this dream world is in conflict with the current state of > -bis, other than possibly that requirement to limit STH issuance to one per > hour. I understand why it got put in, but I do wonder if it really belongs > in the Gossip doc rather than -bis where it's potentially discouraging This > Sort of Thing. > > Anyway, I just thought I'd chip in with some colour. > > > [1] https://github.com/google/certificate-transparency/blob/ > master/cpp/merkletree/compact_merkle_tree.h > > On Fri, Mar 3, 2017 at 5:37 AM, Ryan Sleevi <[email protected]> wrote: > >> >> >> On Thu, Mar 2, 2017 at 5:38 PM, Richard Barnes <[email protected]> wrote: >> >>> On Thu, Mar 2, 2017 at 8:04 PM, Ryan Sleevi <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Thu, Mar 2, 2017 at 3:58 PM, Richard Barnes <[email protected]> wrote: >>>>> >>>>> In any case, we should stop thinking that log delay and the MMD are >>>>> essential properties of this system. >>>>> >>>> >>>> I'm confused by this conclusion, and apologies if I've misunderstood. >>>> >>>> Can you explain how this statement differs, from say a discussion about >>>> keeping a database in RAM and never flushing to disk? You can have amazing >>>> QPS - but terrible reliability. It sounds like you're describing that >>>> you've built an unreliable, but efficient, system, and are using that as >>>> proof that reliability is not a critical property? >>>> >>> >>> That's part of why I used Spanner as one of our test points. At least >>> according to Al at the CT policy days, that's what his team is using as >>> storage for their logs. So presumably it's suitably reliable? >>> >>> I'm definitely willing to admit there's a trade-off here. My point is >>> just that the reliability requirements are not inconsistent with a >>> sufficiently high transaction rate to serve existing needs. >>> >> >> Again, I'm confused as to how you reach that conclusion, so apologies if >> I'm just dense here. >> >> You've compared an extremely reliable, globally consistent storage system >> and established one bound (10qps) for your idea. You've then compared an >> extremely unreliable, globally inconsistent storage system and established >> another bound (60qps-200qps) >> >> I'm not sure why you've introduced the unreliable system - which has SPOF >> written all over it - or how it relates to this proposal. Are you >> suggesting that reliability is no longer necessary? >> >> Assuming reliability is necessary, and we accept 10qps for 'extremely >> high' reliability, and 60qps for 'extremely low reliability', doesn't your >> solution only provide value iff the growth rate of the ecosystem is >> somewhere within these bounds? Are you asserting that "10-60 qps should be >> enough for everyone"? >> >> I guess what I'm trying to figure out is what the consequence of this >> experiment is - are you proposing change? Because aren't those bounds only >> relevant to the specific experiment you did, which is related to your >> proposed solution for STH-on-every-cert? >> >> I apologize if I'm simply dense from what this implementation feedback is >> related to, or understanding the objective of this experiment. You suggest >> it may be feasible, but I see those numbers and reach the opposite >> conclusion, so I'm trying to understand where I'm misunderstanding. >> >> _______________________________________________ >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans >> >> >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
