[Cryptography] Two quick questions about IPsec AH

[Phillip Hallam-Baker]

On Fri, Jan 7, 2022 at 1:03 AM Christian Huitema <huitema at huitema.net>
wrote:

> On 1/6/2022 6:31 PM, Peter Gutmann wrote:
>
> Phillip Hallam-Baker <phill at hallambaker.com> <phill at hallambaker.com> writes:
>
>
> I remember sitting in an IPSEC meeting at the Dallas IETF and hearing the AD
> call this 'a feature'.
>
> Yup, I remember that too (not at the Dallas IETF but elsewhere).  The thinking
> was "IPsec will be bigger than NAT so if we make sure it breaks NAT, NAT will
> go away".
>
> This anti-NAT crusade within the IETF persisted for a long, long time.  Look
> at RFC 3424 for example, which invented a childish backronym "UNSAF" to refer
> to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF
> servers throughout.  Section 4 is particular amusing, describing the various
> levels of self-flagellation that any UNSAF mechanism is required by the IAB to
> subject itself to.
>
> ... which is why I had to write something like 19 iterations of the Teredo
> draft in order to jump through the UNSAF loops. Standardizing STUN also
> took a long time. Yes, that was silly. But the argument that I heard then
> was not that "IPsec will be bigger than NAT". Yes, there was the anti-NAT
> argument that IPv6 will make all that complexity go away, but there was
> also the pro-NAT argument about NAT providing a firewall service to users,
> so don't you dare break through that firewall, even if it is required for
> video conferences or video games.
>
One of the big problems in IETF is that the IAB was originally intended to
be the DARPA program managers paying for the work. As the IETF expanded,
they devised a politburo system to maintain control which turned into the
NOMCON scheme. All the rough consensus and running code guff really boils
down to a bunch of unelected, unaccountable people taking random decisions
with little recourse.

The anti-NAT jihad continued because the NOMCON by design selects people
who 'will work well together'. They (usually) make sure nobody will rock
the boat. I burned a lot of political capital by pointing out that NAT was
going to be widely deployed and used regardless of IAB distaste and more
importantly, there was no way to deploy any IPvNext without an address
translation layer.


I agree that NAT does have some value as a poor-man's firewall. But it is
not a very good firewall and nor are the devices sold as firewalls. And
again IETF ideology has hurt, not helped. IETF had a jihad against
firewalls before NAT was a thing.

What IETF should have done is to identify the network-internet boundary as
a control point that the network owner is responsible for policing. They
should have pushed for NAT and a good firewall.


So going back to cryptography, how am I going to fix things in the Mesh?

Well first off, my short term plan is to package the Mesh as a podcast
course on information security showing that the current state of affairs is
not inevitable. There are other design choices that could have been taken.

Secondly, I believe in permissionless innovation, I post to the IETF list
to let them know what I am doing. I am not asking for permission, no
accountability means no authority in my book. Being told that the system
cannot possibly work is of course an essential part in the foundation myth
of every new invention. The New York Times and Washington Post etc. love
the idea of a lone inventor contra mundum. Which is exactly what I am
giving them.


At the technical level, we have to make security policy work. The Mesh is
designed to provide a path to default deny security in which every device
connects to the network with minimum privileges and those privileges are
enforced in the network itself.

This is going to require every bit of the network stack to be touched
eventually. I am starting at the application layer and working down. Part
of the Mesh is the Device Catalog. Provisioning a device to a user's
personal Mesh is simple, it can be achieved through a simple QR code
interaction. So take the device out of the box, scan a QR code, turn it on
and the device is now connected to your personal Mesh.

[And why yes, I do have running code for all of this except for the bit
about acquiring the network parameters]

So if I win, after a short while, IoT devices will start appearing with a
'Mesh Ready' sticker on them to tell the customer that all they need to do
is scan the device with an app and it just works as part of their personal
Mesh without any further configuration. And the only reason I might not win
is that someone else has beaten me to it with a scheme that has the same
properties.

So at this point Alice buys a network hub that has the Mesh ready sticker
on it as well. And this enforces a security policy that is derived from the
device profile established when the device was connected to the personal
Mesh. The coffee pot can talk to the home automation dashboard devices and
nothing else, it can't send email. A laptop or a desktop has much broader
privileges. A dedicated server is constrained to its functions, yadda,
yadda.

Security policy can only work if the policy is being automatically
generated and maintained. If a network admin has to configure security
policy separately from administering the hosts, it will always be
inconsistent and out-of-date.


Yes, I know that there are bits and bobs that are kinda sorta part of such
a scheme floating around IETF and IEEE but they don't really work because
none of them is designed to realize an over-arching vision and so none of
the roads actually meet up. They are tightly focused, point solutions that
are more concerned about not treading on another group's turf than
delivering a seamless user experience. WiFi UI has been crap for over 25
years and it is still crap. We could make it un-crap in a few weeks if we
could get the right engineers in a room together with the right attitude.

All WiFi has atrocious security because consumer security is password based
with a single password per network. There are other options available in
theory for corporate environments at greater cost but they have withered
away because the consumer approach is the only approach every device
supports. So the attempt to establish a premium market failed and the
engineers are convinced that the reason is the technology failed rather
than their marketing was greedy and stupid.

To fix WiFi, begin with one simple principle: No passwords.

Devices should be able to authenticate to a WiFi network without the use of
a password ever.

Anyway, the pain has dulled enough for me to begin writing some code today
so I will.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20220107/a8177ed6/attachment.htm>