invoicing with PKI

[Ian Grigg]

Peter Gutmann wrote:
> 
> Hadmut Danisch <hadmut at danisch.de> writes:
> 
> >There was an interesting speech held on the Usenix conference by Eric
> >Rescorla (http://www.rtfm.com/TooSecure-usenix.pdf, unfortunately I did not
> >have the time to visit the conference) about cryptographic (real world)
> >protocols and why they failed to improve security.
> 
> It was definitely a "must hear" talk.  If you haven't at least read the slides
> (were the invited talks recorded this year?  Any MPEGs available?), do so now.
> I'll wait here.

I read them twice the other say.  Recordings
would be nice.

> [Pause]
> 
> The main point he made was that designers are resorting to "fixing" mostly
> irrelevant theoretical problems in protocols because they've run out of other
> things to do, while ignoring addressing how to make the stuff they're building
> usable, or do what customers want.  My favourite example of this (coming from
> the PKI world, not in the talk) is an RFC on adding animations and theme music
> to certificates, because that's obviously what's holding PKI deployment back.

:-) Was this an April 1st RFC?  Or a stealth DRM
effort?

> >From the logfiles I've visited I'd estimate that more than 97% of SMTP relays
> >do not use TLS at all, not even the oportunistic mode without PKI.
> 
> I did a talk last year at Usenix Security where I said that all SSL really
> needed was anon-DH, because in most deployments that's how certificates are
> being used (self-signed, expired, snake-oil CAs, even Verisign's handed-out-
> like-confetti certs).

It's worth looking at these figures from 1st Sep 2003:

      Description              Count

      Valid                    35709
      Self Signed              9769
      Unknown Signer           27507
      Cert-Host Mismatch       40276
      Expired                  54578

http://www.securityspace.com/s_survey/sdata/200308/certca.html

I used the total in my calculation to get 1.24% server
penetration, but the true story is way worse - only a
quarter are supposed PKI-valid.  The rest are deviant
in some form.

> It's no less secure than what's being done now, and
> since you can make it completely invisible to the user at least it'll get
> used.  If all new MTA releases automatically generated a self-signed cert and
> enabled STARTTLS, we'd see opportunistic email encryption adopted at a rate
> that tracks MTA software upgrades.

I've thought about this a lot, and I've come to the
conclusion that trying to bootstrap using ADH is not
worth the effort.  I think the best thing is if the
web servers were to automatically generate self-signed
certs on install, and present them by default.

Then, at least, we offer the opportunity for browsers
to do SSH-style time-trust analysis.

The forces of crypto-conservatism are so strong that
I suspect we only get one shot at saving the HTTPS
protocol.  Trying to get browsers and servers to agree
to like ADH seems too much a challenge.  Using self-
signed certs seems to promise more bang for buck.

For new applications, using ADH is definately a good
way to go.

iang

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