Re: A mighty fortress is our PKI, Part II

[Jerry Leichter]

On Aug 17, 2010, at 4:20 AM, Peter Gutmann wrote:
 Your code-signing system should create a tamper-resistant audit  
trail [0] of

 every signature applied and what it's applied to.

Peter.

[0] By this I don't mean the usual cryptographic Rube-Goldbergery,  
just log
   the details to a separate server with a two-phase commit protocol  
to

   minimise the chances of creation of phantom non-logged signatures.
...thus once again demonstrating how much of good cryptographic  
practice is just good engineering/release management practice.


A number of years ago, in addition to being in charge of much of the  
software development, I had the system management organization of the  
small software maker I worked at reporting to me.  I formalized a  
process that the (already well run) organization already had in  
place.  Any time *any* build of the software "left the building", even  
if just for a demo, we marked that build as "locked".  We would never  
delete a "locked" build without a careful determination that it was,  
in fact, "dead":  No longer in use at any customer. We also,  
within 24 hours, did a special backup of the build onto a tape that  
went into permanent off-site storage.


The one time I know of that we didn't follow these procedures (before  
they were officially put into place), a very large customer, at their  
insistence and after the sales guy who dealt with them swore they  
agreed to delete the copy we gave them, got a snapshot of a build from  
a developer's workstation "just to see how the new version would  
look".  Without telling us, the customer proceeded to roll this out at  
hundreds of sites, resulting in years of support grief, since it was  
impossible for us to determine exactly what went into the code they  
were running.


We were later acquired by a much larger company that claimed they  
would "teach us how to do big-league software engineering".  Hah.   
That company was shipping software built on developer workstations as  
a day-to-day practice - they were just beginning to develop mechanisms  
to ensure that the stuff they shipped came through traceable,  
reproducible builds.  Oh ... but their stuff was in Java, so was  
signed  The signing was tightly controlled at a central location.  Cue  
classic joke about using an armored car to deliver an envelope to  
someone living in a cardboard box.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

A quick followup note on this, I was reading Microsoft's code-signing best
practices document and one comment caught my eye:

  If code is signed automatically as part of a build process, it is highly
  recommended that any code that is submitted to that build process be
  strongly authenticated.

Given that Realtek produce huge numbers of products and therefore even larger
numbers of drivers for different environments (and JMicron probably not much
less so), it's likely that they use a highly automated driver-signing process
to deal with this.  Even if they use "strong authentication" as per the
guidelines, for example making the network share on the company-wide signing
server non-public (i.e. requiring Windows domain authentication), this means
that anyone who compromises any PC on the network can now use the code-signing
server as an oracle.  So there may have been no need to steal the key, just
compromise one developer PC and you can get your malware signed.  So perhaps a
corollary requirement might be:

  Your code-signing system should create a tamper-resistant audit trail [0] of
  every signature applied and what it's applied to.

Peter.

[0] By this I don't mean the usual cryptographic Rube-Goldbergery, just log
the details to a separate server with a two-phase commit protocol to 
minimise the chances of creation of phantom non-logged signatures.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Thor Lancelot Simon  writes:

>If you want to see a PKI tragedy in the making, have a look at the CRLs used
>by the US DoD.

Only "in the making"?

Actually it's all relative, in Japan the Docomo folks turned off CRLs because
they found that even a relatively modest CRL (not just the DoD monsters)
presented a nice DoS when sent over cellular data links.  What happened was
that as the CRLs grew, performance got worse and worse as the phone downloaded
the CRL.  It took them quite some time to diagnose that they were being DoS'd
by their own PKI.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Thor Lancelot Simon]

On Wed, Aug 04, 2010 at 10:46:44PM -0700, Jon Callas wrote:
> 
> I think you'll have to agree that unlike history, which starts out as
> tragedy and replays itself as farce, PKI has always been farce over the
> centuries. It might actually end up as tragedy, but so far so good. I'm
> sure that if we look further, the Athenians had the same issues with it
> that we do today, and that Sophocles had his own farcical commentary.

If you want to see a PKI tragedy in the making, have a look at the CRLs
used by the US DoD.

Thor

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Tom Ritter]

> And what else should Windows say?  "We put this through our time machine and
> noticed that at some time in the past it was signed and now it isn't"?

Absolutely, on initial install there's no way to know it was originally
signed (if you're smart about it).  But in another architecture
Microsoft makes available (ClickOnce) software _upgrades_ that _were_
initially signed - but now are not - do not give indication that
something fishy is going on.

-tom

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[James A. Donald]

On 2010-08-05 11:30 AM, David-Sarah Hopwood wrote:
> Signatures are largely a distraction from the real problem: that software
> is (unnecessarily) run with the full privileges of the invoking user.
> By all means authenticate software, but that's not going to prevent 
malware.


A lot of devices are locked down so that you cannot install bad 
software.  This is somewhat successful in preventing bad software from 
being installed, and highly successful in irritating users.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

Zeus malware used pilfered digital certificate
http://www.computerworld.com/s/article/9180259/Zeus_malware_used_pilfered_digital_certificate
Zeus Malware Used Pilfered Digital Certificate
http://www.pcworld.com/businesscenter/article/202720/zeus_malware_used_pilfered_digital_certificate.html

&

Zeus malware used pilfered digital certificate
http://www.networkworld.com/news/2010/080610-zeus-malware-used-pilfered-digital.html

from above:

The version of Zeus detected by Trend Micro had a digital certificate belonging
to Kaspersky's Zbot product, which is designed to remove Zeus. The certificate 
--
which is verified during a software installation to ensure a program is what it
purports to be -- was expired, however.

... snip ...

Certificate Snatching—ZeuS Copies Kaspersky’s Digital Signature
http://blog.trendmicro.com/certificate-snatching-zeus-copies-kasperskys-digital-signature/

...

there was another scenario of certificate-copying (& dual-use vulnerability)
discussed in this group a while ago. The PKI/certificate bloated payment
specification had floated the idea that that when payment was done with their
protocol, dispute burden-of-proof would be switched & placed on the consumer
(from the current situation where burden-of-proof is on the 
merchant/institution;
this would be a hit to "REG-E" ... and also apparently what has happened in the
UK with the hardware token point-of-sale deployment).

However, supposedly for this to be active, the payment transaction needed a 
consumer
appended digital certificate that indicated they were accepting dispute
burden-of-proof. The issue was whether the merchant could reference some
public repository and replace the digital certificate appended by the
consumer ... with some other digital certificate for the same public key
(possibly digital certificate actually obtained by the consumer for that
public key at some time in the past ... or an erroneous digital certificate
produced by a sloppy Certification Authority that didn't adequately perform
check for applicant's possession of the corresponding private key).

Of course, since the heavily bloated PKI/certificate payment specification,
performed all PKI-ops at the internet boundary ... and then passed
a normal payment transaction with just a flag claiming that PKI-checking
had passed ... they might not need to even go that far. There
was already stats on payment transactions coming thru with the flag
on ... and they could prove no corresponding PKI-checking had actually
occurred. With the burden-of-proof on consumer ... the merchant might
not even have to produce evidence that the appended digital certificates
had been switched.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Jon Callas]

On Aug 4, 2010, at 11:29 PM, Peter Gutmann wrote:

> Jon Callas  writes:
> 
>> But S.J. Perleman's "Three Shares in a Boat"
> 
> Uhh. minor nitpick, it was Jerome K.Jerome who wrote "Three Shares in a 
> Boat". 
> He followed it up with "Three Certificates on the Bummel", a reference to the 
> sharing of commercial vendors' code-signing keys with malware authors.

Oh, well. You are, of course, correct.

Jon

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Jon Callas  writes:

>But S.J. Perleman's "Three Shares in a Boat"

Uhh. minor nitpick, it was Jerome K.Jerome who wrote "Three Shares in a Boat". 
He followed it up with "Three Certificates on the Bummel", a reference to the 
sharing of commercial vendors' code-signing keys with malware authors.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Jon Callas]

On Jul 30, 2010, at 4:58 AM, Peter Gutmann wrote:

> 
> [0] I've never understood why this is a comedy of errors, it seems more like
>a tragedy of errors to me.

That is because a tragedy involves someone dying. Strictly speaking, a tragedy 
involves a Great Person who is brought to their undoing and death because of 
some small fatal flaw in their otherwise sterling character.

In contrast, comedies involve no one dying, but the entertaining exploits of 
flawed people in flawed circumstances.

PKI is not a tragedy, it's comedy. No one dies in PKI. They may get embarrassed 
or lose money, but that happens in comedy. It's the basis of many timeless 
comedies.

Specifically, PKI is a farce. In the same strict definition of dramatic types, 
a farce is a comedy in which small silly things are compounded on top of each 
other, over and over. The term farce itself comes from the French "to stuff" 
and is comedically like stuffing more and more feathers into a pillow until the 
thing explodes.

So farces involve ludicrous situations, buffoonery, wildly improbable / 
implausible situations, and crude characterizations of well-known comedic 
types. Farces typically also involve mistaken identity, disguises, verbal humor 
including sexual innuendo all in a fast-paced plot that doesn't let up piling 
things on top of each other until the whole thing bursts at the seams.

PKI has figured in tragedy, most notably when Polonius asked Hamlet, "What are 
you signing, milord?" and he answered, "OIDs, OIDs, OIDs," but that was 
considered comic relief. Farcical use of PKI is far more common. 

We all know the words to Gilbert's patter-song, "I Am the Very Model of a 
Certificate Authority," and Wilde's genius shows throughout "The Importance of 
Being Trusted." Lady Bracknell's snarky comment, "To lose one HSM, Mr. 
Worthing, may be regarded as a misfortune, but lose your backup smacks of 
carelessness," is pretty much the basis of the WebTrust audit practice even to 
this day.

More to the point, not only did Cyrano issue bogus short-lived certificates to 
help woo Roxane, but Mozart and Da Ponte wrote an entire farcical opera on the 
subject of abuse of issuance, "EV Fan Tutti." There are some who assert that he 
did this under the control of the Freemasons, who were then trying to gain 
control of the Austro-Hungarian authentication systems. These were each 
farcical social commentary on the identity trust policies of the day. 

Mozart touched upon this again (libretto by Bretzner this time) in "The 
Revocation of the Seraglio," but this was comic veneer over the discontent that 
the so-called Aluminum Bavariati had with the trade certifications in siding 
sales throughout the German states, as well as export control policies since 
Aluminum was an expensive strategic metal of the time. People suspected the 
Freemasons were behind it all yet again. Nonetheless, it was all farce. 

Most of us would like to forget some of the more grotesque twentieth-century 
farces, like the thirties short where Moe, Larry, and Shemp start the "Daddy-O" 
DNS registration company and CA or the "23 Skidoo" DNA-sequencing firm as a way 
out of the Great Depression. But S.J. Perleman's "Three Shares in a Boat" shows 
a real-world use of a threshold scheme. I don't think anyone said it better 
than W.C. Fields did in "Never Give a Sucker an Even Break" and "You Can't 
Cheat an Honest Man."

I think you'll have to agree that unlike history, which starts out as tragedy 
and replays itself as farce, PKI has always been farce over the centuries. It 
might actually end up as tragedy, but so far so good. I'm sure that if we look 
further, the Athenians had the same issues with it that we do today, and that 
Sophocles had his own farcical commentary.

Jon
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

David-Sarah Hopwood  writes:

>Huh? I don't understand the argument being made here.

It's a bogus argument, the text says:

  He took a legitimate software package and removed the signature of the
  digital certificate it contained, then installed the package on his
  computer. The Installer application didn't indicate that the certificate had
  been modified.

The certificate wasn't modified, they just stripped the signature from the
executable.

  "Only an expert will be able to detect a problem," Schouwenberg said. "And
  all Microsoft will tell you is that the file is not signed."

And what else should Windows say?  "We put this through our time machine and
noticed that at some time in the past it was signed and now it isn't"?

The rest of the story isn't much better:

  The Stuxnet worm, which surfaced last month, used fake Verisign digital
  certificates

No, they were genuine certs, just in the wrong hands.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[David-Sarah Hopwood]

Anne & Lynn Wheeler wrote:
> Kaspersky: Sham Certificates Pose Big Problem for Windows Security
> http://www.ecommercetimes.com/story/70553.html
> 
> from above ..
> 
> Windows fails to clearly indicate when digital security certificates
> have been tampered with, according to Kaspersky Lab's Roel Schouwenberg,
> and that opens a door for malware makers.

Huh? I don't understand the argument being made here.

Obviously Windows can't distinguish an unsigned executable from one where
the was a signature that has been stripped. How could it possibly do that?

Signatures are largely a distraction from the real problem: that software
is (unnecessarily) run with the full privileges of the invoking user.
By all means authenticate software, but that's not going to prevent malware.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com



signature.asc
Description: OpenPGP digital signature

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

Kaspersky: Sham Certificates Pose Big Problem for Windows Security
http://www.ecommercetimes.com/story/70553.html

from above ..

Windows fails to clearly indicate when digital security certificates have been
tampered with, according to Kaspersky Lab's Roel Schouwenberg, and that
opens a door for malware makers.

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Bill Frantz]

On 7/28/10 at 8:52 PM, pfarr...@pfarrell.com (Pat Farrell) wrote:


When was the last time you used a paper Yellow Pages?


Err, umm, this last week. I'm in a place where cell coverage 
(AT&T, Verizon has a better reputation) is spotty and internet 
is a dream due to a noisy land line. I needed to find a ceramic 
tile store. The paper yellow pages had survived being left in 
the driveway in the rain and I used it.


However, I agree that this is the <2% case for many parts of the world.

Cheers - Bill

---
Bill Frantz|"Web security is like medicine - trying to 
do good for

408-356-8506   |an evolved body of kludges" - Mark Miller
www.periwinkle.com |

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Bill Stewart]

At 07:16 AM 7/28/2010, Ben Laurie wrote:

SSH does appear to have got away without revocation, though the nature
of the system is s.t. if I really wanted to revoke I could almost
always contact the users and tell them in person. This doesn't scale
very well to SSL-style systems.


Unfortunately, there _are_ ways that it can scale adequately.
Bank of America has ~50 million customers,
so J. Random Spammer sends out 500 million emails saying
"Bank of America is updating our security procedures,
please click on the following link to update your browser."
It's more efficient for BofA to send out the message themselves,
only to actual subscribers, with the actual keys,
helping to train them to accept phishing mail in the process,
but apparently even doing it the hard way scales well enough for some 
people to make money.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

On 07/28/2010 11:52 PM, Pat Farrell wrote:

A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.


some ssl, payment, smartcard trivia ...

those smartcards were used for the offline authorization (not just authentication) ... which, in at least one 
major product, led to the "YES CARD" ... relatively trivial to skim & replicated a static digital 
certificate for a counterfeit card ... then the counterfeit card was programmed to answer "YES" to 1) 
was the correct PIN entered, 2) should the transaction be performed offline, and 3) was the transaction approved. 
Once the static digital certificate was skimmed, it was no longer even necessary to know the PIN, since the 
counterfeit card accepted every possible PIN as valid. misc. past posts mentioning "YES CARD"
http://www.garlic.com/~lynn/subintegrity.html#yescard

In a 2003, at an ATM Integrity task force meeting ... there was presentation by some LEO explaining the "yes 
card" ... and how there was little or no countermeasure once a "YES CARD" was in existence ... somebody 
in the audience loudly observed that billions were spent on proving smartcards are less secure than magstripe. In the 
"YES CARD" timeframe there was even a rather large pilot of the cards in the US ... but seemed to disappear 
after the "YES CARD" scenario was publicized (it was actually explained to the people doing the pilot, before 
the pilot started ... but apparently they didn't appreciate the significance).

much earlier, we had been working on our ha/cmp product and cluster scaleup. we 
had meeting on cluster scaleup meeting during jan92 sanfran usenet (in 
ellison's conference room) ... past posts mentioning the jan92 meeting
http:www/garlic.com/~lynn/95.html#13

this was just a few weeks before cluster scaleup was transferred (announced as 
supercomputer for numerical intensive only) and we were told we couldn't work 
on anything with more than four processors. some old email from the period on 
cluster scaleup
http://www.garlic.com/~lynn/lhwemail.html#medusa

we then leave a couple months later. two of the other people named in the jan92 meeting also leave and show 
up at small client/server startup responsible for something called "commerce server". we get 
brought in to consult because they want to do payment transactions on the server ... the small client/server 
startup has also invented some technology called "SSL" they want to use. The results is now 
frequently called "electronic commerce".

Then apparently because of the work on electronic commerce ... we also get 
invited to participate in the x9a10 financial standard working group ... which 
had been given the requirement to preserve the integrity of the financial 
infrastructure  for all retail payments.

About the same time there is a pilot program for magstripe-based online 
stored-value cards  (uses existing POS magstripe terminals but the payment 
network routes the transactions to different backend processor, original 
program of its kind in the US). At the time, the US didn't have the telco 
connectivity availability and cost issues that many places in the rest of the 
world were dealing with ... and therefor didn't have that requirement to move 
to offline smartcard payment paradigm. However, it turns out their backend, 
high-availability, no-single-point-of-failure platform developed a glitch ... 
and even tho it was from a different vendor (than our ha/cmp product) we were 
asked to investigate at the various failure modes.

Somewhat as a result of all of the above, when one of the major offline, 
smartcard, european, stored-value payment operators was looking at making an 
entry into the US in the 90s ... we were asked to design, size, and cost their 
backend dataprocessing infrastructure. Along the way, we took an indepth look 
at the business process and cost structure of such payment products. Turns out 
that the major financial motivation for that generation of smartcard 
stored-value payment products ... was that the operators got to keep the float 
on the value resident in the stored-value cards. Not too long later ... several 
of the major european central banks announced that the smartcard, stored-value 
operators would have to start paying interest on value in the smartcards 
(eliminating the float financial incentive to those operators). It wasn't too 
long after that most of the programs disappeared.

The major difference between that generation of smartcard payment products and the AADS chip 
strawman ... was that rather than attempting to be a complex, loadable, multi-function issuer card 
 the objective was changed to being a person-centric, highest-possible integrity, 
lowest-possible cost, hard-to-counterfeit authentication ... which could be registered (publickey) 
for arbitrary number of different environments ("something you have" authentication 
registered in 

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Steven Bellovin  writes:

>When I look at this, though, little of the problem is inherent to PKI.
>Rather, there are faulty communications paths.

"Oh no my Lord, I assure you that parts of it are excellent!" :-).

>[...] how should the CA or Realtek know about the problem? [...]

That was the whole point, that the whole system doesn't work, and it's the 
system as a whole that has to work, not just some parts of it.  Here's another 
description, without the possibly confusing 't +/- x' stuff:

Shortly after the malware appeared (or at least got noticed) it was added to
anti-virus vendor databases and pushed out to users via updates.  Some time
later when it made headlines because of its use of the Realtek certificate,
the CA that had issued it read about it in the news, contacted the certificate
owner, and revoked it.  However due to the dysfunctional nature of revocation
handling, the certificate was still regarded as valid by Windows systems after
it had been revoked, and of a range of machines running Windows 7, Vista, and
XP, all with the latest updates and hotfixes applied and with automatic
updates turned on, the first machine to notice the revocation and treat the
signature as invalid didn't do so until a full week after the revocation had
occurred, and some machines still regard the signature as valid even now (I've
heard this before a number of times in software developer forums and mailing
lists, plaintive complaints from users to the effect that "I know this
certificate is revoked, but no matter what I do I can't get the software to
stop using it!").

So while PKI and code-signing promise the user a fairly deterministic series
of events in which A occurs, the B occurs, then C occurs, and then the user is
safe, what actually happens in practice is that A occurs, then a comedy of
errors ensues [0], and then the user is still unsafe while possibly being
under the mistaken impression that they're actually safe.

[0] I've never understood why this is a comedy of errors, it seems more like
a tragedy of errors to me.

A real-world demonstration of the relative effectiveness of various protection
mechanisms occurred when I wanted to evaluate the ability of code-signing to
protect users.  A researcher sent me a copy of the signed malware (thanks!),
and because of its nature encrypted it with AES using the RAR archiver.
Because RAR (and indeed most other archivers) don't protect file metadata, the
message was blocked by email scanners that identified the overall contents
from the metadata even though the file contents themselves were encrypted.
After some discussion with the IT people ("yes, I am certain what the file is,
it's a rather nasty piece of Windows malware, and I trust the sender to have
sent me malware") they forwarded the email to the PowerPC Linux machine on
which I read email, and which is rather unlikely to be affected by x86 Windows
malware.

Unfortunately I never could check it on the Windows system that I wanted to
test it on because the instant it appeared on there the resident malware
protection activated and deleted it again, despite various attempts to bypass
the protection.  Eventually I got it onto a specially-configured Windows
system, which reported that both the signature and its accompanying
certificate were valid (this is now two weeks after the CA had declared the
certificate revoked).  So it actually proved quite difficult to see just how
ineffective PKI and code-signing actually was in protecting users from malware
because the real protection mechanisms were so effective at doing their job.

(It's also rather an eye-opener about the effectiveness, at least in some
cases, of malware-protection software, no matter what I did I couldn't get the
malware files onto a Windows PC in order to have the code-signing declare them
valid and, by implication, perfectly safe).

>What's interesting here is the claim that AV companies could respond much
>faster.

I'd say it's more than just a claim, the malware was first detected around 1
1/2 months ago and added to AV vendor databases, a full month later the
certificate was declared revoked by the CA, and currently the majority of
Windows systems still regard the signature as valid (I've had a report from
someone else of one machine that records it as revoked, so at least one
machine has been belatedly protected by the code signing, assuming the user
doesn't just click past the warning as pretty much all of them will).

So yes, I'd say the AV companies respond a helluva lot faster, and a helluva
lot more effectively. The bigger lesson, for people who ever believed this to
be the case, is "don't rely on code signing to protect you from malware".

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Thu, Jul 29, 2010 at 10:50:10AM +0200, Alexandre Dulaunoy wrote:
> On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams
>  wrote:
> > This is a rather astounding misunderstanding of the protocol.  [...]
> 
> I agree on this and but the implementation of OCSP has to deal with
> all "non definitive" (to take the wording of the RFC) answers. That's
> where the issue is. All the "exception case", mentioned in 2.3, are
> all unauthenticated and it seems rather difficult to provide authenticated
> scheme for that part as you already mentioned in [*].
> 
> That's why malware authors are already adding fake entries of OCSP
> server in the host file... simple and efficient.

A DoS attack on OCSP clients (which is all this really is) should either
cause the clients to fallback on CRLs or to fail the larger operation
(TLS handshake, whatever) altogether.  The latter makes this just a DoS.
The former makes this less than a DoS.

The real risk would be OCSP clients that don't bother with CRLs if OCSP
Responder can't respond successfully, but which proceed anyways af if
peers' certs are valid.  If there exist such clients, don't blame OCSP.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[StealthMonger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jerry Leichter  writes:

> The only conceivable purpose for using a signature is that you can
> check it *offline*.  If you assume you can connect to the network,
> and that you can trust what you get from the network - why bother
> with a signature?  Simply check a cryptographic hash of the driver
> against an on-line database of "known good" drivers.

> This is right in line with Lynn Wheeler's frequent mention here that
> the use case for offline verification of certs for commerce
> basically doesn't exist.  It was a nice theory to develop 30 years
> ago, but today the rest of the framework assumes connectivity, and
> you buy nothing but additional problems by focusing on making just
> one piece work off-line.

Not quite.

Untraceable anonymity and untraceable pseudonymity remain one of the
important applications of cryptography, and both depend on store and
forward anonymizing networks which mix traffic by using high random
latency.

The saving qualifier for your assertion is "for commerce".  True,
there is not yet a way to securely transmit and store commercial value
(money) offline, but it has not been proven impossible.

For these applications, the security has to be in the message, not the
connection.  Offline verification is essential.


 -- StealthMonger
 

 --
   stealthmail: Scripts to hide whether you're doing email, or when,
   or with whom.
 mailto:stealthsu...@nym.mixmin.net

Finger for key.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iEYEARECAAYFAkxReuIACgkQDkU5rhlDCl7izQCfXuxcHdDT5c54EpATviI+PXCO
MFEAoI62kO/DZcwkw++BpQ4Ey5jTVro6
=6mIw
-END PGP SIGNATURE-

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

On 07/28/2010 11:52 PM, Pat Farrell wrote:

I'd like to build on this and make a more fundamental change. The
concept of a revocation cert/message was based on the standard practices
for things like stolen credit cards in the early 1990s. At the time, the
credit card companies published telephone book sized listings of stolen
and canceled credit cards. Merchant's had the choice of looking up each
card, or accepting a potential for loss.

A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.



that was one of my points ridiculing PKI in the mid-90s ... that the CRL was a 
return to offline point-of-sale payment operation ... and seemed to motivate 
the work on OCSP.

The difference was that in the move to real-time online transactions ... it got 
much high quality operation ... not only could it establish real-time 
valid/not-valid ... but also other real-time characteristics like real-time 
credit limit, recent pattern of transactions, and much more. by comparison, 
OCSP was an extremely poor man's real-time, online transaction

smartcard payment cards started out being stand-alone stored-value to 
compensate for the extremely expensive and limited availability of 
point-of-sale in much of the world ... aka it was stored-value operation where 
the operation could be performed purely offline (the incremental cost of the 
smartcard chip was offset by savings not requiring realtime, online 
transaction).

The telco economics didn't apply to the US ... as seen by the introduction of 
"stored-value" magstripe based payment cards in the US that did real-time, online 
transaction ... which served the same market niche that the offline smartcard was performing 
in other parts of the world. Between the mid-90s and now, telco costs & connectivity has 
significantly changed around the world ... pervasive uniquitness of the internet, cellphone 
coverage, wireless, ... lots of things.

The common scenario in the past couple decades ... was looking to add more & 
more feature/function to smartcards to find the magical economic justification ... 
unfortunately, the increase in feature/function tended to also drive cost ... 
keeping the break even point just out of reach.

Part of the certificateless public key work was to look at chips as a cost item (rather 
than profit item ... since lots of the smartcard work was driven by entities looking to 
profit by smartcard uptake). The challenge was something that had stronger integrity 
than highest rated smartcard but at effective fully loaded cost below magstripe (i.e. I 
had joked about taking a $500 milspec part, cost reducing by 3-4 orders of magnitude 
while improving the integrity). Another criteria was that it had to work within the 
time & power constraints of a (ISO14443) contactless transit turnstyle ... while 
not sacrificing any integrity & security.

By comparison ... one of the popular payment smartcards from the 90s looked at the transit 
turnstyle issue ... and proposed a "wireless" sleeve for their contact card ... and 15ft 
electromagnetic "tunnels" on the approach to each transit turnstyle ... where public 
would walk slowly thru the tunnel ... so that the transaction would have completed by the time the 
turnstyle was reached.

Part of achieving lower aggregate cost than magstripe ... was that even after 
extremely aggressive cost reduction, the unit cost was still 2-3 times that of 
magstripe ... however, if the issuing frequency could be reduced (for chip)... 
it was more than recouped (i.e. magstripe unit cost is possibly only 1% of 
fully loaded issuing costs). Changing the paradigm from institutional-centric 
(i.e. institution issued) to person-centric (i.e. person uses the same unit for 
multiple purposes and with multiple institutions) ... saves significant amount 
more (replaces an issuing model with a registration model).

Turns out supposedly a big issue for a transition from an institution-centric (institution issuing) 
to person-centric paradigm ... was addressing how can the institution "trust" the unit 
being registered. Turns out that "trust" issue may have been obfuscation ... after 
providing a solution to institution trust ... there was continued big push back to moving off an 
institutional issuing (for less obvious reasons) ... some of the patent stuff (previous mentions) 
covered steps for moving to person-centric paradigm (along with addressing institutional trust 
issues). Part of it involved tweaking some of the processes ... going all the way back to while the 
chip was still part of wafer (in chip manufacturing ... and doing the tweaks in such a way that 
didn't disrupt standard chip manufacturing ... but at the same time reduced steps/costs).

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mail

Re: A mighty fortress is our PKI, Part II

[James A. Donald]

On 2010-07-29 12:18 AM, Peter Gutmann wrote:

This does away with the need for a CA,
because the link itself authenticates the cert that's used.

Then there are other variations, cryptographically generated addresses, ...
all sorts of things have been proposed.

The killer, again, is the refusal of any browser vendor to adopt any of it.


Bittorrent links have this property.  A typical bittorent link looks 
like 
magnet:?xt=urn:btih:2ac7956f6d81bf4bf48b642058d31912479d8d8e&dn=South+Park+S14E06+201+HDTV+XviD-FQM+%5Beztv%5D&tr=http%3A%2F%2Fdenis.stalker.h3q.com%3A6969%2Fannounce


It is the equivalent of an immutable file in Tahoe.



In the case of FF someone actually wrote the code for them, and it was
rejected.  Without support from browser vendors, it doesn't matter what cool
ideas people come up with, it's never going to get any better.


The browser vendors are married to the CAs

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Alexandre Dulaunoy]

On Thu, Jul 29, 2010 at 3:09 AM, Nicolas Williams
 wrote:

> This is a rather astounding misunderstanding of the protocol.  An
> OCSPResponse does contain unauthenticated plaintext[*], but that
> plaintext says nothing about the status of the given certificates -- it
> only says whether the OCSP Responder was able to handle the request.  If
> a Responder is not able to handle requests it should respond in some
> way, and it may well not be able to authenticate the error response,
> thus the status of the responder is unauthenticated, quite distinctly
> from the status of the certificate, which is authenticated.  Obviously
> only successful responses are useful.

I agree on this and but the implementation of OCSP has to deal with
all "non definitive" (to take the wording of the RFC) answers. That's
where the issue is. All the "exception case", mentioned in 2.3, are
all unauthenticated and it seems rather difficult to provide authenticated
scheme for that part as you already mentioned in [*].

That's why malware authors are already adding fake entries of OCSP
server in the host file... simple and efficient.

I just wanted to raise the point that a model like PK-i relying on complex
scheme for security will easily fail at the obvious as the attacker
is often choosing the shortest/fastest path to reach his goal.


> [*] It's not generally possible to avoid unauthenticated plaintext
>    completely in cryptographic protocols.  The meaning of a given bit
>    of unauthenticated plaintext must be taken into account when
>    analyzing a cryptographic protocol.

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Pat Farrell]

On 07/28/2010 08:44 PM, Steven Bellovin wrote:
> When I look at this, though, little of the problem is inherent to
> PKI.  Rather, there are faulty communications paths.
> 
> You note that at t+2-3 days, the CA read the news.  Apart from the
> question of whether or not "2-3 days" is "shortly after" -- the time
> you suggest the next step takes place -- how should the CA or Realtek
> know about the problem? 
> [snip]
> The point about the communications delay is that it's inherent to
> anything involving the source company canceling anything -- whether
> it's a PKI cert, a pki cert, a self-validating URL, a KDC, or magic
> fairies who warn sysadmins not to trust certain software.

While I'm quoting Steve, his comment really drives me to a bigger break.

I'd like to build on this and make a more fundamental change. The
concept of a revocation cert/message was based on the standard practices
for things like stolen credit cards in the early 1990s. At the time, the
credit card companies published telephone book sized listings of stolen
and canceled credit cards. Merchant's had the choice of looking up each
card, or accepting a potential for loss.

A lot of the smart card development in the mid-90s and beyond was based
on the idea that the smart card, in itself, was the sole authorization
token/algorithm/implementation.

How about we posit that there is networking everywhere? People carry
"cell phones" that are serious computers and are connected to serious
networks.

When was the last time you used a paper Yellow Pages?

How about thinking of a solution that addresses 98% of all transactions
for 98% of all people in the places where 98% of business is done. At
some point, the perfect is the enemy of the good. If you have a selling
hut in the middle of nowhere, well, you probably don't have a lot of
computer power either. So calculating to do an RSA signature is out of
the question anyway.

A risk based approach would have an algorithm that looks at the value of
the transaction. Buying a meal at a fast food place is not worth a lot
of effort, so the definition of "shortly after" can be a second or so.
Buying new 3D TV can have a longer time, with the time allowance, and
expected/acceptable response time, perhaps time for automated actuarial
analysis. When you are signing a contract to buy a house, you can take a
day to verify that everything is proper.

We have fast computers and ubiquitous networking. Why are we still
thinking about systems based on 3 inch think paper books?

We seem to be solving a problem that no longer exists when you look at
it from first principals.

Pat

-- 
Pat Farrell
http://www.pfarrell.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Sampo Syreeni]

On 2010-07-28, Jerry Leichter wrote:

There is, of course, the problem of knowing when a signature was 
stolen!


Or in economic terms, asymmetric information. Can we for example learn 
something from the way insurers and the like who've been dealing with 
that for centuries solve the problem? And then apply it to 
protocol/market design?

--
Sampo Syreeni, aka decoy - de...@iki.fi, http://decoy.iki.fi/front
+358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 10:03:08PM +0200, Alexandre Dulaunoy wrote:
> On Wed, Jul 28, 2010 at 5:51 PM, 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%
> > [...]

The protocol allows for more than simple proxy checking of CRLs.  What
implementations do is another matter (which matters, of course, but be
sure to know what you're condemning, the implementations or the
protocol, as they're not the same thing).

> OCSP is even better for an attacker. As the OCSP responses are
> unauthenticated[1], you can be easily fake the response with
> what ever the attacker likes.
> 
> http://www.thoughtcrime.org/papers/ocsp-attack.pdf
> 
> [1] Would be silly to run OCSP over SSL ;-)

This is a rather astounding misunderstanding of the protocol.  An
OCSPResponse does contain unauthenticated plaintext[*], but that
plaintext says nothing about the status of the given certificates -- it
only says whether the OCSP Responder was able to handle the request.  If
a Responder is not able to handle requests it should respond in some
way, and it may well not be able to authenticate the error response,
thus the status of the responder is unauthenticated, quite distinctly
from the status of the certificate, which is authenticated.  Obviously
only successful responses are useful.

The status of a certificate (see SingleResponse ASN.1 type) most
certainly is covered by the signature: SingleResponse is part of
ResponseData, which is the type of tbsResponseData, which is what the
signature covers.

Don't take my word for it, nor that paper's author's.  Read the RFC and
decide for yourself.

[*] It's not generally possible to avoid unauthenticated plaintext
completely in cryptographic protocols.  The meaning of a given bit
of unauthenticated plaintext must be taken into account when
analyzing a cryptographic protocol.


Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Steven Bellovin]

On Jul 28, 2010, at 9:22 29AM, Peter Gutmann wrote:

> Steven Bellovin  writes:
> 
>> For the last issue, I'd note that using pki instead of PKI (i.e., many 
>> different per-realm roots, authorization certificates rather than identity 
>> certificates, etc.) doesn't help: Realtek et al. still have no better way or 
>> better incentive to revoke their own widely-used keys.
> 
> I think the problems go a bit further than just Realtek's motivation, if you 
> look at the way it's supposed to work in all the PKI textbooks it's:
> 
>  Time t: Malware appears signed with a stolen key.
>  Shortly after t: Realtek requests that the issuing CA revoke the cert.
>  Shortly after t': CA revokes the cert.
>  Shortly after t'': Signature is no longer regarded as valid.
> 
> What actually happened was:
> 
>  Time t: Malware appears signed with a stolen key.
>  Shortly after t: Widespread (well, relatively) news coverage of the issue.
> 
>  Time t + 2-3 days: The issuing CA reads about the cert problem in the news.
>  Time t + 4-5 days: The certificate is revoked by the CA.
>  Time t + 2 weeks and counting: The certificate is regarded as still valid by
>the sig-checking software.
> 
> That's pretty much what you'd expect if you're familiar with the realities of 
> PKI, but definitely not PKI's finest hour.  In addition you have:
> 
>  Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than
>the victims)
>  Shortly after t - lots: AV vendors add it to their AV databases and push out
>updates
> 
> (I don't know what "lots" is here, it seems to be anything from weeks to
> months depending on which news reports you go with).
> 
> So if I'm looking for a defence against signed malware, it's not going to be 
> PKI.  That was the point of my previous exchange with Ben, assume that PKI 
> doesn't work and you won't be disappointed, and more importantly, you now 
> have 
> the freedom to design around it to try and find mechanisms that do work.

When I look at this, though, little of the problem is inherent to PKI.  Rather, 
there are faulty communications paths.

You note that at t+2-3 days, the CA read the news.  Apart from the question of 
whether or not "2-3 days" is "shortly after" -- the time you suggest the next 
step takes place -- how should the CA or Realtek know about the problem?  Did 
the folks who found the offending key contact either party?  Should they have?  
The AV companies are in the business of looking for malware or reports thereof; 
I think (though I'm not certain) that they have a sharing agreement for new 
samples.  (Btw -- I'm confused by your definition of "t" vs. "t-lots".  The 
first two scenarios appear to be "t == the published report appearing"; the 
third is confusing, but if you change the timeline to "t+lots" it works for "t 
== initial, unnoticed appearance in the wild".  Did the AV companies push 
something out long before the analysis showed the stolen key?)

Suppose, though, that Realtek has some Google profile set up to send them 
reports of malware affecting their anything.  Even leaving aside false 
positives, once they get the alert they should do something.  What should that 
something be?  Immediately revoke the key?  The initial reports I saw were not 
nearly specific enough to identify which key was involved.  Besides, maybe the 
report was not just bogus but malicious -- a DoS attack on their key.  They 
really need to investigate it; I don't regard 2-3 days as unreasonable to 
establish communications with an malware analysis company you've never heard of 
and which has to verify your bonafides, check it out, and verify that the 
allegedly malsigned code isn't something you actually released N years ago as 
release 5.6.7.9.9.a.b for a minor product line you've since discontinued.  At 
that point, a revocation request should go out; delays past that point are not 
justifiable.  The issue of software still accepting it, CRLs notwithstanding, 
is more a sign of buggy code.

The point about the communications delay is that it's inherent to anything 
involving the source company canceling anything -- whether it's a PKI cert, a 
pki cert, a self-validating URL, a KDC, or magic fairies who warn sysadmins not 
to trust certain software.  

What's interesting here is the claim that AV companies could respond much 
faster.  They have three inherent advantages: they're in the business of 
looking for malware; they don't have to complete the analysis to see if a 
stolen key is involved; and they can detect problems after installation, 
whereas certs are checked only at installation time.  Of course, speedy action 
can have its own problems; see 
http://www.pcworld.com/businesscenter/article/194752/few_answers_after_mcafee_antivirus_update_hits_intel_others.html
 for a recent example, but there have been others.  

Note that I'm not saying that PKI is a good solution.  But it's important to 
factor out the different contributing factors in order to understand w

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 15:30:08 -0600 Paul Tiemann
 wrote:
> > However, in discussing this at a high level, as though we could
> > improve things, we shouldn't kid ourselves about the current
> > model. It is fatally broken. Hanging garlands from the corpse's
> > ears will not convince anyone that it has a vibrant future ahead.
>
> "it will CLEARLY not solve the browser security problem."
> "the certifications made by even the best of those CAs are
> effectively MEANINGLESS" "the users are well trained to ignore
> EVERY browser warning they EVER get" "the ENTIRE question of OCSP
> is somewhat irrelevant." "spritzing the SKUNK with eau de cologne."
> "hanging garlands from the corpses ears."

I stand by all the things I said above, other than the apparent lack
of an apostrophe in "corpse's". I realize it isn't moderate language,
but on the other hand, my meaning is unmistakable.

> That's all expressed in very certain terms.

We've been watching the slow motion accident very closely for a couple
of decades now. If that isn't long enough to develop certainty, I
don't know how many years would suffice. To believe we can fix the
mess now would be to ignore twenty years of experience.

> Is OCSP _that_ hopeless?

I believe you misunderstand me. I'm not talking about OCSP.  I'm
saying the entire X.509 certificate infrastructure used in web
browsers is hopeless. OCSP is just one small hopeless component of a
hopeless whole.

(I don't think things are particularly better in other applications of
the system, but there are almost no other widely used applications
beyond code signing anyway. S/MIME and the rest are not merely dead
but nearly forgotten.)

There are multiple completely fatal flaws in the system. Any one of
them alone would suffice. To repeat just a few:

1) The user's security depends on the security of the worst CA in the
system. If there is any dispute about this, I would like to know on
what basis. There should be no dispute that CAs have certified things
they should not have, and will do so again. There should be no dispute
that some CAs have been sold and their keys subsequently passed around
under less than ideal circumstances. There should be no dispute that
not all CAs are what would be universally considered trustworthy
organizations.

2) Users have been trained by too many false alarms to ignore all
browser warnings. If you don't believe me, there are fine papers about
what real users do when exposed to warnings, and they ignore
them. Users also have no real ability to understand the error messages
even if they did still care about them.

3) Revocation in the face of compromise is, as a practical matter,
nearly impossible.

4) CAs as a practical matter disclaim all liability and are not, in
fact, insuring anything in the sense of insurance.

5) The third party attestation idea is wrong as it does not properly
model the actual trust relationships and liability among the parties.

6) The entire idea of signed attestations that last for years is based
on a pre-Internet, largely offline model of security.

There is more, but why should we belabor it? The parrot is not pining
for the fjords. I'm only surprised that the nails have kept it
vertical for so long.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 14:40:14 -0600 Paul Tiemann
 wrote:
> 
> On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote:
> 
> > On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams
> >  wrote:
> >> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> >>> Again, I understand that in a technological sense, in an ideal
> >>> world, they would be equivalent. However, the big difference,
> >>> again, is that you can't run Kerberos with no KDC, but you can
> >>> run a PKI without an OCSP server. The KDC is impossible to leave
> >>> out of the system. That is a really nice technological feature.
> >> 
> >> Whether PKI can run w/o OCSP is up to the relying parties.
> >> Today, because OCSP is an afterthought, they have little choice.
> > 
> > My mother relies on many certificates. Can she make a decision on
> > whether or not her browser uses OCSP for all its transactions?
> 
> That might depend.  I tell Firefox to use OCSP if a responder is
> referenced in the certificate, and I check that little checkbox
> that says "When an OCSP connection fails, treat the certificate as
> invalid."

I believe you've missed an important point.

First, my mother would never understand what that box means. Second,
my mother has no control over whether the CA provides OCSP.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Paul Tiemann]

On Jul 28, 2010, at 10:37 AM, Perry E. Metzger wrote:

> As to OCSP being a reasonable solution because it can be deployed
> easily, it clearly will not solve the browser security problem. So
> long as security depends on reliance on the lowest common denominator
> among the policies of hundreds of CAs, many of which are quite
> questionable, and so long as the certifications made by even the best
> of those CAs are effectively meaningless, and so long as the users are
> well trained to ignore every browser warning they ever get, the entire
> question of OCSP is somewhat irrelevant -- it would just be a way of
> spritzing the skunk with eau de cologne.
> 
> I fully recognize that the odds we will fix the browser security
> problem are very low, if only because no one can deploy a truly new
> solution in a world where we can't even get IE 6 to die.
> 
> However, in discussing this at a high level, as though we could
> improve things, we shouldn't kid ourselves about the current model. It
> is fatally broken. Hanging garlands from the corpse's ears will not
> convince anyone that it has a vibrant future ahead.


"it will CLEARLY not solve the browser security problem."
"the certifications made by even the best of those CAs are effectively 
MEANINGLESS"
"the users are well trained to ignore EVERY browser warning they EVER get"
"the ENTIRE question of OCSP is somewhat irrelevant."
"spritzing the SKUNK with eau de cologne."
"hanging garlands from the corpses ears."

That's all expressed in very certain terms.

Is OCSP _that_ hopeless?  

You were kind enough to suggest Orwell to Jay at Edgecast (and possibly also to 
me.)  I read it, liked it, and I'm glad you sent it.  I sincerely think we can 
all learn from these two references:

A great essay by Neil Postman:

http://criticalsnips.wordpress.com/2007/07/22/neil-postman-bullshit-and-the-art-of-crap-detection/

And Ben Franklin's advice, with one paragraph excerpted below:

http://grammar.about.com/b/2009/06/01/how-to-argue-like-ben-franklin-and-lieutenant-columbo.htm

And as the chief Ends of Conversation are to inform or to be informed, to 
please or to persuade, I wish well-meaning sensible men would not lessen their 
Power of doing Good by a Positive assuming Manner that seldom fails to disgust, 
tends to create Opposition, and to defeat every one of those Purposes for which 
Speech was given to us, to wit, giving or receiving Information or Pleasure: 
For If you would inform, a positive dogmatical Manner in advancing your 
Sentiments, may provoke Contradiction & prevent a candid Attention. If you wish 
Information and Improvement from the Knowledge of others and yet at the same 
time express your self as firmly fix'd in your present Opinions, modest 
sensible Men, who do not love Disputation, will probably leave you undisturb'd 
in the Possession of your Error; and by such a Manner you can seldom hope to 
recommend your self in pleasing your Hearers, or to persuade those whose 
Concurrence you desire.
(Part One of The Autobiography of Benjamin Franklin, 1793; from The Library of 
America edition of Benjamin Franklin: Writings, 1987)

All the best,

Paul Tiemann
(DigiCert)
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Paul Tiemann]

On Jul 28, 2010, at 11:25 AM, Perry E. Metzger wrote:

> On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams
>  wrote:
>> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
>>> Again, I understand that in a technological sense, in an ideal
>>> world, they would be equivalent. However, the big difference,
>>> again, is that you can't run Kerberos with no KDC, but you can
>>> run a PKI without an OCSP server. The KDC is impossible to leave
>>> out of the system. That is a really nice technological feature.
>> 
>> Whether PKI can run w/o OCSP is up to the relying parties.  Today,
>> because OCSP is an afterthought, they have little choice.
> 
> My mother relies on many certificates. Can she make a decision on
> whether or not her browser uses OCSP for all its transactions?

That might depend.  I tell Firefox to use OCSP if a responder is referenced in 
the certificate, and I check that little checkbox that says "When an OCSP 
connection fails, treat the certificate as invalid."

True, if you don't have that checkbox marked, then Firefox will take a failed 
OCSP check attempt (connection refused, socket timeout, etc) as a success.  
What it ought to do is try the CRL(s) listed in the certificate too, and if 
both don't work then it really ought to error.

Paul Tiemann
(DigiCert)
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Paul Tiemann]

On Jul 28, 2010, at 10:23 AM, Peter Gutmann wrote:

> Nicolas Williams  writes:
> 
>> Sorry, but this is wrong.  The OCSP protocol itself really is an online
>> certificate status protocol.  
> 
> It's not an online certificate status protocol because it can provide neither
> a yes or a no response to a query about the validity of a certificate.
> 
> (For an online status protocol I want to be able to submit a cert and get back
> a straight valid/not valid response, exactly as I can for credit cards with
> their authorised/declined response.  

It might not be hard to determine whose OCSP responders are CRL based and whose 
are database backed instead.  

> Banks were doing this twenty years ago
> with creaky mainframes over X.25 and (quite probably) wet bits of string, but
> we still can't do this today with multicore CPUs and gigabit links if we're
> using OCSP).

Yes we can, and some actually do.

>> Responder implementations may well be based on checking CRLs, but they aren't
>> required to be.
> 
> They may be, or they may not be, but you as a relying party have no way of 
> telling.  

Even the most savvy of relying parties probably has no way of caring.  They 
want to know when something is positively revoked, and having a definitive Yes 
is a nice distinction, but having a definitive Not-Revoked appears to be good 
enough for most.  

> In any event though since OCSP can't say yes or no, it doesn't matter whether 
> the response is coming from a live database or a month-old CRL, since it's 
> still a fully CRL-bug-compatible blacklist I can trivially avoid it with a 
> manufactured-cert attack.

You're right: a manufactured-cert attack is going to really hurt that kind of 
an OCSP responder.

Is a manufactured-cert a trivial thing to create?  

Paul Tiemann
(DigiCert)

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[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 
> say 
> "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
(DigiCert)


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Alexandre Dulaunoy]

On Wed, Jul 28, 2010 at 5:51 PM, 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.  Specifically, if I submit a freshly-issued, valid certificate to
> an OCSP responder and ask "is this a valid certificate" then it can't say yes,
> and if I submit an Excel spreadsheet to an OCSP responder and ask "is this a
> valid certificate" then it can't say no.  It takes quite some effort to design
> an online certificate status protocol that's that broken.

OCSP is even better for an attacker. As the OCSP responses are
unauthenticated[1], you can be easily fake the response with
what ever the attacker likes.

http://www.thoughtcrime.org/papers/ocsp-attack.pdf

[1] Would be silly to run OCSP over SSL ;-)

-- 
--                   Alexandre Dulaunoy (adulau) -- http://www.foo.be/
--                             http://www.foo.be/cgi-bin/wiki.pl/Diary
--         "Knowledge can create problems, it is not through ignorance
--                                that we can solve them" Isaac Asimov

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 02:41:35PM -0400, Perry E. Metzger wrote:
> On the other edge of the spectrum, many people now use quite secure
> protocols (though I won't claim the full systems are secure --
> implementation bugs are ubiquitous) for handling things like remote
> login and file transfer, accessing shared file systems on networks,
> etc., with little to no knowledge on their part about how their
> systems work or are configured. This seems like a very good thing. One
> may complain about many issues in Microsoft's systems, for example,
> but adopting Kerberos largely fixed the distributed authentication
> problem for them, and without requiring that users know what they're
> doing.

Hear, hear!  But... great for corporate networks, not quite for
Internet-scale, but a great example of how we can make progress when we
want to.

> (I am reminded of the similar death-by-complexity of the IPSec
> protocol's key management layers, where I am sad to report that even I
> can't easily configure the thing. Some have proposed standardizing on
> radically simplified profiles of the protocol that provide almost no
> options -- I believe to be the last hope for the current IPSec suite.)

IPsec is a great example of another kind of failure: lack of APIs.
Applying protection to individual packets without regard to larger
context is not terribly useful.  Apps have no idea what's going on, if
anything, in terms of IPsec protection.  Worse, the way in which IPsec
access control is handled means that typically many nodes can claim any
given IP address, which dilutes the protection provided by IPsec as the
number of such nodes goes up.  Just having a way to ask that a TCP
connection's packets all be protected by IPsec, end-to-end, with similar
SA pairs (i.e., with same peers, same transforms) would have been a
great API to have years ago.

The lack of APIs has effectively relegated IPsec to the world of VPN.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 12:38:10 -0500 Nicolas Williams
 wrote:
> Again, if everything is too hard, why do we bother even talking
> about any of this?  ETOOHARD cannot usefully be a retort to every
> suggestion.

Well, not everything is too hard. In fact, one of the important
characteristics of systems that work is that they're simple, and thus
tractable.

We were just discussing the problem of needing users to make fine
grained security decisions. Several obvious solutions exist here.

For example, the "there should be one mode, and it should be secure"
rule lowers the complexity users encounter quite a bit.
I know of at least one project to fix the browser PKI mess which
claims that they want to involve the users more, not less. This would
seem to be a big mistake to me.

On the other edge of the spectrum, many people now use quite secure
protocols (though I won't claim the full systems are secure --
implementation bugs are ubiquitous) for handling things like remote
login and file transfer, accessing shared file systems on networks,
etc., with little to no knowledge on their part about how their
systems work or are configured. This seems like a very good thing. One
may complain about many issues in Microsoft's systems, for example,
but adopting Kerberos largely fixed the distributed authentication
problem for them, and without requiring that users know what they're
doing.

Yet another reason (one of dozens) that X.509 has never worked right
for most users is the sheer number of knobs. There are too many
choices for mortals, and there will always be subtle configuration
failures that can catch even experts.

(I am reminded of the similar death-by-complexity of the IPSec
protocol's key management layers, where I am sad to report that even I
can't easily configure the thing. Some have proposed standardizing on
radically simplified profiles of the protocol that provide almost no
options -- I believe to be the last hope for the current IPSec suite.)


Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 01:25:21PM -0400, Perry E. Metzger wrote:
> My mother relies on many certificates. Can she make a decision on
> whether or not her browser uses OCSP for all its transactions?
> 
> I mention this only because your language here is quite sticky.
> Saying it is "up to the relying parties" is incorrect. It is really
> up to a host of people who are nowhere near the relying parties. In
> most cases, the relying parties aren't even capable of understanding
> the issue.

Precise and concise language in a fast moving thread with participants
with diverse backgrounds is going to be hard to come by.  Better to quit
than hold out for that (unless you enjoy being disappointed).  I'm
hardly the only "sinner" here on that score.

"up to the relying parties" means "up to the browsers", where users-as-
relying-parties are concerned.  That also means "getting software
updated", which to some degree means "getting my mom to do stuff she
doesn't and shouldn't have to know how".  It shouldn't mean "getting my
mom to enable OCSP" -- that would be hopeless.

"up to the relying parties" means "up to the server" as well, since
servers too are relying-parties.

Again, if everything is too hard, why do we bother even talking about
any of this?  ETOOHARD cannot usefully be a retort to every suggestion.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 11:20:52 -0500 Nicolas Williams
 wrote:
> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> > Again, I understand that in a technological sense, in an ideal
> > world, they would be equivalent. However, the big difference,
> > again, is that you can't run Kerberos with no KDC, but you can
> > run a PKI without an OCSP server. The KDC is impossible to leave
> > out of the system. That is a really nice technological feature.
> 
> Whether PKI can run w/o OCSP is up to the relying parties.  Today,
> because OCSP is an afterthought, they have little choice.

My mother relies on many certificates. Can she make a decision on
whether or not her browser uses OCSP for all its transactions?

I mention this only because your language here is quite sticky.
Saying it is "up to the relying parties" is incorrect. It is really
up to a host of people who are nowhere near the relying parties. In
most cases, the relying parties aren't even capable of understanding
the issue.


Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> Again, I understand that in a technological sense, in an ideal world,
> they would be equivalent. However, the big difference, again, is that
> you can't run Kerberos with no KDC, but you can run a PKI without an
> OCSP server. The KDC is impossible to leave out of the system. That is
> a really nice technological feature.

Whether PKI can run w/o OCSP is up to the relying parties.  Today,
because OCSP is an afterthought, they have little choice.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Thu, Jul 29, 2010 at 04:23:52AM +1200, Peter Gutmann wrote:
> Nicolas Williams  writes:
> >Sorry, but this is wrong.  The OCSP protocol itself really is an online
> >certificate status protocol.  
> 
> It's not an online certificate status protocol because it can provide neither
> a yes or a no response to a query about the validity of a certificate.

You should be more specific.  I'm looking at RFC2560 and I don't see
this.

OCSP Responses allow the Responder to assert:

 - A time at which the given cert was known to be valid (thisUpdate;
   REQUIRED).

   Relying parties are free to impose a "freshness" requirement (e.g.,
   thisUpdate must be no more than 5 minutes in the past).

   Perhaps you're concerned that protocols that allow for carrying OCSP
   Responses don't provide a way for peers to indicate what their
   freshness requirements are?

 - A time after which the given OCSP Response is not to be considered
   valid (nextUpdate, which is OPTIONAL).

 - The certificate's status (certStatus, one of good, revoked, unknown;
   REQUIRED).

How is responding "certStatus=good, thisUpdate="
not a "yes response to a query about the validity of a certificate"?

What am I missing?

> (For an online status protocol I want to be able to submit a cert and get back
> a straight valid/not valid response, exactly as I can for credit cards with
> their authorised/declined response.  Banks were doing this twenty years ago
> with creaky mainframes over X.25 and (quite probably) wet bits of string, but
> we still can't do this today with multicore CPUs and gigabit links if we're
> using OCSP).

OCSP gives you that.  Seriously.  In fact, an OCSP Responder either must
not respond or it must give you at least {certStatus, thisUpdate}
information about a cert.  Yes, certStatus can be "unknown", but a
Responder that regularly asserts certStatus=unknown would be a rather
useless responder.

> >Responder implementations may well be based on checking CRLs, but they aren't
> >required to be.
> 
> They may be, or they may not be, but you as a relying party have no way of 
> telling.

And why would a relying party need to know internal details of the OCSP
Responder?

> In any event though since OCSP can't say yes or no, it doesn't matter whether 
> the response is coming from a live database or a month-old CRL, since it's 
> still a fully CRL-bug-compatible blacklist I can trivially avoid it with a 
> manufactured-cert attack.

Manufactured cert attack?  If you can mint certs without having the CA's
private key then who cares about OCSP.  If you can do it only as a
result of hash collisions, well, switch hashes.  Let's not confuse hash
collision issues with whether OCSP does what it's advertised to do.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

On 07/28/2010 12:02 PM, Nicolas Williams wrote:

Sorry, but this is wrong.  The OCSP protocol itself really is an online
certificate status protocol.  Responder implementations may well be
based on checking CRLs, but they aren't required to be.

Don't be confused by the fact that OCSP borrows some elements from CRLs.


my OCSP analogy was turning authentication into an end in itself ... basically 
a new kind of retail store ... instead of retail store that sells some product 
... you go in and buy something ... doing a real-time payment transaction; ... 
there is an authentication store ... convince everybody that they need to walk 
into their (OCSP) authentication retail store at least once a day to perform an 
authentication operation (for no other reason that people should get a lot of 
comfort out of being authenticated at least once a day or more if necessary) 
... totally divorced and unrelated to any actual business purpose.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 11:23:16 -0500 Nicolas Williams
 wrote:
> On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote:
> > On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> > > Again, I understand that in a technological sense, in an ideal
> > > world, they would be equivalent. However, the big difference,
> > > again, is that you can't run Kerberos with no KDC, but you can
> > > run a PKI without an OCSP server. The KDC is impossible to
> > > leave out of the system. That is a really nice technological
> > > feature.
> > 
> > Whether PKI can run w/o OCSP is up to the relying parties.  Today,
> > because OCSP is an afterthought, they have little choice.
> 
> Also, requiring OCSP will probably take less effort than switching
> from PKI to Kerberos.  In other words: eveything sucks.

I wouldn't suggest that everything on earth move to Kerberos. I
mentioned Kerberos only to show that entirely different models are
possible.

As to OCSP being a reasonable solution because it can be deployed
easily, it clearly will not solve the browser security problem. So
long as security depends on reliance on the lowest common denominator
among the policies of hundreds of CAs, many of which are quite
questionable, and so long as the certifications made by even the best
of those CAs are effectively meaningless, and so long as the users are
well trained to ignore every browser warning they ever get, the entire
question of OCSP is somewhat irrelevant -- it would just be a way of
spritzing the skunk with eau de cologne.

I fully recognize that the odds we will fix the browser security
problem are very low, if only because no one can deploy a truly new
solution in a world where we can't even get IE 6 to die.

However, in discussing this at a high level, as though we could
improve things, we shouldn't kid ourselves about the current model. It
is fatally broken. Hanging garlands from the corpse's ears will not
convince anyone that it has a vibrant future ahead.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Nicolas Williams  writes:

>Sorry, but this is wrong.  The OCSP protocol itself really is an online
>certificate status protocol.  

It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.

(For an online status protocol I want to be able to submit a cert and get back
a straight valid/not valid response, exactly as I can for credit cards with
their authorised/declined response.  Banks were doing this twenty years ago
with creaky mainframes over X.25 and (quite probably) wet bits of string, but
we still can't do this today with multicore CPUs and gigabit links if we're
using OCSP).

>Responder implementations may well be based on checking CRLs, but they aren't
>required to be.

They may be, or they may not be, but you as a relying party have no way of 
telling.  OCSP covers not only the three incompatible business models of the 
different authors' employers but, for good measure, an extra "anything else 
you may care to do" option if the first three aren't enough.  A decade after 
it was published, PKI experts are still arguing over what various bits of the 
OCSP spec actually mean (the PKIX list has only just gone through yet another 
round of this... *ten years* later and domain experts still can't agree on how 
it's supposed to work).  So given the schizophrenic nature of the RFC you can 
easily claim "but you can do X" because chances are if you read it just right 
you probably can.  Unfortunately this doesn't give a relying party much to 
rely on, because they have absolutely no idea what they're getting, it could 
be anything from a live database query to a value from a month-old CRL to 
(thanks to the removal of nonces from the protocol a few years ago) an 
attacker replaying an old "not-revoked" value (although I don't know why 
they'd even bother with that, given the state of revocation checking in client 
software).

In any event though since OCSP can't say yes or no, it doesn't matter whether 
the response is coming from a live database or a month-old CRL, since it's 
still a fully CRL-bug-compatible blacklist I can trivially avoid it with a 
manufactured-cert attack.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 11:20:51AM -0500, Nicolas Williams wrote:
> On Wed, Jul 28, 2010 at 12:18:56PM -0400, Perry E. Metzger wrote:
> > Again, I understand that in a technological sense, in an ideal world,
> > they would be equivalent. However, the big difference, again, is that
> > you can't run Kerberos with no KDC, but you can run a PKI without an
> > OCSP server. The KDC is impossible to leave out of the system. That is
> > a really nice technological feature.
> 
> Whether PKI can run w/o OCSP is up to the relying parties.  Today,
> because OCSP is an afterthought, they have little choice.

Also, requiring OCSP will probably take less effort than switching from
PKI to Kerberos.  In other words: eveything sucks.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 10:50:52 -0500 Nicolas Williams
 wrote:
> On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote:
> > On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
> >  wrote:
> > > OCSP Responses are much like a PKI equivalent of Kerberos
> > > tickets. All you need to do to revoke a principal with OCSP is
> > > to remove it from the Responder's database or mark it revoked.
> > 
> > Actually, that's untrue in one very important respect.
> > 
> > In a Kerberos style system, you actively ask for credentials to do
> > things at frequent intervals, and if the KDCs refuse to talk to
> > you, you get no credentials.
> > 
> > In OCSP, we've inverted that. You have the credentials, for years
> > in most cases, and someone else has to actively check that
> > they're okay -- and in most instances, if they fail to get
> > through to an OCSP server, they will simply accept the
> > credentials.
> 
> No, they really are semantically equivalent.

Again, I understand that in a technological sense, in an ideal world,
they would be equivalent. However, the big difference, again, is that
you can't run Kerberos with no KDC, but you can run a PKI without an
OCSP server. The KDC is impossible to leave out of the system. That is
a really nice technological feature.

Peter Gutmann has pointed out other critical distinctions, but I'll
let his message stand for itself.


Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Thu, Jul 29, 2010 at 03:51:33AM +1200, 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.  Specifically, if I submit a freshly-issued, valid certificate 
> to 
> an OCSP responder and ask "is this a valid certificate" then it can't say 
> yes, 
> and if I submit an Excel spreadsheet to an OCSP responder and ask "is this a 
> valid certificate" then it can't say no.  It takes quite some effort to 
> design 
> an online certificate status protocol that's that broken.
> 
> (For people not familiar with OCSP, it can't say "yes" because a CRL can't 
> say 
> "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).

Sorry, but this is wrong.  The OCSP protocol itself really is an online
certificate status protocol.  Responder implementations may well be
based on checking CRLs, but they aren't required to be.

Don't be confused by the fact that OCSP borrows some elements from CRLs.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 11:38:28AM -0400, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
>  wrote:
> > OCSP Responses are much like a PKI equivalent of Kerberos tickets.
> > All you need to do to revoke a principal with OCSP is to remove it
> > from the Responder's database or mark it revoked.
> 
> Actually, that's untrue in one very important respect.
> 
> In a Kerberos style system, you actively ask for credentials to do
> things at frequent intervals, and if the KDCs refuse to talk to you,
> you get no credentials.
> 
> In OCSP, we've inverted that. You have the credentials, for years in
> most cases, and someone else has to actively check that they're okay
> -- and in most instances, if they fail to get through to an OCSP
> server, they will simply accept the credentials.

No, they really are semantically equivalent.  In Kerberos (traditional,
pre-PKINIT Kerberos) the long-term credential is {principal name,
long-term secret key} or {principal name, password}, and the temporary
credential is the Kerberos Ticket.  In PKI+OCSP the long-term credential
is {certificate, private key}, and the temporary credentials is
{certificate, private key, fresh OCSP Response}.

Both, Kerberos and PKI+OCSP replace a long-term credential with a
short-lived, temporary credential authenticating the same principal.

> OCSP is hung on to the side of X.509 as an afterthought, so it cannot
> [...]

Yes, but it's still "morally equivalent" to Kerberos as described above,
but with PK instead of KDCs and shared secret keys.

Also, PKI+OCSP is somewhat less dependent on online infrastructure than
Kerberos because: a) just one OCSP Response will do[*], vs. a multitude
of service Tickets, b) OCSP Responders don't need access to the CA's
private key, whereas the KDCs do need access to the TGS keys.  Also,
OCSP Responses can be cached by the network, whereas Kerberos Tickets
cannot be (since they are useless[**] without the corresponding session
key).

[*]  It helps to have protocols where subjects can send OCSP responses
 for their own certs to their peers.  It also helps to have
 protocols where client subjects can get OCSP Responses for their
 own certs from their peers and then re-use those Responses later.

[**] I'm ignoring user-to-user authentication here.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

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.  Specifically, if I submit a freshly-issued, valid certificate to 
an OCSP responder and ask "is this a valid certificate" then it can't say yes, 
and if I submit an Excel spreadsheet to an OCSP responder and ask "is this a 
valid certificate" then it can't say no.  It takes quite some effort to design 
an online certificate status protocol that's that broken.

(For people not familiar with OCSP, it can't say "yes" because a CRL can't say 
"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).

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 09:57:21 -0500 Nicolas Williams
 wrote:
> OCSP Responses are much like a PKI equivalent of Kerberos tickets.
> All you need to do to revoke a principal with OCSP is to remove it
> from the Responder's database or mark it revoked.

Actually, that's untrue in one very important respect.

In a Kerberos style system, you actively ask for credentials to do
things at frequent intervals, and if the KDCs refuse to talk to you,
you get no credentials.

In OCSP, we've inverted that. You have the credentials, for years in
most cases, and someone else has to actively check that they're okay
-- and in most instances, if they fail to get through to an OCSP
server, they will simply accept the credentials.

OCSP is hung on to the side of X.509 as an afterthought, so it cannot
be enforced as part of the system. In Kerberos, the online aspect is
burned into the protocol and cannot be avoided. There is no such thing
as a Kerberos installation that chooses not to use KDCs.

> > SSH does appear to have got away without revocation, though the
> > nature of the system is s.t. if I really wanted to revoke I could
> > almost always contact the users and tell them in person. This
> > doesn't scale very well to SSL-style systems.
> 
> The SSH ad-hoc pubkey model is a public key pre-sharing (for user
> keys) and pre-sharing and/or leap-of-faith (for host keys) model.
> It doesn't scale without infrastructure.  Add infrastructure and
> you're back to a PKI-like model (maybe with no hierarchy, but
> still).

There are two parts to the SSH model that should be segregated in
discussions.

One part is the "I've seen this one before" key validation model. I
think there is merit in parts of that for many sorts of systems (say,
secure email), and it is also worth discussing, but there is a second
thing here which is usually ignored that I would prefer to concentrate
on for now.

The other part, which is very important, is the "we authorize keys by
storing them in a database, we de-authorize them by removing them"
model. This is typically used by Kerberized apps as well, though
Kerberos doesn't generally impose a particular authorization model.

Now, to some people, the "the key is in the database" model might seem
trivial, or obvious, or otherwise insignificant. I think that's a
mistake -- it is a critical part of what makes SSH work so well.

The system is not relying on an old signature on a data structure
around the key to say that the key is authorized. The system relies on
something much simpler: keeping an up to date database of what keys
are allowed. We can change that database at will, in real time.

In this model, some external protocol might or might not be available
to automate maintenance of that database, and the database might or
might not be local to the host, but that part is conceptually entirely
separate.

The important part is that we are not relying on cryptography to
handle the authorization -- we are not going to let someone in because
a third party signed something last year. Cryptography handles only
proving that someone holds a particular private key -- it isn't even
handling authentication of a party per se. We decide to give
privileges to the holder of that private key because a database check
performed right now showed the particular key was in the database as
authorized.

I believe this way of doing things deserves much closer scrutiny. It
is far simpler. It is far easier to understand the security properties
of such a system. There are far fewer systems whose compromise will
compromise the authorization decision. These are under-appreciated
features.


Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

On 07/28/2010 11:05 AM, Nicolas Williams wrote:

Are you arguing for Kerberos for Internet-scale deployment?  Or simply
for PKI with rp-only certs and OCSP?  Or other "federated"
authentication mechanism?  Or all of the above?  :)


as i've mentioned ... the relying-party-only certificates are almost always 
redundant and superfluous ... except in cases where the relying party can't 
justify their own repository of information and/or distributed access to such a 
repository of information.

I previously mentioned that in the payment transaction case, even a 
relying-party-only certificate was a factor of 100-times payload size bloat for 
typical payment transactions ... aka not only was the certificate redundant and 
superfluous ... but it represented an enormous (redundant and superfluous) 
processing burden.

I've mentioned a number of times that OCSP appeared after I had repeatedly ridiculed 
revokation process being archaic backwards step for real-time payment processes. And that 
even OCSP (with a certificate) is still redundant and superfluous when real-time 
transaction is being performed using the "real" information.

the other scenario for rpo-certs ... besides for no-value operations ...  is 
when the real infrastructure is down and/or not accessible. But that usually is 
matter of cost also, some of the higher-value operations have gone to 
significant redundancy and claim 100% availability. The certificate analogy is 
still the letters of credit/introduction from sailing ship days ... when the 
relying-party had no (other) access to first time interaction with complete 
stranger (and has to fall back to much cruder and lower quality information).

There is also some scenario if the respository and the service are co-located 
... that when the repository is unavailable the service will also be 
unavailable ... so there is no requirement for independent source of 
information.

The catch22 for certification authority operation ... is that as they move further 
& further into the no-value market niches (and/or market niches that can't 
justify the expense of higher quality operation with real-time repository) ... they 
are forced to cut their fees and indirectly the quality of their operation.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 11:13:36AM -0400, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams
>  wrote:
> 
> I have no objections to "infrastructure" -- bridges, the Internet,
> and electrical transmission lines all seem like good ideas. However,
> lets avoid using the term "Public Key Infrastructure" for things that
> depart radically from the Kohnfelder and subsequent X.509 models.

Well, OK.  But PKI no longer means that, not with bridges and what not
in the picture.

> > Infrastructure (whether of a pk variety or otherwise) and transitive
> > trust probably have to be part of the answer for scalability
> > reasons, even if transitive trust is a distasteful concept.
> 
> Well, it depends a lot on what kind of trust.
> 
> Let me remind everyone of one of my long-standing arguments.
> 
> Say that Goldman Sachs wants to send Morgan Stanley an order for a
> billion dollars worth of bonds. Morgan Stanley wants to know that
> Goldman sent the order, because the consequences of a mistake on a
> transaction this large would be disastrous.

Indeed.  They must first establish a direct trust relationship.  They
might leverage transitive trust to bootstrap direct trust if doing so
makes the process easier (which it almost certainly does, and which we
use in the off-line world all the time using pieces of paper or plastic
issued by various authorities, such as "drivers' licenses", "passports",
...).

> > However, we need to be able to build direct trust relationships,
> > otherwise we'll just have a house of transitive trust cards.
> > Again, think of the the SSH leap-of- faith and "SSL pinning"
> > concepts, but don't constrain yourselves purely to pk technology.
> 
> I believe we may, in fact, be in violent agreement here.

We are.  Perhaps I hadn't made my point obvious enough: transitive trust
is necessary, but primarily as a method of bootstrapping direct trust
relationships.  I really should have used that specific formulation.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 09:30:22 -0500 Nicolas Williams
 wrote:
> On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote:
> > PKI was invented by Loren Kohnfelder for his bachelor's degree
> > thesis at MIT. It was certainly a fine undergraduate paper, but I
> > think we should forget about it, the way we forget about most
> > undergraduate papers.
> 
> PKI alone is certainly not the answer to all our problems.
> 
> Infrastructure

Let me interrupt here and say that when I refer to PKI, I mean the
Kohnfelder model which we have been following, which is the model of
very long lived "phone books" of hierarchically issued certificates
along with very long lived lists of revoked certificates, all
designed with an offline world in mind.

I have no objections to "infrastructure" -- bridges, the Internet,
and electrical transmission lines all seem like good ideas. However,
lets avoid using the term "Public Key Infrastructure" for things that
depart radically from the Kohnfelder and subsequent X.509 models.

> Infrastructure (whether of a pk variety or otherwise) and transitive
> trust probably have to be part of the answer for scalability
> reasons, even if transitive trust is a distasteful concept.

Well, it depends a lot on what kind of trust.

Let me remind everyone of one of my long-standing arguments.

Say that Goldman Sachs wants to send Morgan Stanley an order for a
billion dollars worth of bonds. Morgan Stanley wants to know that
Goldman sent the order, because the consequences of a mistake on a
transaction this large would be disastrous.

Should they trust Verisign's ExtraSuperHighValue certificate presented
by Goldman? No. Why? Because Verisign disclaims all effective
liability for the use of its certs. It is not a party to the
transaction being conducted. If it was actually insuring all
transactions conducted with the certificate, then Morgan could trust
them, because the counterparty who's credit would be at issue would no
longer be Goldman but Verisign. However, Verisign won't even pay out
if it turned out that they gave signed a Goldman cert and it was in
fact held by a scammer.

The problem with Certification Authorities is they certify
NOTHING. There can be no reliance on them, because they have no
liability of any sort in any transaction.

So, in the real world, Goldman and Morgan come up with ways of making
sure they trust each other's communications and credit lines. Even
when we're dealing with small transactions, like buying a book at a
book store with a credit card, if you trace it out, we're dealing with
nothing but a web of bilateral commercial relationships.

So, I have no trouble with various kinds of trust. What I have trouble
with is the sort of false trust that a CA implies. CAs certify nothing
in a real world business sense -- they are just toll collectors.

> However, we need to be able to build direct trust relationships,
> otherwise we'll just have a house of transitive trust cards.
> Again, think of the the SSH leap-of- faith and "SSL pinning"
> concepts, but don't constrain yourselves purely to pk technology.

I believe we may, in fact, be in violent agreement here.


Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 16:01, Perry E. Metzger wrote:
> On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie  wrote:
>> SSH does appear to have got away without revocation, though the
>> nature of the system is s.t. if I really wanted to revoke I could
>> almost always contact the users and tell them in person.
> 
> No, that's not what SSH does, or rather, it confuses the particular
> communications channel (i.e. some out of band mechanism) with the
> method that actually de-authorizes the key.
> 
> The point is that in SSH, if a key is stolen, you remove it from the
> list of keys allowed to log in to a host. The key now need never be
> thought about again. We require no list of "revoked keys" be kept,
> just as we required no signed list of keys that were authorized. We
> just had some keys in a database to indicate that they were
> authorized, and we removed a key to de-authorize it.

I am referring to the SSH host key. Fully agree for user keys.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 10:42:43AM -0400, Anne & Lynn Wheeler wrote:
> On 07/28/2010 10:05 AM, Perry E. Metzger wrote:
> >I will point out that many security systems, like Kerberos, DNSSEC and
> >SSH, appear to get along with no conventional notion of revocation at all.
> 
> long ago and far away ... one of the tasks we had was to periodically
> go by project athena to "audit" various activities ... including
> Kerberos. The original PK-INIT for kerberos was effectively
> certificateless public key ... 

And PKINIT today also allows for rp-only user certs if you want them.
They must be certificates, but they needn't carry any useful data beyond
the subject public key, and the KDC must know the {principal,
cert|pubkey} associations.

> An issue with Kerberos (as well as RADIUS ... another major
> authentication mechanism) ... is that account-based operation is
> integral to its operation ... unless one is willing to go to a
> strictly certificate-only mode ... where all information about an
> individuals authority and access privileges are also carried in the
> certificate (and eliminate the account records totally).

This is true time you have rp-only certs or certs that carry less
information than the rp will require.  The latter almost always true.
The account can be local to each rp, however, or centralized -- that's
up to the relying parties.

> As long as the account record has to be accessed as part of the
> process ... the certificate remains purely redundant and superfluous
> (in fact, some number of operations running large Kerberos based
> infrastructure have come to realize that they have large redundant
> administrative activity maintaining both the account-based information
> as well as the duplicate PKI certificate-based information).

Agreed.  Certificates should, as much as possible, be rp-only.

> The account-based operations have sense of revocation by updating the
> account-based records. [...]

Exactly.  OCSP can work in that manner.  CRLs cannot.  In terms of
administration updating an account record is much simpler than updating
a CRL (because much less information needs to be available for the
former than for the latter).

> The higher-value operations tend to be able to justify the real-time,
> higher quality, and finer grain information provided by an
> account-based infrastructure ... and as internet and technology has
> reduced the costs and pervasiveness of such operations ... it further
> pushes PKI, certificate-based mode of operation further and further
> into no-value market niches.

Are you arguing for Kerberos for Internet-scale deployment?  Or simply
for PKI with rp-only certs and OCSP?  Or other "federated"
authentication mechanism?  Or all of the above?  :)

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 15:16:32 +0100 Ben Laurie  wrote:
> On 28 July 2010 15:05, Perry E. Metzger  wrote:
> > On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie  wrote:
> >>
> >> And still needs revocation.
> >
> > Does it?
> >
> > I will point out that many security systems, like Kerberos,
> > DNSSEC and SSH, appear to get along with no conventional notion
> > of revocation at all
>
> Maybe it doesn't, but no revocation mechanism at all makes me
> nervous.

I think that is because you are thinking in terms of certificates,
which naturally would require such a mechanism.

> I don't know Kerberos well enough to comment.

In kerberos, tickets are short lived -- one can simply fail to give
the person who stole a credential new ones, and in the interim, one
can remove the authorization that a particular principal has.

> DNSSEC doesn't have revocation but replaces it with very short
> signature lifetimes (i.e. you don't revoke, you time out).

Yes. Precisely.

> SSH does appear to have got away without revocation, though the
> nature of the system is s.t. if I really wanted to revoke I could
> almost always contact the users and tell them in person.

No, that's not what SSH does, or rather, it confuses the particular
communications channel (i.e. some out of band mechanism) with the
method that actually de-authorizes the key.

The point is that in SSH, if a key is stolen, you remove it from the
list of keys allowed to log in to a host. The key now need never be
thought about again. We require no list of "revoked keys" be kept,
just as we required no signed list of keys that were authorized. We
just had some keys in a database to indicate that they were
authorized, and we removed a key to de-authorize it.

> This doesn't scale very well to SSL-style systems.

I believe it does scale. Pretty much by definition, if you can get to
a web site, your Internet connectivity is working. That means that
there is no need for methods like having a signed key that lasts for
years so you can cache it for offline use.

I'm sure you remember the 1960s and 1970s well, as we are both a bit
past our youth. In the US, at least, every store clerk had in their
hands an unwieldy, telephone-book sized list of stolen credit card
numbers they had to consult at each credit card transaction. In those
days, there were no cheap modems and doing on-line verification was
impossible.

The whole point of Kohnfelder's thesis was, in effect, to turn the
1970s era books of stolen numbers into an offline machine readable
list. You signed a long-lived credential so that it could be checked
offline, and you kept a big book of withdrawn credentials around so
you could check them offline as well. It was a model from the era in
which everyone had a paper phone book. It was designed for the era
where networks were a rarity.

We no longer live in that era. The models used by Kerberos, DNSSEC,
SSH, and such, make far more sense. We no longer need revocation.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 03:16:32PM +0100, Ben Laurie wrote:
> Maybe it doesn't, but no revocation mechanism at all makes me nervous.
> 
> I don't know Kerberos well enough to comment.
> 
> DNSSEC doesn't have revocation but replaces it with very short
> signature lifetimes (i.e. you don't revoke, you time out).

Kerberos too lacks revocation, and it also makes up for it with short
ticket lifetimes.

OCSP Responses are much like a PKI equivalent of Kerberos tickets.  All
you need to do to revoke a principal with OCSP is to remove it from the
Responder's database or mark it revoked.  To revoke an individual
certificate you need only mark a date for the given subject such that no
cert issued prior to it will be considered valid.

An OCSP Responder implementation could be based on checking a real CRL
or checking a database of known subjects (principals).  Whichever is
likely to be smaller over time is best, though the latter is just
simpler to administer (since you don't need to know the subject public
key nor the issuer&serial, nor the actual TBSCertificate in order to
revoke, just the subject name and current date and time).

> SSH does appear to have got away without revocation, though the nature
> of the system is s.t. if I really wanted to revoke I could almost
> always contact the users and tell them in person. This doesn't scale
> very well to SSL-style systems.

The SSH ad-hoc pubkey model is a public key pre-sharing (for user keys)
and pre-sharing and/or leap-of-faith (for host keys) model.  It doesn't
scale without infrastructure.  Add infrastructure and you're back to a
PKI-like model (maybe with no hierarchy, but still).

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Jack Lloyd]

On Wed, Jul 28, 2010 at 08:48:14AM -0400, Steven Bellovin wrote:

> There seem to be at least three different questions here: bad code
> (i.e., that Windows doesn't check the revocation status properly),
> the UI issue, and the conceptual question of what should replace the
> current PKI+{CRL,OCSP} model.  For the last issue, I'd note that
> using pki instead of PKI (i.e., many different per-realm roots,
> authorization certificates rather than identity certificates, etc.)
> doesn't help: Realtek et al. still have no better way or better
> incentive to revoke their own widely-used keys.

With a sufficiently fine grained authorization model inside the OS,
there is no reason in principle that something like attribute
certificates couldn't work - RealTek would have a code signing cert
only valid for drivers that talked to network cards with specific PCI
vendors IDs, and UI tools that talked to that driver - the signature
on the worm binary in question would be valid, but the worm would not
be given the permissions it wants to actually do its thing. (Eg, when
was the last time you had a network driver that needed to access an
MSSQL db). Windows is not that OS. (Neither is Linux or BSD of
course). It looks like Singularity has some features which could
support this sort of model [1].

This is not to suggest this is at all an easy course of action to
take; my point is just that it's possible to do much better here
without having to alter anyone's incentives: the CAs still collect
their rent, and RealTek's drivers still work. Fixing the OS is
probably easier than somehow fixing PKI to do what we'd nominally want
it to do here (though actually revoking the cert would have been a
good start) or modifying the obvious incentives.

-Jack

[1] http://research.microsoft.com/apps/pubs/default.aspx?id=59976

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 15:18, Peter Gutmann wrote:
> Ben Laurie  writes:
> 
>> However, using private keys to prove that you are (probably) dealing with 
>> the 
>> same entity as yesterday seems like a useful thing to do. And still needs 
>> revocation.
> 
> It depends on what you mean by revocation, traditional revocation in the PKI 
> sense isn't needed because (well apart from the fact that it doesn't work, 
> you 
> can't un-say something after you've already said it) if you look at what a PK 
> or a cert is, it's just a capability, and the way to revoke (in the 
> capability 
> sense) a capability is to do something like rename the object that the 
> capability refers to or use a level of indirection and break the link when 
> you 
> want to revoke (in the capability sense) the access.  This means that no 
> matter how many copies of the capability are floating around out there and 
> whether the relying party checks CRLs or not, they're not going to be able to 
> get in.

Now you are talking my language! Have I mentioned that my new project at
Google is all about finding good UI for exposing capabilities to users?

>> Is there a good replacement for pk for this purpose?
> 
> Which purpose?  If you mean securing the distribution channel for binaries, 
> here's a very simple one that doesn't need PK at all, it's called a 
> self-authenticating URL.  To use it you go to your software site, and here's 
> a 
> real-world example that uses it, the Python Package Index, and click on a 
> download link, something like 
> http://pypi.python.org/packages/package.gz#md5= (yeah, I know, it uses 
> MD5...).  This link can point anywhere, because the trusted source of the 
> link 
> includes a hash of the binary (and in this case it's a non-HTTPS source, you 
> can salt and pepper it as required, for exammple make it an HTTPS link and 
> use 
> key continuity to manage the cert).  In this form the concept is called link 
> fingerprints, it was actually implemented for Firefox as a Google Summer of 
> Code project, but then removed again over concerns that if it was present 
> people might actually use it (!!).  It's still available in DL managers like 
> DownThemAll.

The problem here is that it doesn't directly give me an upgrade path. Of
course, I agree that this is sufficient to give me a link to the "right"
binary, but what about its successors?

> Another option is to cryptographically bind the key to the URL, so you again 
> have a trusted link source for your download and the link is to 
> https://.downloadsite.com, where  is a fingerprint of the 
> cert 
> you get when you connect to the site.  This does away with the need for a CA,
> because the link itself authenticates the cert that's used.

Yes, this is of course the YURL scheme.

> Then there are other variations, cryptographically generated addresses, ... 
> all sorts of things have been proposed.
> 
> The killer, again, is the refusal of any browser vendor to adopt any of it.  
> In the case of FF someone actually wrote the code for them, and it was 
> rejected.  Without support from browser vendors, it doesn't matter what cool
> ideas people come up with, it's never going to get any better.
> 
> Peter.
> 
> 


-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Stefan Kelm]

Perry,


I think public key cryptography is a wonderful thing. I'm just not
sure I believe at all in PKI -- that is, persistent certification via
certificates, certificate revocation, etc.


I'm sure you remember Peter Honeyman's "PK-no-I" talk from
the '99 USENIX Security Symposium?  :-)

Cheers,

Stefan.

--
Stefan Kelm   
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstrasse 100 Tel: +49-721-96201-1
D-76133 Karlsruhe Fax: +49-721-96201-99

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Anne & Lynn Wheeler]

On 07/28/2010 10:05 AM, Perry E. Metzger wrote:

I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.
 
long ago and far away ... one of the tasks we had was to periodically go by project athena to "audit" various activities ... including Kerberos. The original PK-INIT for kerberos was effectively certificateless public key ... aka replace registering a shared-secret password (for authentication) with a public key. There was then some amount of lobbying by the certification authority interests for pk-init to include certificate-based mode of operation (I wrote the draft-words for PK-INIT for inclusion of certificateless ecdsa).


An issue with Kerberos (as well as RADIUS ... another major authentication 
mechanism) ... is that account-based operation is integral to its operation ... 
unless one is willing to go to a strictly certificate-only mode ... where all 
information about an individuals authority and access privileges are also 
carried in the certificate (and eliminate the account records totally).

As long as the account record has to be accessed as part of the process ... the 
certificate remains purely redundant and superfluous (in fact, some number of 
operations running large Kerberos based infrastructure have come to realize 
that they have large redundant administrative activity maintaining both the 
account-based information as well as the duplicate PKI certificate-based 
information).

The account-based operations have sense of revocation by updating the 
account-based records. This can be done in real-time and at much finer levels 
of granularity than the primitive, brute-force (PKI) revocation (and 
replacement). For instance, have you gone over your outstanding balance or 
credit-limit? ... are you up-to-date with you ISP account? ... or should it 
just be temporarily suspended bending receipt of funds. Account records can 
carry other kinds of real-time information ... like whether currently logged on 
... and should duplicate, simultaneous logons be prevented (difficult to 
achieve with redundant and superfluous, stale, static certificates).

The higher-value operations tend to be able to justify the real-time, higher 
quality, and finer grain information provided by an account-based 
infrastructure ... and as internet and technology has reduced the costs and 
pervasiveness of such operations ... it further pushes PKI, certificate-based 
mode of operation further and further into no-value market niches.

--
virtualization experience starting Jan1968, online at home since Mar1970

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 10:05:22AM -0400, Perry E. Metzger wrote:
> PKI was invented by Loren Kohnfelder for his bachelor's degree thesis
> at MIT. It was certainly a fine undergraduate paper, but I think we
> should forget about it, the way we forget about most undergraduate
> papers.

PKI alone is certainly not the answer to all our problems.

Infrastructure (whether of a pk variety or otherwise) and transitive
trust probably have to be part of the answer for scalability reasons,
even if transitive trust is a distasteful concept.  However, we need to
be able to build direct trust relationships, otherwise we'll just have a
house of transitive trust cards.  Again, think of the the SSH leap-of-
faith and "SSL pinning" concepts, but don't constrain yourselves purely
to pk technology.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Ben Laurie  writes:

>However, using private keys to prove that you are (probably) dealing with the 
>same entity as yesterday seems like a useful thing to do. And still needs 
>revocation.

It depends on what you mean by revocation, traditional revocation in the PKI 
sense isn't needed because (well apart from the fact that it doesn't work, you 
can't un-say something after you've already said it) if you look at what a PK 
or a cert is, it's just a capability, and the way to revoke (in the capability 
sense) a capability is to do something like rename the object that the 
capability refers to or use a level of indirection and break the link when you 
want to revoke (in the capability sense) the access.  This means that no 
matter how many copies of the capability are floating around out there and 
whether the relying party checks CRLs or not, they're not going to be able to 
get in.

>Is there a good replacement for pk for this purpose?

Which purpose?  If you mean securing the distribution channel for binaries, 
here's a very simple one that doesn't need PK at all, it's called a 
self-authenticating URL.  To use it you go to your software site, and here's a 
real-world example that uses it, the Python Package Index, and click on a 
download link, something like 
http://pypi.python.org/packages/package.gz#md5= (yeah, I know, it uses 
MD5...).  This link can point anywhere, because the trusted source of the link 
includes a hash of the binary (and in this case it's a non-HTTPS source, you 
can salt and pepper it as required, for exammple make it an HTTPS link and use 
key continuity to manage the cert).  In this form the concept is called link 
fingerprints, it was actually implemented for Firefox as a Google Summer of 
Code project, but then removed again over concerns that if it was present 
people might actually use it (!!).  It's still available in DL managers like 
DownThemAll.

Another option is to cryptographically bind the key to the URL, so you again 
have a trusted link source for your download and the link is to 
https://.downloadsite.com, where  is a fingerprint of the cert 
you get when you connect to the site.  This does away with the need for a CA,
because the link itself authenticates the cert that's used.

Then there are other variations, cryptographically generated addresses, ... 
all sorts of things have been proposed.

The killer, again, is the refusal of any browser vendor to adopt any of it.  
In the case of FF someone actually wrote the code for them, and it was 
rejected.  Without support from browser vendors, it doesn't matter what cool
ideas people come up with, it's never going to get any better.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28 July 2010 15:05, Perry E. Metzger  wrote:
> On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie  wrote:
>> On 28/07/2010 14:05, Perry E. Metzger wrote:
>> > It is not always the case that a dead technology has failed
>> > because of infeasibility or inapplicability. I'd say that a
>> > number of fine technologies have failed for other reasons.
>> > However, at some point, it becomes incumbent upon the proponents
>> > of a failed technology to either demonstrate that it can be made
>> > to work in a clear and convincing way, or to abandon it even if,
>> > on some level, they are certain that it could be made to work if
>> > only someone would do it.
>>
>> To be clear, I am not a proponent of PKI as we know it, and
>> certainly the current use of PKI to sign software has never
>> delivered any actual value, and still wouldn't if revocation worked
>> perfectly.
>>
>> However, using private keys to prove that you are (probably) dealing
>> with the same entity as yesterday seems like a useful thing to do.
>
> I agree with that fully.
>
>> And still needs revocation.
>
> Does it?
>
> I will point out that many security systems, like Kerberos, DNSSEC and
> SSH, appear to get along with no conventional notion of revocation at 
> all-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 14:38:53 +0100 Ben Laurie  wrote:
> On 28/07/2010 14:05, Perry E. Metzger wrote:
> > It is not always the case that a dead technology has failed
> > because of infeasibility or inapplicability. I'd say that a
> > number of fine technologies have failed for other reasons.
> > However, at some point, it becomes incumbent upon the proponents
> > of a failed technology to either demonstrate that it can be made
> > to work in a clear and convincing way, or to abandon it even if,
> > on some level, they are certain that it could be made to work if
> > only someone would do it.
> 
> To be clear, I am not a proponent of PKI as we know it, and
> certainly the current use of PKI to sign software has never
> delivered any actual value, and still wouldn't if revocation worked
> perfectly.
> 
> However, using private keys to prove that you are (probably) dealing
> with the same entity as yesterday seems like a useful thing to do.

I agree with that fully.

> And still needs revocation.

Does it?

I will point out that many security systems, like Kerberos, DNSSEC and
SSH, appear to get along with no conventional notion of revocation at all.

> Is there a good replacement for pk for this purpose?

I think public key cryptography is a wonderful thing. I'm just not
sure I believe at all in PKI -- that is, persistent certification via
certificates, certificate revocation, etc.

PKI was invented by Loren Kohnfelder for his bachelor's degree thesis
at MIT. It was certainly a fine undergraduate paper, but I think we
should forget about it, the way we forget about most undergraduate
papers.

Perry
-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 14:05, Perry E. Metzger wrote:
> It is not always the case that a dead technology has failed because of
> infeasibility or inapplicability. I'd say that a number of fine
> technologies have failed for other reasons. However, at some point, it
> becomes incumbent upon the proponents of a failed technology to
> either demonstrate that it can be made to work in a clear and
> convincing way, or to abandon it even if, on some level, they are
> certain that it could be made to work if only someone would do it.

To be clear, I am not a proponent of PKI as we know it, and certainly
the current use of PKI to sign software has never delivered any actual
value, and still wouldn't if revocation worked perfectly.

However, using private keys to prove that you are (probably) dealing
with the same entity as yesterday seems like a useful thing to do. And
still needs revocation.

Is there a good replacement for pk for this purpose?

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Steven Bellovin  writes:

>For the last issue, I'd note that using pki instead of PKI (i.e., many 
>different per-realm roots, authorization certificates rather than identity 
>certificates, etc.) doesn't help: Realtek et al. still have no better way or 
>better incentive to revoke their own widely-used keys.

I think the problems go a bit further than just Realtek's motivation, if you 
look at the way it's supposed to work in all the PKI textbooks it's:

  Time t: Malware appears signed with a stolen key.
  Shortly after t: Realtek requests that the issuing CA revoke the cert.
  Shortly after t': CA revokes the cert.
  Shortly after t'': Signature is no longer regarded as valid.

What actually happened was:

  Time t: Malware appears signed with a stolen key.
  Shortly after t: Widespread (well, relatively) news coverage of the issue.

  Time t + 2-3 days: The issuing CA reads about the cert problem in the news.
  Time t + 4-5 days: The certificate is revoked by the CA.
  Time t + 2 weeks and counting: The certificate is regarded as still valid by
the sig-checking software.

That's pretty much what you'd expect if you're familiar with the realities of 
PKI, but definitely not PKI's finest hour.  In addition you have:

  Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than
the victims)
  Shortly after t - lots: AV vendors add it to their AV databases and push out
updates

(I don't know what "lots" is here, it seems to be anything from weeks to
months depending on which news reports you go with).

So if I'm looking for a defence against signed malware, it's not going to be 
PKI.  That was the point of my previous exchange with Ben, assume that PKI 
doesn't work and you won't be disappointed, and more importantly, you now have 
the freedom to design around it to try and find mechanisms that do work.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Stefan Kelm]

Peter,

In any case though the whole thing is really a moot point given the sucking 
void that is revocation-handling, the Realtek certificate was revoked on the 
16th but one of my spies has informed me that as of yesterday it was still 
regarded as valid by Windows.  


I can confirm that, at least for XP SP3: revocation just doesn't
matter. What's even more worrying is the fact that one of the
stuxnet/tmphider variants used the lnk exploit to install a dll signed
w/ the (expired) Realtek key but w/ a *broken* signature in the first
place. Still, it doesn't matter altough, as wireshark tells me, the
host connects to microsoft.com in order to fetch certificates.
When looking at the file properties, though, Windows tells you
that "this digital signature is not valid" ...  :-(

Cheers,

Stefan.

--
Stefan Kelm   
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstrasse 100 Tel: +49-721-96201-1
D-76133 Karlsruhe Fax: +49-721-96201-99

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Perry E. Metzger]

On Wed, 28 Jul 2010 11:38:17 +0100 Ben Laurie  wrote:
> On 28/07/2010 09:57, Peter Gutmann wrote:
> > In any case though the whole thing is really a moot point given
> > the sucking void that is revocation-handling, the Realtek
> > certificate was revoked on the 16th but one of my spies has
> > informed me that as of yesterday it was still regarded as valid
> > by Windows.  Previous experience with revoked certs has been that
> > they remain valid more or less indefinitely (which would be
> > really great if CAs offered something like domain-tasting for
> > certs, you could get as many free certs as you wanted).
> 
> Again, citing the failure to use revocation correctly right now
> does not tell us anything much about the possibility of using it
> correctly in the future.

The US Securities and Exchange Commission has long forced companies to
state, when selling advisory services, that "past performance is no
indicator of future performance".

However, I think that's pretty much clearly untrue in most
disciplines. Empirical reasoning is entirely about observing and
drawing conclusions based on what we observe. Virtually all of modern
science comes, in fact, from observing what happens in the real world
and extrapolating from it.

After a few decades of trying to get PKI to work, we have failed to do
so. At some point, one has to have very firm justifications for the
belief that these decades of experience should be dismissed as mere
experimental error.

In another message you say:
> The core problem appears to be a lack of will to fix the problems,
> not a lack of feasible technical solutions.

I'm unsure whether you are correct here, but I will point out that any
solution which can never be deployed *is*, in fact, infeasible, and
that if human beings cannot be convinced to use a particular solution
(which is one form of the "lack of will" problem), then we might as
well dismiss that solution.

Now, I've been saying "PKI can never be made to work" for something
like the last fifteen years. I was on a panel with Steve Kent at a
Usenix workshop long ago, where I expressed the opinion that PKI very
poorly models the actual legal and de facto relationships between
parties, and I think that experience has borne that out. We've watched
the rise and fall of substantial companies dedicated to trying to get
PKI sold into enterprises, and the best efforts that Certco and
Entrust and the like made were not enough. There is also considerable
evidence that many of the technologies PKI requires, like reliable
revocation, cannot be made to work, and whether that is because of a
"lack of will" or because of something deeper, the fact is that these
techniques have failed in practice over the course not of months or
years but of decades, and we cannot ignore that forever.

It is not always the case that a dead technology has failed because of
infeasibility or inapplicability. I'd say that a number of fine
technologies have failed for other reasons. However, at some point, it
becomes incumbent upon the proponents of a failed technology to
either demonstrate that it can be made to work in a clear and
convincing way, or to abandon it even if, on some level, they are
certain that it could be made to work if only someone would do it.

I think we are at or even past that point with PKI. The odor of
putrefaction is unmistakable.


-- 
Perry E. Metzgerpe...@piermont.com

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Steven Bellovin]

On Jul 28, 2010, at 8:21 33AM, Ben Laurie wrote:

> On 28/07/2010 13:18, Peter Gutmann wrote:
>> Ben Laurie  writes:
>> 
>>> I find your response strange. You ask how we might fix the problems, then 
>>> you 
>>> respond that since the world doesn't work that way right now, the fixes 
>>> won't 
>>> work. Is this just an exercise in one-upmanship? You know more ways the 
>>> world 
>>> is broken than I do?
>> 
>> It's not just that the world doesn't work that way now, it's quite likely 
>> that 
>> it'll never work that way (for the case of PKI/revocations mentioned in the 
>> message, not the original SNI).  We've been waiting for between 20 and 30 
>> years (depending on what you define as the start date) for PKI to start 
>> working, and your reponse seems to indicate that we should wait even harder. 
>>  
>> If I look at the mechanisms we've got now, I can identify that commercial 
>> PKI 
>> isn't helping, and revocations aren't helping, and work around that.  I'm 
>> after effective practical solutions, not just "a solution exists, QED" 
>> solutions.
> 
> The core problem appears to be a lack of will to fix the problems, not a
> lack of feasible technical solutions.
> 
> I don't know why it should help that we find different solutions for the
> world to ignore?

There seem to be at least three different questions here: bad code (i.e., that 
Windows doesn't check the revocation status properly), the UI issue, and the 
conceptual question of what should replace the current PKI+{CRL,OCSP} model.  
For the last issue, I'd note that using pki instead of PKI (i.e., many 
different per-realm roots, authorization certificates rather than identity 
certificates, etc.) doesn't help: Realtek et al. still have no better way or 
better incentive to revoke their own widely-used keys.

--Steve Bellovin, http://www.cs.columbia.edu/~smb





-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Nicolas Williams]

On Wed, Jul 28, 2010 at 01:21:33PM +0100, Ben Laurie wrote:
> On 28/07/2010 13:18, Peter Gutmann wrote:
> > Ben Laurie  writes:
> > 
> >> I find your response strange. You ask how we might fix the problems, then 
> >> you 
> >> respond that since the world doesn't work that way right now, the fixes 
> >> won't 
> >> work. Is this just an exercise in one-upmanship? You know more ways the 
> >> world 
> >> is broken than I do?
> > 
> >   [...].  I'm 
> > after effective practical solutions, not just "a solution exists, QED" 
> > solutions.
> 
> The core problem appears to be a lack of will to fix the problems, not a
> lack of feasible technical solutions.
> 
> I don't know why it should help that we find different solutions for the
> world to ignore?

Solutions at higher layers might have a better chance of getting
deployed.  No, I'm not suggesting that we replace TLS and HTTPS with
application-layer crypto over HTTP, not entirely anyways.  I am
suggesting that we use what little TLS does give us in ways that don't
require changing TLS much or at all.

Application-layer authentication with tls-server-end-point channel
bindings seems like a feasible candidate.  This too would require
changes on clients and servers, which makes it not-that-likely to get
implemented and deployed, but not changes at the TLS layer (other than
an API by which to extract a TLS connection's server cert).  It could be
deployed incrementally such that users who can use it get better
security.  Then if the market gives a damn about security, it might get
closer to fully deployed in our lifetimes.

The assumption here is that improvements at the TLS and PKI layers occur
with enormous latency.  If this were true at all layers then we could
just give up, or aim to fix not just today's problems, but tomorrow's, a
decade or three from now (ha).  It'd be nice if that assumption were not
true at all.

Nico
-- 

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 13:18, Peter Gutmann wrote:
> Ben Laurie  writes:
> 
>> I find your response strange. You ask how we might fix the problems, then 
>> you 
>> respond that since the world doesn't work that way right now, the fixes 
>> won't 
>> work. Is this just an exercise in one-upmanship? You know more ways the 
>> world 
>> is broken than I do?
> 
> It's not just that the world doesn't work that way now, it's quite likely 
> that 
> it'll never work that way (for the case of PKI/revocations mentioned in the 
> message, not the original SNI).  We've been waiting for between 20 and 30 
> years (depending on what you define as the start date) for PKI to start 
> working, and your reponse seems to indicate that we should wait even harder.  
> If I look at the mechanisms we've got now, I can identify that commercial PKI 
> isn't helping, and revocations aren't helping, and work around that.  I'm 
> after effective practical solutions, not just "a solution exists, QED" 
> solutions.

The core problem appears to be a lack of will to fix the problems, not a
lack of feasible technical solutions.

I don't know why it should help that we find different solutions for the
world to ignore?

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Ben Laurie  writes:

>I find your response strange. You ask how we might fix the problems, then you 
>respond that since the world doesn't work that way right now, the fixes won't 
>work. Is this just an exercise in one-upmanship? You know more ways the world 
>is broken than I do?

It's not just that the world doesn't work that way now, it's quite likely that 
it'll never work that way (for the case of PKI/revocations mentioned in the 
message, not the original SNI).  We've been waiting for between 20 and 30 
years (depending on what you define as the start date) for PKI to start 
working, and your reponse seems to indicate that we should wait even harder.  
If I look at the mechanisms we've got now, I can identify that commercial PKI 
isn't helping, and revocations aren't helping, and work around that.  I'm 
after effective practical solutions, not just "a solution exists, QED" 
solutions.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Jerry Leichter]

On Jul 27, 2010, at 5: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.
There is, of course, the problem of knowing when a signature was stolen!  You 
can know that it was definitely stolen *by* a particular date, but never that 
it wasn't stolen earlier.  Given that it was stolen, what evidence could you 
produce that it wasn't stolen - and simply kept around for later use - at the 
moment it was created?

Beyond that, you it's often hard to know when you received a file.  Perhaps the 
actual attack was to stick it on your system and backdate it!  A forensic 
examination could look at backups, but we're talking about how to decide 
whether to accept a signature in an operational setting.  You can't, of course, 
rely on any dates within the file itself, as they are protected from fakery 
only by the signature that you can't trust.  You could rely on a digital 
time-stamping service ... but that just brings into sharper focus the absurdity 
that actually began the moment you needed to check an on-line CRL.  The only 
conceivable purpose for using a signature is that you can check it *offline*.  
If you assume you can connect to the network, and that you can trust what you 
get from the network - why bother with a signature?  Simply check a 
cryptographic hash of the driver against an on-line database of "known good" 
drivers.

This is right in line with Lynn Wheeler's frequent mention here that the use 
case for offline verification of certs for commerce basically doesn't exist.  
It was a nice theory to develop 30 years ago, but today the rest of the 
framework assumes connectivity, and you buy nothing but additional problems by 
focusing on making just one piece work off-line.

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 09:57, Peter Gutmann wrote:
> Ben Laurie  writes:
>> 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.
> 
> This wouldn't make any difference, except for the special case of x64, 
> signatures are only verified on install, so existing installed code isn't 
> affected and anything new that's being installed is, with either form of 
> sig-checking.

Obviously if you are going to change revocation you can also change when
signatures are checked. This hardly seems like a show-stopper.

> In any case though the whole thing is really a moot point given the sucking 
> void that is revocation-handling, the Realtek certificate was revoked on the 
> 16th but one of my spies has informed me that as of yesterday it was still 
> regarded as valid by Windows.  Previous experience with revoked certs has 
> been 
> that they remain valid more or less indefinitely (which would be really great 
> if CAs offered something like domain-tasting for certs, you could get as many 
> free certs as you wanted).

Again, citing the failure to use revocation correctly right now does not
tell us anything much about the possibility of using it correctly in the
future.

> The way to revoke a cert for signed malware is to wait 0-12 hours for the 
> malware signature to be added to AV databases, not to actually expect PKI to 
> work.

At which time they release another version? Doesn't sound like the
optimal answer to me.

I find your response strange. You ask how we might fix the problems,
then you respond that since the world doesn't work that way right now,
the fixes won't work. Is this just an exercise in one-upmanship? You
know more ways the world is broken than I do?

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

On 28/07/2010 00:14, Paul Tiemann wrote:
> 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 
> signature?

Note that I avoided this issue by using the date of receipt.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Peter Gutmann]

Ben Laurie  writes:
>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.

This wouldn't make any difference, except for the special case of x64, 
signatures are only verified on install, so existing installed code isn't 
affected and anything new that's being installed is, with either form of 
sig-checking.

In any case though the whole thing is really a moot point given the sucking 
void that is revocation-handling, the Realtek certificate was revoked on the 
16th but one of my spies has informed me that as of yesterday it was still 
regarded as valid by Windows.  Previous experience with revoked certs has been 
that they remain valid more or less indefinitely (which would be really great 
if CAs offered something like domain-tasting for certs, you could get as many 
free certs as you wanted).

The way to revoke a cert for signed malware is to wait 0-12 hours for the 
malware signature to be added to AV databases, not to actually expect PKI to 
work.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[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 
signature?

Paul Tiemann
(DigiCert)
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Re: A mighty fortress is our PKI, Part II

[Ben Laurie]

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.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com