[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





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. 

_______________________________________________
The cryptography mailing list
cryptography AT metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography