Re: A mighty fortress is our PKI

2010-07-25 Thread Paul Tiemann

I admit there are areas of XS* in practice which I do not understand perfectly. 
 Can anyone think of a specific vulnerability here?

As for config problems, you have to weigh the risk of downtime due to running 
your web presence in one datacenter versus running it at 15+ locations 
simultaneously via Anycast.  There is always going to be a risk of _something_ 
happening that can take your site offline.  Running high volume or high profile 
sites out of multiple locations seems to be a growing practice though.

CDNs running anycast are facing another big problem: There's not much IPv4 
space left to go around.  To run anycast you'll need to have a /24 at a 
minimum.  Even if you put one SSL certificate on each of your spare IP 
addresses, you're only going to be able to run 254 certificates per block.  
What if you eventually have a few thousand customers?  Two realities deserve 
explicit mention: 

1) Most CDNs are new entities, started up long after the days when individuals 
could get their own giant netblock assignments.  Most CDNs are not sitting on 
their own /16s.
2) Most CDN customers are big enough to be running an SSL certificate on their 
main site, and if they are serving all their images and other media content via 
the CDN, they will _need_ to have SSL on the CDN or they're going to run into 
Insecure mixed content warnings when their HTTPS content refers to HTTP 
content on the CDN.

Should having an SSL certificate on your CDN cost you more per month than your 
bandwidth costs, and consume lots of IPv4 space?  What is an appropriate amount 
of SAN entries in one certificate?  Are two unrelated domains too many?  What 
about twenty or fifty?  I can tell you at the moment that we're considering 
putting a cap of somewhere between 25 and 50 on the number of SAN entries 
allowed in one certificate.  Would that solve the problem?  I'd really like 
more feedback on how to improve this.  

 (For the TLS folks, SNI (a client-supplied Server Name Indication when it
 connects) won't fix this because (a) it's not widely-enough supported yet and
 (b) the server admin would have to buy 107 separate certificates to do the
 job that's currently done by one Sybil certificate, and then repeat this for
 every other Sybil certificate they use).

True for (a) which makes it a bit of a show stopper for SNI at the moment, but 
(b) is not so problematic due to the internal automation that is likely to be a 
pre-requisite for managing many certificates across multiple locations.

I appreciate the chance to participate in the discussion.  We're very open to 
considering the risks, and not afraid to make changes based on feedback like 
this.  From my call with Edgecast I can tell you they feel the same way, and 
they're willing to make changes to improve.  

All the best,

Paul Tiemann
CTO, DigiCert, Inc.
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI, Part II

2010-07-27 Thread Paul Tiemann
On Jul 27, 2010, at 3:34 PM, Ben Laurie wrote:

 On 24/07/2010 18:55, Peter Gutmann wrote:
 - PKI dogma doesn't even consider availability issues but expects the
  straightforward execution of the condition problem - revoke cert.  For a
  situation like this, particularly if the cert was used to sign 64-bit
  drivers, I wouldn't have revoked because the global damage caused by that is
  potentially much larger than the relatively small-scale damage caused by the
  malware.  So alongside too big to fail we now have too widely-used to
  revoke.  Is anyone running x64 Windows with revocation checking enabled and
  drivers signed by the Realtek or JMicron certs?
 One way to mitigate this would be to revoke a cert on a date, and only
 reject signatures on files you received after that date.

I like that idea, as long as a verifiable timestamp is included.

Without a trusted timestamp, would the bad guy be able to backdate the 

Paul Tiemann
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
On Jul 27, 2010, at 1:14 PM, wrote:

 False metrics are rampant in the security industry. We really need
 to do something about them. I propose that we make fun of them.
 You might consider joining us in D.C. on 10 August at
 --dan, program committee

Wow, I was just going to recommend Dan's book, Security Metrics.

Anyone tasked with quantifying actual security should read his book.  There's a 
pretty good dissection of ALE, and a fantastic few chapters about building a 
balanced scorecard to measure your operations from more perspectives than just 
dollars and cents.

When I read that link, the joke about the spherical cow popped into my 

Paul Tiemann

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
 Haven't we already decided what to do: SNI?
 But isn't that the problem, that SNI had to be added therefore it isn't
 everywhere therefore site operators don't trust its presence therefore
 SNI is irrelevant?

It appears Apache supports SNI as of 2.2.12 which was released 12 months ago.

 Do we have any information as to which browsers in significant current
 use don't support SNI?  Hopefully at some point site operators could
 declare that browsers that don't support SNI will not be supported.

The worst of the show stoppers is IE on Windows XP.  No SNI support.

IE6 is still at 7.2% as of June 2010.  It was 14.4% in June 2009.

... is it possible to help IE6 and other non-SNI browsers to die faster?

 Perry suggested reading Orwell's essay, Politics and the English Language.  
Think about Orwell's opening sentence:

Most people who bother with the matter at all would admit that the English 
language is in a bad way, but it is generally assumed that we cannot by 
conscious action do anything about it.

Now replace the English language with PKI


There is a long list of flyblown metaphors which could similarly be got rid of 
if enough people would interest themselves in the job; and it should also be 
possible to laugh the not un- formation out of existence*...

*One can cure oneself of the not un- formation by memorizing this sentence: A 
not unblack dog was chasing a not unsmall rabbit across a not ungreen field.


There is a long list of outdated browsers which could be got rid of if enough 
people would interest themselves in the job.

One fast way to pressure technological change is for the world to move on to 
better things and leave the legacy stuff behind.  Who uses Netscape 4 or IE 5 
any more?  Those were left behind because everyone in web design wanted CSS 
support and just started using CSS.  The web design field desperately wants to 
be throwing IE6-is-dead parties.  Could some intelligent web designers come up 
with a few snippets of code in the various web flavors (PHP, ASP, JSP, etc) for 
people to easily install and include on their sites (as part of a movement to 
discourage old browser usage and encourage better security on the web...)  If 
an old browser is detected, a friendly warning message or even an error message 
appears, along with links to the site explaining the movement...  Of course it 
would only be grassroots, but I've heard enough rumbling on web designer blogs 
to think that someone might just take up a cause like that.  The security 
community could encourage it maybe?  Put a Paypal button on there.  I know a 
lot of people who would donate money.  

Looks like at least one site is out there: but has no 
Paypal donate button, and doesn't offer newcomers the reasons they should 
switch to something more modern.

Maybe this is too utopian.  But laughing does work, sometimes.

Paul Tiemann
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI

2010-07-27 Thread Paul Tiemann
 **  But talking about TLS/SNI to SSL suppliers is like talking about the
 lifeboats on the Titanic ... we don't need it because SSL is unsinkable.

Apache support for this came out 12 months ago.  Does any one know of 
statistics that show what percentage of installed Apache servers out there are 
running 2.2.12 or greater?  How many of the top 10 Linux distributions are past 

A CDN might be able to push SNI forward for its own platform, but mass adoption 
isn't coming until we also have broad compatibility among the client browsers.  
SSL certs as they are currently being used are not good for much if they cause 
a bunch of browser warnings, so I can't see how you could really expect SSL 
suppliers to blast holes in their own Titanic.  New standards are wonderful, 
but who can use them until they're well supported?

This page says iPhone IOS4 supports SNI.  That just came out.

 ... or talking to PKI standards groups about adding a CRL reason code for
 certificate issued in error (e.g. to an imposter).  This was turned down
 because CA's never make mistakes, so there's no need to have such a reason

I wasn't around when this happened, but maybe revoking for Key compromise was 
considered just as good.  And maybe it's rare enough not to need its own 
special if() statement in all the browsers.  The browsers don't really do 
different things based on the reason code anyway (to my knowledge) 

Paul Tiemann
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI

2010-07-27 Thread 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:

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

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI

2010-07-28 Thread Paul Tiemann
On Jul 26, 2010, at 10:22 PM, Chris Palmer wrote:

 Perry E. Metzger writes:
 All major browsers already trust CAs that have virtually no security to
 speak of,
 ...and trust any of those CAs on any (TCP) connection in the (web app)
 session. Even if your first connection was authenticated by the right CA,
 the second one may not be. Zusmann and Sotirov suggested SSL pinning (like
 DNS pinning, in which the browser caches the DNS response for the rest of
 the browser process' lifetime), but as far as I know browsers haven't
 implemented the feature.

I like the idea of SSL pinning, but could it be improved if statistics were 
kept long-term (how many times I've visited this site and how many times it's 
had certificate X, but today it has certificate Y from a different issuer and 
certificate X wasn't even near its expiration date...)

Another thought: Maybe this has been thought of before, but what about 
emulating the Sender Policy Framework (SPF) for domains and PKI?  Allow each 
domain to set a DNS TXT record that lists the allowed CA issuers for SSL 
certificates used on that domain.  (Crypto Policy Framework=CPF?) IN TXT v=cpf1 /^DigiCert/ -all

Get the top 5 browsers to support it, and a lot of that any CA can issue to 
any domain risk goes way down.

Thought: Could you even list your own root cert there as an http URL, and get 
Mozilla to give a nicer treatment to your own root certificate in limited scope 
(inserted into some kind of limited-trust cert store, valid for your domains 

Is there a reason that opportunistic crypto (no cert required) hasn't been done 
for https?  Would it give too much confidence to people whose DNS is being 

 A presentation I've given at a few security gatherings may be of interest. I
 cover some specific security, UI/UX, and policy problems, as well as some
 general observations about incentives and barriers to improvement. Our
 overall recommendation is to emulate the success of SSH, but in a browser-y,
 gentle-compliance-with-the-status-quo-where-safe way.

Great slides!  The TOFU/POP is nice, and my favorite concept was to translate 
every error message into a one sentence, easy-to-understand statement.

Paul Tiemann
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI

2010-07-28 Thread Paul Tiemann
On Jul 27, 2010, at 10:58 PM, wrote:

 Wow, I was just going to recommend Dan's book, Security Metrics.
 It is actually Andy Jaquith's book, I only wrote the intro.

Ouch, I'm sorry for the mistake!  (I knew I remembered your name in connection 
with the book, but it's on my bookshelf in the office and I was at home.)

 In the meantime, though, couple of years ago I did a tutorial
 on security metrics which you may find useful

Thanks, my favorite so far is page 45 with the table on Risk Management 
Culture.  I need to tape that to the wall for inspiration.

Pathologic: Don't want to know
Bureaucratic: May not find out
Generative: Actively seek

Pathologic: Failures punished
Bureaucratic: Local repairs only
Generative: Failures beget reforms

From my point of view: The security community is being Generative (Actively 
seek) about finding the flaws in systems, but it's too often in the Pathologic 
(Failures punished) stage about how to handle those flaws once they're 

My suspicion: It's fun to Actively seek, and hard to find solutions, and it can 
be downright frustrating to champion reforms.  If the vulnerability isn't 
gigantic, it's hard to even get people to listen.  Reform is maybe 20x harder 
and 1/5th as fun as poking the holes.

That said, here's an experience worth talking about: Dan Kaminsky did a pretty 
good job of being Generative in _both_ categories.  He found a hole in DNS, and 
then worked with LOTS of vendors and even with people not directly tied to DNS 
to collaborate on reforms.  He even called me (at a smaller CA) to make sure we 
were aware of the risks and to verify that we don't only rely on automated 
forms of verification.  I really appreciated the call--it felt like my chance 
to talk to a rock star.

All the best,

Paul Tiemann 
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to

Re: A mighty fortress is our PKI, Part II

2010-07-28 Thread Paul Tiemann
On Jul 28, 2010, at 9:51 AM, Peter Gutmann wrote:

 Nicolas Williams writes:
 Exactly.  OCSP can work in that manner.  CRLs cannot.
 OCSP only appears to work in that manner.  Since OCSP was designed to be 100% 
 bug-compatible with CRLs, it's really an OCQP (online CRL query protocol) and 
 not an OCSP.  

This isn't true for all OCSP services.  For example, DigiCert's is not CRL 
based, so it really can say Yes and it really can say Unknown meaningfully.

 (For people not familiar with OCSP, it can't say yes because a CRL can't 
 yes either, all it can say is not on the CRL, and it can't say no for 
 the same reason, all it can say is not on the CRL.  The ability to say 
 vslid certificate or not valid certificate was explicitly excluded from 
 OCSP because that's not how things are supposed to be done).

True for off-the-shelf OCSP responders that base themselves on CRL.

Paul Tiemann

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to