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

[David Arnold]

-->"Martin" == Wanicki, Martin <Martin.Wanicki at Australia.Boeing.com> writes:

  Martin> In fact I'd prefer that the replacement option to be key
  Martin> based, so that only the bona fide originator of a
  Martin> notification has the right to recall or change the notif.

oh well. there goes my theory that most people won't care ;-)

  Martin> Yeah, I agree, although if a notif could be *keyed with the
  Martin> plaintext of the replacement id hash it would work, but then
  Martin> I know three fifths of feck-all about security and keys :-(

i played, once, with using this kind of mechanism.  it's actually not
dissimilar to the Bell Labs S/Key protocol.

  1. sender picks the plaintext
  2. sender picks how many times it want to replace the message
     (** this is the bad bit **)
  3. sender hashes the plaintext, and then hashes the result, and that
     result, etc, N times (from step 2).
  4. for the first message, use the final hash and then work
     backwards through previous hashes.

this works because the hash function is one-way, so having seen a
message, a receiver cannot derive the hash of its replacement, but
when it gets the replacement, if its REPLACEMENT field hashes to the
REPLACEMENT of the previous message, it's legitimate.

the big limitation is that the sender need to know up front how many
times you want to do this.

i couldn't figure out a way to do an in-band rekey over a federation
-- a man-in-the-middle attacker could race the legitimate re-key
packet with a malicious re-key packet, and since we don't guarantee
total ordering, the nastygram could win :-(

  Martin> *Keyed : Its my understanding that keys are not a client
  Martin> readable part of a notification and I'm not familiar enough
  Martin> with the api to know if there is a way to throw a key at a
  Martin> routine to check if the notif has this key

keys are not delivered to the client, so you can only check them using
a subscription.

  Martin> Basically i was thinking along the lines of a digital
  Martin> signature. the signatures should match before replacement is
  Martin> done.

but if i can receive the first signature, then i can simply dump those
bytes into a bogus message.  you need to have some content to sign
which varies in a way which only the sender can predict, and the
receiver can verify in-band.

of course, if you're prepared to do an out-of-band signature
verification, then the problem evaporates.  you simply sign all
messages.


  Martin> I really dont know how to solve this but I know i would
  Martin> prefer it to be secure.

there's no such thing as "secure", only degrees of security ;-)

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





d