[liberationtech] [cryptography] [ipv6hackers] opportunistic encryption in IPv6

[Nico Williams]

[BTW, thanks Eugen for forwarding these posts!]

> Date: Wed, 12 Jun 2013 09:34:11 -0700
> From: Tim <tim-security at sentinelchicken.org>
> To: IPv6 Hackers Mailing List <ipv6hackers at lists.si6networks.com>
> Subject: Re: [ipv6hackers] opportunistic encryption in IPv6

> [...]
>
> SOOOO many different attempts at creating encryption protocols have
> utterly failed, and in most cases, it is because the designers have
> put the cart before the horse.  They've started with the easy
> encryption problem rather than addressing the hard authentication
> problem.

Many protocols separate key exchange and authentication.  E.g., SSHv2
and TLS (when using DH for key exchange).  Combining the two (e.g., by
using RSA key transport) can be a nice optimization (though you might
lose PFS), but IMO it's best to think of the two things as distinct
and attempt only for round-trip optimization (i.e., don't incur an
extra round-trip as a result of treating key exchange and
authentication as separate).

> Indeed, you may be able to convince the world at some point to adopt
> opportunisitic encryption without authentication, since so many people
> don't understand that it doesn't buy you anything.  But then they'll
> be shocked when the first guy writes and releases a MitM tool for it.

TOFU has a decent track record.  It doesn't scale, and you do need
users to know how to handle key rollover, but otherwise it's pretty
good.

> [...]
> As an aside: the idea embodied in CGAs is a powerful one:  By making
> my address my key (signature), I'm implicitly binding my key to my
> protocol. However, CGAs address this problem at network layer, not at
> the human layer.  So all it takes to bypass it is to MitM the protocol
> that hands out addresses for hosts.  However, as a building block, it
> could be useful.  Also, for those who aren't familiar with it, I
> strongly urge you to read up on Identity Based Encryption, where any
> string can be a public key, within a predefined authentication realm.

I see CGA as an attempt to deal with a serious API-ish shortcoming of
IPsec: there's no APIs (socket options, whatever) by which to a)
influence policy to apply, b) specify who you want the peer to be, c)
find out who the peer is, d) find out what policy (e.g., transforms)
got applied, e) guarantee peer key/ID continuity for the lifetime of a
packet flow (connection).

(a) through (e) are standard features of security protocols layered
above TCP/UDP/SCTP: TLS, DTLS, SSH, ...

But IPsec lacks them utterly.  This makes IPsec useless for end-to-end
(as opposed to VPN) use except in very small deployments where static
addressing makes it possible to make up for the lack of those features
via policy (i.e., without the application having any visibility).

There is one Internet standards-track application protocol that
depends on IPsec: iSCSI.  So that sucks, but fortunately iSCSI doesn't
need to scale to Internet scale -- just data center scale.

The only way to get IPsec APIs would be to go implement one for enough
OSes.  And then you'd need to get deployment, which would mean getting
apps to use these APIs.  That's a lost cause.

Opportunistic encryption is inherently a difficult thing to pull off
because "opportunistic" is roughly "transparently", which I take to
mean "no UI".  But authentication without any form of UI (e.g.,
because it takes place at a layer that lacks information like the URI
of a resource a user wants loaded, or that lacks the ability to
interact with the user) is a contradiction in terms.  Opportunistic
encryption, then is inherently susceptible to MITM attacks, and the
only way I see to fix that is to provide the necessary interfaces
across layers so that at least TOFU can be implemented.

Nico
--