GSM eavesdropping

[Nicolas Williams]

On Mon, Aug 02, 2010 at 01:05:53PM -0400, Paul Wouters wrote:
> On Mon, 2 Aug 2010, Perry E. Metzger wrote:
> 
> >For example, in the internet space, we have http, smtp, imap and other
> >protocols in both plain and ssl flavors. (IPSec was originally
> >intended to mitigate this by providing a common security layer for
> >everything, but it failed, for many reasons. Nico mentioned one that
> >isn't sufficiently appreciated, which was the lack of APIs to permit
> >binding of IPSec connections to users.)
> 
> If that was a major issue, then SSL would have been much more successful
> then it has been.

How should we measure success?  Every user on the Internet uses TLS
(SSL) on a daily basis.  None uses IPsec for anything other than VPN
(the three people who use IPsec for end-to-end protection on the
Internet are too few to count).

By that measure TLS has been so much more successful than IPsec as to
prove the point.

Of course, TLS hasn't been successful in the sense that we care about
most.  TLS has had no impact on how users authenticate (we still send
usernames and passwords) to servers, and the way TLS authenticates
servers to users turns out to be very weak (because of the plethora of
CAs, and because transitive trust isn't all that strong).

> I have good hopes that soon we'll see use of our new biggest
> cryptographically signed distributed database. And part of the
> signalling can come in via the AD bit in DNSSEC (eg by adding an EDNS
> option to ask for special additional records signifying "SHOULD do
> crypto with this pubkey")
> 
> The AD bit might be a crude signal, but it's fairly easy to implement
> at the application level. Requesting specific additional records will
> remove the need for another latency driven DNS lookup to get more
> crypto information.
> 
> And obsolete the broken CA model while gaining improved support for
> SSL certs by removing all those enduser warnings.

DNSSEC will help immensely, no doubt, and mostly by giving us a single
root CA.

But note that the one bit you're talking about is necessarily a part of
a resolver API, thus proving my point :)

The only way we can avoid having such an API requirement is by ensuring
that all zones are signed and all resolvers always validate RRs.  An API
is required in part because we won't get there from day one (that day
was decades ago).

The same logic applies to IPsec.  Suppose we'd deployed IPsec and DNSSEC
back in 1983... then we might have many, many apps that rely on those
protocols unknowingly, and that might be just fine...

...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.

Nico
-- 

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