Open Stack

On Fri, 2013-04-26 at 16:52 -0400, Eric Windisch wrote:
> > 
> > Except for encryption you have to do those lookups on the sender
> side
> > too, so you are back to square zero.
> 
> Overall, the encryption situation is not too different in the PKI vs
> shared-key case.
> 
> We shouldn't disregard improvements in signing performance just
> because they don't apply when encryption is used.  Most I've spoken to
> consider encryption a nice-to-have than a need-to-have. Signing seems
> to be the common case.

How comes that you get to wave away any deficiency in the public-key
model but I have to defend any minor nitpick in my detailed
proposal ? :-)

> > Also doing lookup on the receiver you forgo the possibility of doing
> > access control even before allowing to send any message, requiring
> > access control on the receiving end (potentially a second lookup for
> the
> > policy).
> 
> Potentially as part of the keying, but yes, this is a challenge. 

Do you have a solution to propose that we can evaluate ?

> > Also doing lookups on the receiver end you open up to an attack
> where a
> > malicious users sends thousands of messages *seemingly* coming from
> > different sources causing the receiver to try thousands of requests
> > against the server to verify a public key that does not exist.
> > 
> 
> You can DoS a message consumer, period. Hell, if you get this far, you
> can probably DoS the keyservers without too much difficulty.

I think you have not caught the point.

The problem is not in the DoS per se. The problem is that Actor X can
cause any other party to hit the key server and the key server have no
way, on its own, to identify the bogus party, because the bogus party is
concealed behind a legitimate service that is simply trying to find out
who it is talking to.

If you try to DoS the Key Server directly that is easy to foil, just use
rate limiting or even firewall off the offender. But you can't do that
when the DoS comes masked through a legitimate party.

>  With your suggestion, we'll need a specialized application running on
> each keyserver.

Yeah it is called 'a firewall', I think that is available as a stock
component on all the systems we use.

>  That will limit how much you'll reasonably scale the keyservers
> introducing a greater chance of a DoS.

Can you please explain this one ? It makes no sense to me, sorry.

> Overall, DoS of a message receiver by making it query the keyserver
> too frequently is probably not a concern at all, all things
> considered.

In fact that wasn't the concern ...

Simo.

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