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]
