Open Stack

On Thu, 2013-04-25 at 17:26 -0400, Eric Windisch wrote:
> >  
> > 2. A random number can repeat but it is very unlikely that will happen
> > if you have a good random generator that has uniform distribution.  
> >  
> > I think you mean 2, because the chance we get out of the hat 2 identical
> > numbers chosen at random within the same hundredth of a second on the
> > same machine if the numbers are big enough, say 2^64, are very, very
> > low, so we might decide to ignore that it may happen.
> >  
> > However, how bad is it is it *does* happen ?
> I mean the latter and I believe this is sufficient. I believe worst
> case is that a message is rejected by the endpoint as a potential
> replay. In theory, we should be pretty resistant to lost messages,
> especially at the very low rate of occurrence we'd expect it.

Well actually thinking about it the chance are infinitesimally smaller
than I previously thought because if we are going to use the signature
to check for replays not only the timestamp and nonce must match, but
the message being sent must be a repeat and exactly identical to othe
previous.

Honestly unless there are condition where it is legit to resend the
exact same message multiple times we should probably just forget about
the nonce, which is why I didn't care for it in the first place.
However base don my last formulation we have a good way to avoid
interprocess locking too.

So given a few people requested it, and to account for the weirdest
possible use of messages where a service decides to send 2 identical
messages in rapid succession I will leave the nonce in.

> I gag any time we mention interprocess locking, global counters, or
> state. I recognize might need to compromise here, especially in regard
> to multiple services on a remote machine receiving the same message,
> although I'd be careful about how we implement that.  The
> implementation details will be vastly different for AMQP, versus
> ZeroMQ.

I am not sure this difference will matter from the signing point of
view.

> For instance, the ZeroMQ driver could do first-pass replay detection
> in the ZmqProxy, which is a machine-global process. We'd still want to
> verify signatures in the consuming services, but as all messages pass
> through the ZmqProxy, it can outright reject duplicates. (This won't
> stop someone from killing the ZmqProxy and doing a MITM to allow
> replays - not but outright injection - but if that happens, the server
> is likely compromised already…)

Are you going to check the signature in ZmqProxy ?

> The AMQP drivers won't be able to filter their replays centrally on
> the host unless it added a per-host consumer and local distribution
> pattern like we use in ZeroMQ. Without that, we'd need a local
> datastore with all the locking issues that brings with it.

I am not sure I am following you here ...

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York