[Cryptography] Cryptographic protocol composition (Re: BLAKE2: "Harder, Better, Faster, Stronger" Than) MD5

[Nico Williams]

...is not trivial.

On Tue, Mar 25, 2014 at 03:59:07PM -0700, Jon Callas wrote:
> > Which is to say;  if you are going to do super-encryption, the best
> > thing is to separate the layers as much as possible.
> 
> Bingo. Take a halfway-decent content/message system and run it over
> TLS. Run your TLS over IPsec. Or better yet, run that through Tor
> (which is solving a different problem and that's why you use it).

Careful: IPsec might not mean what you think it does.  It's easy to
think that it must mean a lot more than it does.

In brief: IPsec authenticates source and destination addresses of
packets, but since IP address<->node assignments have a lot of churn,
the policies concerning how to authenticate an IP address are... overly
broad.  In particular the common approach is to say that any node with
a certificate from CA such-and-such gets to claim any IP address from
such and such CIDR blocks.  Which means a) this doesn't scale to the
Internet, b) authorized mobile users can bump others off their assigned
addresses and take over their TCP connections.

Briefer: IPsec is utterly useless at authenticating the entities that we care
about at higher layers.

At least for large/active enough networks.

The "bump 'em off and take over" attack can be prevented locally...[with
a method not yet implemented anywhere, so, not even that.

At scale, end-to-end IPsec as it exists (i.e., as implemented) today is
barely better than nothing[*].  Actually, not even, because as
implemented one generally can't even express a policy that keys should
be exchanged and used even with peers that cannot be authenticated,
therefore at scale end-to-end IPsec cannot be used at all, never mind to
good effect.  Trying to use IPsec this way might only increase latency.

Even with the relevant fixes (BTNS and connection latching) implemented
and deployed IPsec is difficult to use opportunistically (NOTE: not in
the sense of DNSSEC-based discovery) because of the need to attempt -and
timeout!- an IKE SA exchange.  Opportunistic out-of-band key exchange
tivially falls to DoS attacks.

Layering/combining multiple cryptographic protocols is not that much
easier than layering cryptographic algorithms within one protocol.  The
first problem you run into after you get past impedance mismatches is
inappropriate APIs.

And then there's the question of who pays.  All that extra layering/
crypto has non-trivial costs, especially for large services (think of
Google).  With the end of Moore's law we'll probably see more of the
likes of AES-NI: special-purpose on-die HW, but resources are still
finite.

OTOH, if you don't have to scale to Internet scale, sure, IPsec with
very static policies + TLS above that will at least function.  But
you'll probably be using roughly the same PKIs for both, so you'll get
no extra protection, and you'll be wasting resources in the process.

There is value in composing cryptographic protocols, but mostly only so
as to reduce workload rather than increasing security.  Though anything
that improves performance/reduces costs of cryptographic protocols has
the salutary effect of increasing their deployment.

Nico

[*] Pun intended.  Now we just need an IETF working group named PUN.