Open Stack

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

Because we're discussing and hashing out your proposal.

On IRC, we've already had the discussion that I should clarify the public-key proposal in a similar document to the one you've written. Once that is written, I'd appreciate your feedback.

I'm also not strictly indicating that a public-key solution is right. I'm doing an If-by-whiskey / devil's advocate. I do believe there are strong advantages to using PKI, but I also see the advantages your solution provides - even if we need to work out some details and highlight some of its limitations.

Scale issues are pretty important, as is discussion to make sure it is done right.  Simply having the conversation, is important.

> >  
> > Potentially as part of the keying, but yes, this is a challenge.  
>  
> Do you have a solution to propose that we can evaluate ?
Well, X.509 certificates don't support multiple signatures. My original proposal was to use OpenPGP, which does. Those signatures could be mapped to policies.  I haven't hashed out an equivalent solution for X.509 yet. Either way, policy is something that was intended for later, so it hasn't been a priority.

> 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.
>  
You mean if Mallory contacts each compute machine, and each compute machine hits the keyserver?

Keyservers can be scaled, so I'm not so concerned, but you're right that there is some risk here.
>  
> > 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.
>  


I meant the keyserver software itself. Your keyserver needs to be a custom built to purpose service. To scale that keyserver, you'll need to run more of them. Maybe you can deploy some HTTP proxies for caching. This is additional infrastructure for organizations to support and organizations will only add as much as they can afford to.

A PKI-based solution could potentially allow a pluggable keysever component that might be scaled in a variety of ways that may leverage existing infrastructure.  DNS, Swift, etc…

However, to play devil's advocate against myself, if the PKI solution doesn't *also* use a custom built-to-purpose service as a keyserver, it complicates the revocation story.

At least, perhaps, with PKI we do open the possibility of a pluggable keyserver mechanism and changing the keyserver solution -- whereas the shared-key solution will need to be much more baked-in and tightly-coupled?

Regards,
Eric Windisch