A mighty fortress is our PKI

[Paul Tiemann]

Hi Peter,

> I actually
> agree with a lot of the points made in the response, since this wasn't a
> failing of Edgecast or a CA but a problem in the way SSL's PKI (or more
> generally just PKI as a whole) works.  

Yes.  SNI could have been included from the start, but it was probably hard enough back then to get SSL 1.0 or SSL 2.0 out the door.  It's difficult for a CA to push new SSL extensions if SSL clients aren't ready for what's new.

> Because it was designed for the
> purposes of authenticating a single user to the global X.500 directory it
> really doesn't have any provision for Sybil certs (I'm going to keep calling
> them that because we need some sort of label for them :-).

Agreed.  PKI was designed in a time when IPv4 space was a lot more plentiful too, and few had even dreamt of serving from multiple locations via anycast.  A lot of the time (for good or bad) new pressures form around a problem and people invent new ways of using old things.  It's often easier to reuse an older well supported feature of BGP, TCP or even SSL than to go invent something wonderful and new and then wait years for the world to catch up (think SNI.)

The designers of PKI couldn't foresee all possible future uses, and implementation wasn't perfect from the start.  It wasn't until 2007 that the "Subject Alternative Name" started to see mass adoption, and that was due mainly to Microsoft pushing for it (they had supported it since Windows 95!) which ought to be considered a good thing.

I won't object to 'Sybil' as long as it's understood to mean multi-personality and not deception.

> The intent with posting it to the list was to get input from a collection of
> crypto-savvy people on what could be done.  

I'll admit that at first it appeared to have been posted as something to be laughed at.  After reading Perry's recommended Orwell essay, I'm willing to admit that laughing at things can be a way to effect change.  

> The issue had previously been
> discussed on a (very small) private list, and one of the members suggested I
> post it to the cryptography list to get more input from people.  The follow-up
> message (the "Part II" one) is in a similar vein, a summary of a problem and
> then some starters for a discussion on what the issues might be.

Part II was nice.  Shocking and full of thought provoking questions too.

> For example should an
> SSL cert be held to higher standards than the server it's hosted on?  In other
> words if it's easier to compromise a CDN host or (far more likely) a web app
> on it, does it matter if you're using a Sybil cert?  I have no idea, and I'm
> open to arguments for and against.

My technical contention is that it's generally going to be harder to compromise an origin caching CDN host because they do not run any web app code at all:

Pseudo code for a CDN http daemon:

init
while 1:
	read a request
	if already cached: serve the request from cache
	else: fetch from origin, save to cache if cacheable, and serve

If running PHP/ASP/Java/etc then those bets are off, but a CDNs don't do this.  Many CDNs just serve up static (non-origin cached, no POST support) sites.

>> I've spoken with my contacts at Edgecast, and they expressed that they're
>> very willing to consider alternate approaches.
> 
> I'm not actually sure what the "fix" would be for this, or even if there is a
> fix that needs to be made.  Thus the hope to get it discussed on the list.

Well, if nothing else, the smaller certificates might at least help whatever PKI library was getting the segv.

Paul Tiemann
(DigiCert)

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com