[Cryptography] WireGuard

John Denker jsd at av8n.com
Sun Sep 9 03:57:07 EDT 2018


On 09/08/2018 10:49 PM, jamesd at echeque.com wrote:

> IPSec relies on public keys, but identifies computers by their IP address.
> 
> Thus anything using IPSec has to provide a bunch of additional moving parts which are not exactly part of the standard.
> 
> IPSec is incomplete without a Zooko to network address translation standard, or a human readable name to Zooko plus network address standard.
> 
> And thus gets completed by everyone gluing their own matchsticks together in their own way

Agreed.  That's all true and important.

Taking another step down the same road, I would add that

 1) IPsec /requires/ a Security Policy Database (SPDB).
 2) RFCs don't say much about how to implement it.
  (Typically it gets implemented as some sort of firewall
  policy.)

This results in yet more matchstickery.

The SPDB very greatly affects security.  That's because
security requires both:
 a) making sure certain good things are possible, and
 b) making sure certain bad things are not possible.

The SPDB is necessary for (b).  Interoperation testing often
deals mainly with (a).

Unfortunately, I've seen implementations that gave the SPDB
very short shrift.  As soon as they achieved interoperation
they declared victory and forgot about the SPDB.

==================

Tangentially related:  About three weeks ago The Intercept
dumped a batch of Snowden documents that talk about breaching
VPNs (including TLS and IPsec).
  https://theintercept.com/2018/08/15/nsa-vpn-hack-al-jazeera-sidtoday/

>> “For both TLS and IPsec, there are both secure and insecure ways of
>> configuring these protocols, so they can’t really be labeled as
>> blanket ‘secure’ or ‘insecure,’” Heninger explained. “Both protocols
>> offer a zillion configurable options, which is a source of a lot of
>> the published protocol-level vulnerabilities, and there are cipher
>> suites and parameter choices for both protocols that are definitely
>> known to be cryptographically vulnerable.” Still, she was “pretty
>> confident” that there are ways to configure TLS and IPsec that
>> “should resist all known attacks.”

There is not much there in the way of details on what was broken,
how it was broken, or how to make things secure ... but it's
a reminder that a very high degree of professionalism and
fastidiousness is required;  otherwise we're delivering snake
oil or worse.


More information about the cryptography mailing list