Re: [arch-d] deprecating Postel's principle- considered harmful

[Paul Wouters <[e-mail]>]

On Tue, 7 May 2019, Rich Kulawiec wrote:

> But now?  In the decades since, we've learned that every tiny opening
> can be and will be exploited by someone, often in surprising ways.
> The pendulum has swung a long way from "be liberal in what you accept"
> because it's now dangerous.  When I think about Jon, and of what he
> envisioned, I'm saddened by this.

Having done IKE/IPsec since the late 90s - so 30 years - I can tell you
that applying the "no Postel principle" strictly would only work under
special conditions.

The problem is not the Postel principle. The problem is that we have "too
big to fail" implementations and a lack of implementation diversity. The
Postel principle works fine if there is diversity. As soon as someone
can just do whatever they want, the principle breaks. But that does not
mean the answer is to blindly promote the opposite. That will just end
up with errata's or bis documents to follow the incumbents mistakes.

As an example, Microsoft IKEv2 completely breaks DH/PFS on rekeying. If
I apply the unforgiven stance, either my implementation dies because "it
does not work", or all Windows desktop VPN's die, or both. Additionally,
any Microsoft setup with an intermediate CA would get their CERT
payloads rejected for being in the wrong PKCS#7 format. Again, I am not
an incumbent so I have no choice but to apply the Postel principle for
my own survival.

Another example, if my implementation were strict on IPsec ESP with
SHA2_256 truncation, 1 billion Android devices would not have IPsec VPNs.

An RFC telling me not to do this, is going to get ignored by me.

If anything, Postel's principle was too binary. Sometimes it makes sense
to use, and sometimes it does not. But how to apply that is tricky too.
Should I allow Microsoft to do IKEv2 rekeying with DH using modp1024? It
severely degrades security. Am I in a position to do so? Not really. Can
I document this and tell people to enable a workaround and hope to shame
a vendor into compliance? Yes I can[*]. Without having to break everyone.
Can I put in an Android workaround option and tell the Android developers
everytime I see them they still do it wrong. Yes I can, and after 3
years of harassment they finally fixed it and added their own "legacy"
option to get their old behaviour back.

Now, picking up on the origin of the ESP SHA2_256 truncation bug, this
was caused by the linux kernel implementing a draft instead of the final
RFC. I pointed this out to the Linux maintainer in 2008 or so, long
before Android. Their fix was to keep the original broken behaviour and
add a new API for the new correct behaviour. But people kept using old
software that did not use the new API, including the giant Google. This
is clearly a broken strategy. I'd say you MUST fix your code to be RFC
compliant, and clearly mark such fixes in your changelog/release notes.
Yes, it might still break people, but you might prevent 1 billion future
people from being broken, and anyone who does an upgrade and sees a fail,
can do a downgrade and read up on why and what happened. That is, don't
keep on doing it wrong, because then the workarounds never die. You did
it wrong, then you take the extra work to do it right (and wrong) and
maybe in 10-15 years you can delete the workarounds for your own
mistakes.

It is hard for an old code base to still understand various bits of code
and workaround. This is where comments really help. To give another
example, a recent bug showed my implementation ignored VPN delete
requests within the first few seconds of an established VPN session. I
tracked down the problem and found a comment in the code, that allowed
me to make an informed  decision to remove it:

https://github.com/libreswan/libreswan/commit/82adf12106f4d3b44f80819f6e2858d5cd7dfb97

For people saying "that was 20 years ago, this is a different internet
age", I don't believe that. The incumbents might have changed, but the
scenario of the underdog has not changed.

Now, when we do something fairly new and experimental, and we are
doing our first interops, please reject everything that violates the
draft. Get the first implementations to be rigid and robust. The more
strict those first players are, the better we get compliance out of
the different vendors. But if you find something a year later, and you
can do a workaround based on the Postel principle, be a good citizen
and report the bug and implement the workaround clearly. And remove it
again in a number of years. (bonus: people get rewarded for upgrading
their systems!)

In principle, live according to the Postel principle.

Paul
[*] I'm still in the "hoping" phase on this one :(