GSM eavesdropping

Perry E. Metzger perry at
Mon Aug 2 18:37:16 EDT 2010

On Mon, 2 Aug 2010 16:19:38 -0400 (EDT) Paul Wouters
<paul at> wrote:
> [Speaking here about DNSSEC...]
> Yes, but in some the API is pretty much done. If you trust your
> (local) resolver, the one bit is the only thing you need to check.
> You let the resolver do most of the bootstrap crypto. One you have
> that, your app can rip out most of the X.509 nonsense and use the
> public key obtained from DNS for its further crypto needs.

I would like to note that this is not sufficient for the sort of
security I've been talking about.

If, for example, users are still authenticating to web sites by typing
in passwords over an encrypted channel, DNSSEC based keys don't
help. The user still has to actively make sure that they're not giving
their key away to the wrong web site.

You still need to re-engineer the system so that the user cannot
give away their credentials without serious effort. Simply changing
where the opaque third party certified key comes from doesn't help.

What DNSSEC really gives you is the ability to trust the replies the
DNS gives you -- to trust that a DNS label and IP address really are
bound together. It doesn't change the fact that the current user
authentication models are broken.

> > ...but we grow technologies organically, therefore we'll never
> > have a situation where the necessary infrastructure gets deployed
> > in a secure mode from the get-go.  This necessarily means that
> > applications need APIs by which to cause and/or determine whether
> > secure modes are in effect.
> But by now, upgrades happen more automatic and more quickly. Adding
> something new to DNS won't take 10 years to get deployed. We've
> come a long way. It's time to reap the benefits from our new
> infrastructure.

I disagree that we can deploy new systems quickly. See, for example,
the large fraction of IE6 users in the world. Indeed, I suspect it
will be another 10 years before over 95% of machines are even paying
attention to DNSSEC.

Perry E. Metzger		perry at

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list