[Cryptography] IPsec DH parameters, other flaws

William Allen Simpson william.allen.simpson at gmail.com
Sat Jul 11 12:19:21 EDT 2020


On 7/6/20 9:58 PM, Paul Wouters wrote:
> On Thu, 2 Jul 2020, William Allen Simpson wrote:
>> 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?
> 

You've got it backward.  The server proposed several DH parameters.  The
client chose among them, but didn't really have time to verify them.
The server then verified the client choice was valid.

We also provided code (eventually integrated into NetBSD among others) to
generate lists of verified DH parameters.  I also documented a file format
(etc/moduli) to store them, that we later re-used for OpenSSH.

The key here is everybody could independently verify that the list of DH
moduli were safe primes.  And nothing would be dependent upon any fixed DH
prime moduli.  And they could be changed on a regular basis, so that
efforts to break them would be futile.  It was intended that every OS
release or security update have a fresh list.


>> 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)
> 
It's very bad.  In the early '90s, we were merely speculating that a secret IV
could prevent a DES hardware cracker of the era from determining the encryption
secret.  Gilmore later proved it.

Note I'm the originator of one of the first AEAD designs, CBCS, in April 1994.
(We didn't yet have the AEAD terminology at the time.)  It XOR'd a secret into
every block, not just the first, using a checksum technique pioneered in the '70s
SCOPE/Hustler CDC operating system.  No patents.

CBCS is faster than MD5 (and much faster than triple-DES), with a side effect of
theoretically strengthening the encryption at least as much as DESX.  Detects
altering, extending, truncating, or swapping the cipher data blocks; and the
trailing checksum was used to verify the integrity before doing the more
computationally expensive decryption.

Also co-author of the July 1997 DES-XEX3 internet draft, too.  But IETF
wouldn't publish that, either.  Nothing more secure than plain old DES with an IV
transmitted in the clear.


>> 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. 

[Heavy sigh] Karn worked for Bell Labs and then Qualcomm.  The IP stack in
Qualcomm (and Sony and others') phones was based upon his KA9Q NOS.  I'd
consulted on it and shrunk the IP stack enough to fit in the tiny memory.

Photuris and IPsec were designed to be lightweight enough to run on the 186
core in those phones.  I repeat: a 186, not a 286, not a 386.  Karn wrote an
assembly version of both MD5 and DES.


> And they had to sort
> of trust the microwave was directional enough to be safe against
> amateut eavesdropping. 

Karn and I were well aware of the evesdropping issue.  CHAP was originally
proposed circa 1989-1990 as an authentication solution for AMPRnet radios.

Everything else you mention are later developments.  There should never have
been a Null encryption option!


>> 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.

Not a problem for Photuris.  Absolutely everything, every field, and every
field length, verified by crypto.

The designers of IKE/ISAKMP were either incompetent, or it was deliberate.


>> 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.
> 

"ike isakmp considered harmful"

At the time, I owned an ISP.  I could bring a cisco I owned to its knees in seconds.


>> 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. 

[Another heavy sigh]  As I've recounted before on this list, back when Netscape was
located near the Stanford campus (I walked there from the computing center), Paul
Mockapetris got me to visit.  I sat down with Taher Elgamal and others, to critique
their early SSL.

	Eventually, it became obvious that they weren't really open
	to changes/suggestions.  To the best of my memory, we
	thought it would be better to:

	 1) Authenticate the list of supported methods/transforms.
	We did that in Photuris to avoid modification attacks
	choosing the lowest common denominator.

	 2) Encrypt the certificates/users.  We called that "party
	privacy protection".  We used the initial D-H exchange to
	create a temporary stream key, and "masked" the data with
	the stream (simply an MD5 hash).

	 3) Require Perfect Forward Secrecy.  We'd not managed to
	get IPsec to do that.  It was a big argument at the time.

	 4) Authenticate outside of encryption, so we could quickly
	and cheaply check before doing a more computationally
	intensive decryption.  We managed to force that into IPsec,
	and hoped to get Netscape to do the same for SSL (now TLS).
	IIRC, that's since been proven to be more secure, but we
	didn't know it at the time.  We were mostly interested in
	practicality.

Obviously, it has taken decades, and we still cannot get everybody to stop
running SSL or TLS 1.0.


> 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. 

That's what some of us call broken.

Also, see "ike isakmp considered harmful" mentioned above.


>> 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
> 
Photuris and SSL were both ~1994, before ISAKMP -> Oakley -> IKEv1.

Never forget, ISAKMP was originally defined in ASN.1 ("asinine one").
That was going to become the meta higher layer above ATM (asynchronous
transfer mode).  There's a couple of ideas whose time never came....

A lot of the truly terrible ideas, such as aggressive mode, came from Oakley.


> 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.
> 
Admittedly, I've stopped looking at IKEv(whatever) many years ago.  Glad
somebody has the stomach, and things are getting better.


More information about the cryptography mailing list