On Fri, Sep 4, 2009 at 1:03 PM, Brian May<[email protected]> wrote: > > On Thu, Sep 03, 2009 at 06:22:38PM -0700, Tad Glines wrote: >> As far as I can tell, all wavelet updates >> (ProtocolAppliedWaveletDelta) are signed by the federation host and >> not by the federation remote or the actual client.
All deltas are signed by the wave server to which a client submits the delta, regardless of whether that wave server is the host of the wavelet. (see WaveServerImpl.submitRequest(final WaveletName waveletName, ProtocolWaveletDelta delta, final SubmitResultListener listener) in FedOne). In the current architecture, clients trust their service providers (i.e. wave servers) to correctly handle their data. The federation protocol deals with trust between servers.I expect one day we may support user signatures, but not at this point. >> And, since the delta may be transformed prior to application, any >> client signature of the original delta would not be valid if included >> the wavelet update. The code pointed to above signs untransformed deltas, so this is still viable. >> >> This means that participants have no way of verifying that the >> federation host applied other participants deltas properly. Any server involved in federation can verify that a delta was signed by the server that claims to have signed it (provided they trust the CA's). The assumption is that the hosting wave server can correctly transform and apply deltas (as in they use the correct OT algorithm). If they can't, then those waves are broken (and this can be detected by those servers that have the correct implementation, though of course servers may disagree over who is 'correct', in which case they may ignore each other (*)). Once we have completed standardization of the format in which waves are serialized, we can start comparing hashes over a wavelet's state to add additional safety here. (*) This is also why we're keen to get tests of OT implementation out there to help in the validation of different OT implementations. >> If the federation host maintained both the original and transformed >> deltas, and made them available via history then remote hosts (and >> their clients) could verify the hosts transformations. We did consider using post-transformed deltas for the 'historyHash', but came down on side of pre-transformed deltas. Aside from the arguments given above about detecting incorrect OT implementations, we do anticipate including a hash of the wavelet state (of log(n) expense over the entire wavelet state) as an "advisory hash" to allow detection of bad OT implementations and/or the incorrect application of deltas. >> If the original delta's included both the host/remote signature and >> possible a client signature, then complete verification is possible. >> >> Have I misunderstood how OT works? Are there plans to extend >> verification beyond the federation host? You make good points, I think you slightly misunderstood where the signing happens. I think there is scope for more parts of the system being verifiable. > > I still don't understand what verification is, as currently implemented, > possibly because I haven't tried to yet to read up on it (I assume there > is a white paper or something?) Unfortunately the best doc we have so far is the draft protocol spec and the code. > However I can point out that a number of people on the sandbox have been > requesting the ability to sign/encrypt content so the recipients > can verify the validity of the data. Signing is supported, though there are a few bug fixes in the pipeline. > To counter this, it has been pointed out that wave server to server > communications could occur over SSL (I suspect this isn't the case yet > though). > This hasn't helped with the concern is that the system administrators may not > be trustworthy. There is the option of using TLS with encryption between the XMPP servers, though we've been having a few issues with our certificates (for acmewave.com and initech-corp.com). We are working on it, hope to get these configured properly soon. regards, Jochen Bekmann Software Engineer, Google Wave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
