[145420] in cryptography@c2.net mail archive
Re: A mighty fortress is our PKI
daemon@ATHENA.MIT.EDU (Paul Tiemann)
Tue Jul 27 23:11:56 2010
From: Paul Tiemann <paul.tiemann.usenet@gmail.com>
In-Reply-To: <E1OdksF-0003ua-ID@wintermute02.cs.auckland.ac.nz>
Date: Tue, 27 Jul 2010 19:06:28 -0600
Cc: cryptography@metzdowd.com
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
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. =20
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. =20
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. =20=
> 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.
>=20
> 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@metzdowd.com
