[ticker-dev] ticker-3.0 spec - Replace on Message ID ( Keys ? ?)

[David Arnold]

-->"Ian" == Ian Lister <ilister at dstc.edu.au> writes:

  Ian> What's the problem with rekeying? As long as you have one key
  Ian> left (the original seed or its first generation) you can send a
  Ian> verifiable new key, no?

you can send a new key in a message "authenticated" by a key from the
previous sequence.

there are two possible attacks that i can think of: single server and
federated servers.

across a federation, it's easy: the malicious client attaches to the
sender's server and to the receiver's server, short-circuiting the
federation link (or links).

the attacker receives the re-key message, and replaces the legitimate
new-sequence key with its own, and injects that message into the
receiver's server faster than it traverses the federation.

within a single server, a lot depends upon the order of delivery, size
of queues, etc, but essentially the same attack is *possible*,
although unlikely to succeed.

  Ian> There is of course a problem if you miss any notifications...

yep.  although you do *notice* the loss ;-)


  Ian> You don't need to do it out of band. You just send your public
  Ian> key with your messages and consumers can verify that subsequent
  Ian> messages were signed by an entity holding the same private key
  Ian> as that which signed the first message.

does this actually get you any greater confidence than using a
producer-scheme key?  in both cases, all it proves is that the message
sender(s) had access to the same private key?


  >> if you trust the first message, why would you not trust a
  >> replacement with equivalent "credentials" ?

  Ian> I may be happy to receive it, but not necessarily for it to
  Ian> destroy or cause another message to be obscured.

i think that is less a security issue and more a GUI/policy issue.  





d