> If we assume servers only install one composite certificate, then the > clients need to accept all composites if it wishes to visit all servers.
The first sentence is true today: My client, if it wants to talk to every
server, will need to accept every traditional algorithm, assuming each
algorithm is the sole supported one at one server.
Clearly this is not always the case, so interop is limited. My point is that
composites should not make this much worse.
> As
> security crucially only depends on what the client accepts and not what the
> server provisions, this means we also cannot accept a preference for
> different composites based on security. So why prefer one composite over
> another?
The premise of composites (and any hybrid) is that one algorithm may fail and
you are relying entirely on the other one, even if you do not know which
(indeed, that) one failed.
Under these restrictions, it becomes impossible to define a natural
"preference".
But in the server-has-one-certificate case, this doesn't matter. The client has
to make a binary choice whether this certificate is acceptable or not.
Since the premise is that any algorithm could fail (hence you want two which
you initially trust), the sensical way to do this is as follows:
1. Identify the set of traditional algorithms which you would trust alone, say
ed25519 and rsa.
2. Identify the set of PQ algorithms which you would trust alone, say mldsa44
and mldsa65.
3. Now accept every combination of these, being mldsa44+ed25519, mldsa44+rsa,
mldsa65+ed25519 and mldsa65+rsa in this example.
>
> (Just support all variants is easier said than done, certainly if clients
> are constrained and need hardware acceleration. This is of course a bit
> farther from my usual field, but I'm sure there are folk on this list that
> are not very enthusiastic having to implement every ECC curve for which a
> composite is defined.)
This is fine. Take P256 as an arbitrary example to spell my point out:
Case 1: The constrained device might not implement P256 at all.
In this case it will not interoperate with a server offering a, say, MLDSA+P256
certificate.
However, note that such a device would, today, not interoperate with a server
offering a P256-only certificate.
Case 2: The constrained device implements P256 for _some_ composite PQi+P256.
In this case, I am arguing that for each PQ-algorithm, PQj, which is
additionally supported, the device could also implement the composite PQj+P256
at low additional cost. Indeed, the implementation could reuse both the
PQj-implementation and the P256-implementation, whether hardware-implemented or
not.
In other words, I do not assume that every client supports every composite
there is, just every composite which can be formed out of the individual
algorithms it supports. This should ensure that interoperability problems do
not become a greater concern than they are now (I'm not arguing that they are
of no concern now).
Generally, here is my preferred method for future-proofing constrained devices:
1. Take alle the traditional algorithms already supported.
2. Implement the PQ algorithms you intend to support somewhere. (This is the
main work)
3. Write wrapper code to support any combination of 1. and 2.
For any server with a T-Certificate: Get a T+PQ certificate (for the same T it
had earlier, should be a natural choice enforced by most CAs).
Here is my guarantee: If the client, after the composite-transition, cannot
connect to a server, then it either could not connect beforehand (because it
did not know/trust T) or it would have similarly failed with just PQ (because
it does not know/trust) PQ. It is in this sense in which we have not made the
situation worse.
> > I view this as the server supporting the cross product of one traditional
> > algorithm and one PQ algorithm.
>
> I'm confused now. Are we talking about composite or are we talking about
> Stephen's suggestion?
Yeah, sorry for the terminology there. I was still thinking of composites. If
the server supports just one composite for which it has a certificate, say
PQi+Tj, then this is every possible composite out of the one-element set {PQi}
and the one-element set {Tj}.
In general, I believe this to be the common case for servers (and the worst
case for interop), and expect a larger number of algorithms to be supported at
the client.
-- TBB
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
