Re: [lamps] Hybrid pkix isn't needed

[Tim Hollebeek <[e-mail]>]

> Hash based schemes are secure if any signature scheme is secure. Even if we
> want to hybridize, having hybrid keys in certs seems a lot simpler to me than
> tying multiple certs through complex mechanisms.
> 
> [CW] The PQC hackathon during IETF115 bears out that composite is not
> difficult to implement. Interoperability was demonstrated between several
> implementations fairly quickly.

Also, while the security of hash-based encryption algorithms is trivial, the key
management for hash-based algorithms is complex and dangerous which
is why many of us who have been pushing them for about 5+ years now only
feel comfortable with them as part of well-vetted HSM implementations.

Key management for traditional single PQ pairs and for composite are much
more straightforward.

There are several use cases where hash-based signatures make a ton of sense,
but their utility will decline over time as we gain confidence with the newer
stateless NIST algorithms, and their key management challenges mean they are 
not the solution to all the world's problems.

The same is true of composite certificates, to some extent.  We really should
be seeing more concrete analysis of how the transitions, including key management, 
will work at scale, and what special considerations are necessary for each 
particular use case, because it probably will be different.  For example, TLS is 
an online authentication protocol (at least the relevant part here), and so 
negotiation and single certificates makes a lot of sense, but that doesn't mean 
there aren't a lot of useful discussions to be had about how pairs of key pairs 
need to be managed during the transition to avoid risks that will arise due to 
the transition process.  Being able to play games with which key pairs do / do 
not go together will almost certainly be part of some of those shenanigans, 
which is why I think the discussions about how to do bindings is very useful.

In situations where there is no online negotiation, multiple signatures and/or 
multiple keys might be part of the solution.  Very few signature systems today 
support multiple signatures (the only major one I can think of is actually 
probably being replaced as part of the PQ transition anyway), so it's new 
development regardless of the strategy in most cases.  

Many of discussions that I've seen over the years claim that one strategy is 
clearly simpler than another, but in my experience, they're mostly just 
moving complexity around, and by not handling it in one particular way at 
one particular layer, they're forcing the same complexity (or worse) onto 
another layer and encumbering other techniques.  Which strategy is best 
for each particular use case, and what the challenges and advantages / 
disadvantages are, is what we really need to be discussing in a careful way.  
But instead we get stuck in loops with messages that sound suspiciously like 
"technological concept X is bad and I don't like it," but with little actual 
analysis that moves the discussion forward.

On the subject of composite certificates, unfortunately, some of the people 
involved have managed to make them far more complicated than they 
need to be (in my opinion, sorry guys), and this has unfortunately made them 
appear more complicated than they necessarily are.  For example, I see little, 
if any, benefit to having more than two keys in a certificate.  This is a 
technology that, to the extent it has a purpose, is enabling transitions to 
happen more smoothly and securely, by running the same cryptographic 
binding across the identities and both keys, which is the simplest possible 
way to express the binding.  Which is why I was originally drawn to it.

Two certificate transition strategies are also feasible, but then key management 
is more complex, and codifying the binding into the certificates is something that
may also makes sense and simplifies key management.  As a reminder, correct
key management is always the hard part, but it isn't as fun to talk about, so it
gets less attention.

In all of these cases, the design is complicated by the fact that one of the two 
binding mechanisms grows weaker over time, so care needs to be taken about 
which aspects need only be trustworthy now, and which aspects need to 
continue into the future.  This is why all of this technology needs to be carefully
standardized with well written security consideration sections, because pitfalls
and footguns abound, no matter how you try to do it.  It's a complicated topic.

All of this basically just means we still have a lot of work to do on figuring out, 
analyzing, and documenting exactly what each of these techniques can and 
can't achieve, and how they can be put together into systems that will help us 
transition all of our cryptosystems to newer, more secure versions on a relatively 
short timescale.  It's an important problem and we're either going to do a good 
job of handling it, or we're not.  I would prefer we work together on figuring 
out what's best for each of these transitions, as I've seen no evidence that there 
are any silver bullets out there that make any of them trivial.  Except possibly 
TLS which keeps distracting us, when we really should probably put it down 
and come back to it after all the real problems are sorted.  That one's pretty 
easy and not that time sensitive.

-Tim