[Cryptography] IPsec DH parameters, other flaws

[Paul Wouters]

On Thu, 2 Jul 2020, William Allen Simpson wrote:

> Subject: [Cryptography] IPsec DH parameters, other flaws
> 
> [reading some older list items, branching off]
>
> On 6/3/20 2:29 AM, Peter Gutmann wrote:
>>  [1] I've never understood why IPsec and the cargo-cult protocols that
>>  reused
>>       the parameters from it fixed on a single set of DH parameters.  IPsec
>>       is
>>       possibly one of the most unnecessarily flexible protocols in the
>>       world
>>       where absolutely everything is up for negotiation, but there's one
>>       single
>>       set of parameters that every single user has to share to create a
>>       single
>>       point of failure for attackers to exploit.
>
> The original IPsec (Karn, Metzger, and Simpson) did not!
>
> Photuris was designed around negotiating variable DH parameters
> and avoiding easy denial of service attacks.  From the beginning!

I thought this was done to prevent malicious or weak DH parameters. And that the
server was not expected to be able to determine the security of received
variable DH parameters in real time? And I thought TLS did this too?

> All of that went by the wayside after NSA (and BBN) got involved.

That was way before my time ..... But I got the impression that at least
half of this was self-inflicted by the other IETF participants. And the
infosec community is still doing  this do itself all the time.

> Also, among other things, requiring the IV sent in the clear was
> another Steve Kent innovation.  Even though he'd been on a paper
> years earlier that the IV should be secret.

If that is so bad, why did WireGuard use this design too then?
Or is there is a mixup here of terms here (ICV, IV, Nonce, AEAD
components, grrr)

And if it makes you feel better, once I investigated the history and
lack of justification of RFC 5114, which Steve Kent admitted to having
just forwarded from NSA/BNN to IETF without explanation, I pushed to
kill the whole thing. It's now dead.

> And there was the Null encryption option.

Even in my time, early wireless days, this was used a lot. Some
people didn't have the hardware to encrypt. And they had to sort
of trust the microwave was directional enough to be safe against
amateut eavesdropping. Also because AH was more often firewalled than
ESP. But I know of zero instances where someone accidentally negotiated
esp=null. Every implementation would require hardcoding that. Unless you
are referring to ESP without AH, which was kicked out a long time ago and
ESP changed to have AH builtin. It's just that raccoon/setkey refused to
die for so long ang ESP+AH was still needed. But while freeswan supported
it, openswan already dropped support in like 2003 or so.

> And the ability to negotiate a downgrade.

Downgrade what?  IKEv1 was foolish to allow paylaods that were not
verified by crypto, such as the Vendor IDs. That meant we could not
build in an easy IKEv2 to IKEv1 downgrade protection. But then again,
only openswan/libreswan ever implemented connections that could be
either. Eeveryone else just froze their IKEv1 stack and made you
configure which protocol version to use. So also no downgrade
possibility.

IKE/IPsec is missing the force of only having three important vendors
like browsers have. So we can't obsolete things as fast as we would
like. I still get complaints libreswan refuses DH group 2 (and DH group
5 in IKEv2).

> And the serious problems we published via Usenix, because IETF wouldn't....

I'd love to read those. If you have googlable strings or URLs for me, please let
me know.

> We knew so many things to be wrong.  The best explanation is that
> flaws in the resulting IPsec were deliberate.

Yet still, all the TLS protocol attaks like logjam, beast lucky13,
poodle, crime, none of them worked against IKE/IPsec. From a protcol
level, IKE and ESP have never been broken. The only thing that was "too
weak and shouldn't be used" was PSK with Aggressive Mode. And even there,
when using real PSKs you are safe. It is just that humans never muster
up the responsibility to do that. We are waiting on CFRG now to decide
on the PAKE's and hope to be able to phase out most PSK for PAKE. The
only other NSA attacks I know against IKE/IPsec were all based on
vulnerable firmware compromise, and then stealing credentials and
sessions keys.

> Thankfully, after a quarter century, TLS 1.3 has almost all the
> features we originally presented in 1995.

I feel very much that things went:

SSL -> IKEv1 -> TLS 1.[012] -> IKEv2 -> TLS 1.3

I guess with QUIC and HTTP/3 it is kinda merging even more.

And now IKEv2 is up for a round of cleanup dumping old stuff, which
I've actively done with RFC 8247, 8221 and the current ikev1-graveyard
draft.

IKEv2 has its horrors too, don't get me wrong. Whoever in the IPsec
WG thought that EAP-TLS over IKE using 8 RTT was a good idea was crazy.
The whole Traffic Selector narrowing idea is super smart but in practise
just not really used much beyond their trivial cases and adds a lot of
complexity.

As I said, I have never seen an actual protocol attack against IKE or
ESP. I'd love to see one.

Anyway, just the opinions of an cargo cult member :)

Paul