Peter Gutmann wrote: > > Hadmut Danisch <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]