On Mar 8, 2009, at 1:07 AM, Noah Slater wrote:
This is an interesting idea, but surely document level signing is
something that
sits at the application level, not the database level.
Yes, that's why I sent this to user@ instead of d...@. :)
It's kind of a middleware feature: not part of the db itself, but
common enough that many different applications may want to use it. So
it would be nice to have a system that wasn't part of a specific app.
I'm not sure that I would replicate from an untrusted node, unless I
was prepared to deal with the consequences.
This isn't about trusting nodes, it's about trusting documents. In a
distributed system, a document you receive from me will often not have
been created by me. Even if you trust me, do you trust all the nodes
that I replicate from? Or the ones they replicate from? (And do you
trust there isn't some malware on my system overwriting crucial
payload bytes inside my DB file?)
The only way to trust the entire network of nodes is to own all of
them. This works great if you're using replication in a locked-down
data center, but not elsewhere.
If I did want to make sure of the identity of the node I was
replicating with I would either tunnel over a secure connection
using hosts keys or proxy through an SSL gateway with server/client
certificates and an ACL.
SSL connections are valuable for privacy, but in a message-passing
system they don't do anything for authentication of content. As an
analogy: you probably use an SSL connection to receive your email from
a trusted mail server. But somehow you still get spam with forged
headers. The solution to this is S/MIME, which involves signing the
messages.
Conversely, if the messages are signed, it saves you from having to
trust the messenger. This is really convenient, as you can make use of
any reachable nearby node to help relay messages, even if it's a
nearby stranger's laptop at the café. (You can trust your snail mail
because the envelopes are sealed, even though you don't know your
mailman.)
—Jens
