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

David Arnold arnold at dstc.monash.edu.au
Tue Apr 9 12:24:47 EST 2002


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

  >> 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?

  Ian> Yes, it allows you to verify invidual producers, as opposed to
  Ian> just verifying that the producer is in the (possibly rather
  Ian> large or even infinite) set of producers permitted to send
  Ian> notifications that match a particular subscription.

ok, so that seems to be the crux of the issue.

it would be possible to achieve this by using a subscription together
with key(s) obtained from the sender to achieve the same result, but
you'd prefer to have a single, potentially more broad, subscription,
and do application-level checks on replacement messages.

while this basically introduces a redundant means of authenticating
messages, i suppose it *might* be easier to implement.


  Ian> There's no point in having this mechanism if the original
  Ian> message isn't at least obscured in some manner,

well, i'd debate that too.  i'm perfectly happy with an insecure
mechanism for almost all my tickertape usage, and my current usage of
REPLACEMENT is no exception.

  Ian> but as soon as you allow messages to replace others without
  Ian> appropriate security measures (where I believe `appropriate'
  Ian> means more than just making sure the producer has rights to
  Ian> send to you) you have a potential attack.

right.

i'm happy with that, but i'm reluctant to require a duplicated
mechanism.  

could you explain why you'd prefer this than using multiple
subscriptions and careful handling of the deliveries to achieve the
same result?




d







More information about the ticker-dev mailing list