[Cryptography] Old Let's Encrypt's Root Certificate expires 30th September 2021

[Phillip Hallam-Baker]

On Wed, Sep 29, 2021 at 12:57 AM Dave Horsfall <dave at horsfall.org> wrote:

> Seen on another list...
>
> -- Dave
>
> ---------- Forwarded message ----------
> Date: Tue, 28 Sep 2021 15:47:23 +1000
> From: Andrew McNamara
> Subject: APPLIX-L Old Let's Encrypt's Root Certificate expires 30th
> September
>      2021
>
> Popular CA Let's Encrypt's original root certificate expires on 30th
> September 2021. Their issued certs autorenew, and are signed with a new
> root, however vendors were slack about picking up the new root, and there
> are a lot of devices that no longer receive vendor cert updates, so
> there's going to be certain amount of pain after the 30th.
>
> https://scotthelme.co.uk/lets-encrypt-old-root-expiration/


[ObDisclosure, I have not been employed by a company operating a CA for
over four years now. This is not different to what I said in those days.
The replacement I am working on will render much of the existing WebPKI
market obsolete but it will create a much larger market in the process. [*]]


The WebPKI is just a bad fit for IoT security. Not what it was designed
for. Problem is that we have path dependence.

The WebPKI was only designed to make shopping online as secure as
shopping in line at the store. That was the design brief I wrote, that is
what we delivered. Confidentiality was not a part of that brief because in
1994, crypto was still under export control.

Of course, it is inevitable that just as the high price of gas in the UK is
being blamed on the shift to wind rather than Russia and Brexit, the
botched root rollover is blamed on everyone except the CA what botched it.
But as with crypto-securities, there is a force of darkness and a force of
light and every failure of the forced of darkness must be severely punished
(e.g. Symantec CA) and we must understand that if the forces of light have
any difficulties these must be excused as their system is still in
development and it is in any case the fault of the forces of darkness that
there were any difficulties at all.


If all you want is confidentiality, unauthenticated ephemeral key exchange
is sufficient to defeat passive attack which is more than sufficient to
control my conversations with my house thermostats, etc. It was not
necessary to dismantle my work and the work of others to turn the WebPKI
into the WebPKI-Lite we have left.

Let's say we do want to authenticate that conversation. The WebPKI isn't
designed to do that, nor does a LetsEncrypt cert add any value because it
only binds an endpoint to a DNS name and user's don't have DNS names
either. All LetsEncrypt does is prevent Comcast, Verizon etc. replacing
Google's ads in content their customer's download through their ISP. Which
is something I am not entirely sure they were really planning to do because
stealing revenue like that would be a stupid business model and be
regulated out of existence.

If its Alice's thermostat you want to authenticate, you need to validate
the key to Alice. Alice is not an organization. So the WebPKI which is an
organizational authentication was clearly not the right fit. A device cert
is only saying that 'Nest made me', it is not saying what Alice needs to
know which is 'I belong to Alice'.

The WebPKI-Lite and DNSSEC are no better because they only authenticate to
a DNS name and the DNS is only designed to name organizations. It is also a
stupidly expensive infrastructure that costs $10/yr to rent names.


That is why I am proposing the callsign infrastructure. Alice buys a name
for a really modest fee which is then hers for life. No rental. No renewal.
So she can bind her thermostats to @alice and they are bound to her Mesh
until she unbinds them. Alice's browser can have an extension that
recognizes a Mesh Connection Assertion[*].

The callsign registry as designed costs very little to run because 1) the
expensive part of DNS is cost shifted to Alice's Mech Service Provider and
2) 99% of the cost of core DNS is dealing with abuse which becomes
pointless when bringing it down doesn't cause the Internet as a whole to
fail.

My design goal is to sell (not rent) callsigns for $0.10 each. Why charge
at all? Well, I can certainly fund the registry myself if it only has a few
million users but running it for a billion users is going to cause costs to
rise beyond what anyone who is not build-a-spaceship rich. Not thinking
about costs until it was too late caused the DNS to end up with the very
worst cost model in which the entire enterprise is rent seeking. GTLDs
should not cost any more than names in .com. The money will go to a not-for
profit which will put any surplus into funding development of Mesh
applications and other related work.


OK so why does the Mesh Callsign PKI work when efforts to make S/MIME and
PGP web o' trust failed?

The answer is simple, every Mesh name registration is a key registration.
So there is no ambiguity[*] in what key to use to communicate with @alice,
for Trust On First Use, it is the key published in the registration of
@alice which belongs to Alice. For Trust After First Use, it is the key
that was obtained in the first use interaction.

I spent 30 years trying to work out a better way to validate Alice's claim
to alice at example.com and failed because the name does not belong to Alice.
There is no way to make that system work well except for the case where it
it example.com that is being authenticated and 'alice@' is merely a
specializer narrowing down the field of communication.


The Mesh just passed its complete functional unit tests for phase 1 before
I started writing this email. I have to re-integrate the transport layer
after making changes to the authentication scheme and I have to write some
more tests but Phase 1 is almost ready to ship. The Callsign registry is
not a part of that work but there is code and it is the first priority for
phase 2.


[*] Many details and curlicues elided.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20211001/e699c874/attachment.htm>