[Cryptography] IPsec DH parameters, other flaws

[William Allen Simpson]

On 7/20/20 8:09 PM, Dan McDonald wrote:
> I was there in the mid-90s, and we IPng-ers detested NAT, and thought it was
> our mission in life to kill it dead. NATs were middleboxes that altered
> packets and were an extra single-point-of-failure!  Also, we though NATs were
> going to be easy targets for... wait for it... attackers, including-and-
> especially state-sponsored ones!
> 

But some of us were very much in favor of firewalls.  The issue with NAT
was altering packets.  Also, distributing security secrets to the NAT.

Yes, I for one thought that SIPP (v6) would be rapidly deployed, as we had
strong consensus and running code.  Who knew that the vendors would take
over the IESG, and insist that IPv6 be done over again?


> Was it a misguided decision to not think about NAT-Traversal until the
> early-2000s?

Some of us were thinking about it.  I remember presenting our Authenticated
Firewall Traversal paper(s) circa 1995-96.  At least the ICMP message
actually made it to RFC 2521, publication delayed until 1999.

In my view, that was really the only valid reason for AH, used in an outer
wrapper (using the protocol 4 IP in IP).  The firewall didn't get to see
the confidential traffic.  We had running code.

But various folks hated the idea that the firewall needed a separate secret.
There was a big push to have secret sharing that allowed the firewall to
read the traffic as it went through, because pornography terrorists....


> Hell, I'd imagined (and I wasn't alone) IPsec being presented to apps as a
> socket option that you had to turn on *per-socket* to use.  1st year at Sun
> convinced me that wasn't great, because of Legacy Software (TM).

You were not alone.  I'd posted one of the socket interface drafts.

As if they couldn't have upgraded that legacy software over a period of a
few years.  There wasn't much legacy yet in 1995!

Never-the-less, the existing packet filter designs could have turned on
IPsec per socket, as they already filtered per socket.  Fairly sure
SELinux can do something like that.

But the legacy vendors were a problem.  Also their reasoning for tacking
the next header onto the end of the ESP packet.  Terrible idea, caused
already perfectly aligned packets to need extra block cipher padding,
and even fragmentation.

Our original design had things like the port and the protocol chain
negotiated by the session key management per SPI.

For goodness sake, what security is there in allowing the OS or outside
actor to modify things like the port, redirecting to another process???

At one point, I'd added a disclaimer about mutually hostile users.
Prescient, now we see Specter et alia.


> So much
> stupid and greed can do more to kill something than one imagines.  In the
> late 90s, someone asked me if we could use IPsec to protect Oracle database
> traffic w/o paying Oracle some godawful *additional* sum for what was
> essentially turn-on-SSL.

Ha, non-amusing story.  When I was at Red Hat, I discovered that their
internal accounting systems only supported very old SSL.  They didn't want
to pay Oracle for the upgrade.  When the browsers stopped supporting it,
they bought F5 appliances to intercept the traffic, downgrade, re-encipher.
Instead of deploying their own RHEL....


>  [...] but hey, it's likely more about greed [...]
> 
> I agree with you, Paul -- we have ourselves as much to blame as any external
> actor.
> 

Or at least their corporate overlords.