Re: [lamps] Hybrid pkix isn't needed

[Phillip Hallam-Baker <[e-mail]>]

On the question of timing, my starting point is looking at the current
state of Quantum Computing. Currently we have two main tracks to watch:
Josephson junction machines requiring very cold temperatures to maintain
the entangled state and trapped ion machines that don't.

The long and short is that the first has severe scaling challenges and is
at least as hard as fusion power and nobody can build a complete trapped
ion machine yet. But the state of the first suggests that we could
conceivably see a trapped ion machine built within ten years, albeit at low
probability. If they do, the machines could be built using standard VLSI
manufacturing so they will start at significant scale.

So 10 years is short enough to worry about data we are encrypting but we
don't actually need a PQC PKI to apply PQC to the transport layer. We can
use X448 to perform an initial key exchange and layer in Khyber for the
ephemeral.

The tricky part is data at rest. And there our current standards are far
behind what is needed to secure data at rest effectively.

S/MIME messaging is only aspect of Data at Rest. CMS is also used in
various Ford-Weiner key release based CRM systems. That is 1980s technology
and doesn't do the job we need today.

We are seeing very few breaches resulting from the flaws discovered in
transport security. Almost every breach follows the same pattern:

* First endpoint compromised through malware sent by mail or from Web site.
* Endpoint used to collect all materials on shared drives.
* Endpoint used as bridgehead to breach servers and extend attack.

While everyone is calling this 'endpoint security', that misses the most
important issue which is that the only reason cracking a single endpoint
out of tens of thousands in Megacorp.com can bring a billion dollar
enterprise to its knees is that we are not applying least privilege - the
data should be encrypted.

So for Data at Rest, we need PQC capabilities and threshold capabilities so
we can do separation of roles. Which means we can't do it all with khyber,
we need a hybrid system.

On top of that, beyond support for a PQC upgrade bootstrap, I cannot
imagine a situation in which I am going to desperately want a PQC signature
on a document without also wanting that signature to be fixed in a notary
log so I can know when it was signed. The chance of someone successfully
building a quantum cryptanalysis capable computer in our lifetimes is non
zero but it is much less than the likelihood of signing keys leaking.

So we need hybrid. But we should not start by trying to extend PKIX, that
should be the last thing we do.


PKIX has already been extended multiple times and there is a vast amount of
technical debt built up. That said, it is also the deployed legacy
infrastructure. I have been building a next generation Threshold Key
Infrastructure for four years now and in that time I have built three
separate approaches. I believe that the current specification is ready for
use in the real world, the standard lags a little and adding PDQ hybrid
will take another few months.

If you want a PKIX infrastructure that does what you really want a 21st
century key infrastructure to do, what I would do is to use the Mesh as a
prototype and then copy over the parts that are needed to PKIX.



On Mon, Jan 30, 2023 at 5:21 PM Stephen Farrell <[e-mail]>
wrote:

>
> I gotta say I'm with Watson basically, but open to being
> convinced that this stuff is needed nowish rather than being
> premature. Thus far, I'm very unconvinced and am also worried
> that a lot of the code that'd be needed will be liable to be
> buggy and not much exercised, which is a bad combination.
>
> On 30/01/2023 18:30, Mike Ounsworth wrote:
> > Especially since the NSA in their CNSA 2.0 have marked code-signing
> > as the most urgent use case to migrate to PQC. The idea is that a
> > device will leave your manufacturing facility with a burned-in trust
> > anchor that it should use for validating future firmware patches. For
> > good reason you can't change trust anchors in the field, so we need
> > to make sure those algorithms are going to stand the test of time for
> > the lifetime of the device.
>
> That's not at all convincing. As stated, we have hash-based
> sigs now that don't need any hybrid mechanism.
>
> S.
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>