On Thu, Jun 19, 2025 at 12:18:16AM +0200, Yaroslav Rosomakho wrote:
> We have just submitted a new proposal, draft-yusef-tls-dual-certs-00, that
> extends TLS 1.3 to support authentication using two certificate chains: one
> using traditional algorithms and one using post-quantum (PQ) algorithms.
> This approach, aimed at closed environments and staged post-quantum
> migration, enables stronger session authentication by requiring both
> signatures to validate.
Much like the proposals for chameleon certs in X9.146, I see this
direction as fundamentally misguided. TLS signature algorithms provide
sufficient flexibility to obviate the complex juggling needed (and
attack surface) that this and related proposals entail.
In the case of key exchange "record now—encrypt later" justifies hedging
by using composites and relying on the stronger of two algorithms, in
case the selected PQ choice turns out broken (long before, if ever,
future CrQCs also break the classical component).
It is far from clear that such hedging is needed for authentication
certificates. The PQ algorithm only needs to be strong for the lifetime
of the certificate, and while peers (mostly clients) still consider the
algorithm secure. Once a PQ certificate for a broken algorithm expires,
or if clients no longer trust it, the risk exposure is gone.
The remaining risk is that of a secret catastrophic breakthrough, where
some nation-state agency completely breaks a PQ algorithm, but manages
to contain this fact somehow, while at the same time using it to
undetectably carry out clandestine MiTM attacks. I am far from
convinced that this scenario warrants either a zoo of PKIs or a zoo of
TLS extensions that vastly complicate the protocol. If the break
is either public or is gradual progress that weakens the algorithm over
time, alternatives can be phased in.
For a typical TLS server, in the case of certificates it should be fine
to not bother with hybrids, and deploy certificates for one or two
*pure* mainstream PQ algorithms. I see no need for a "zoo" of PKIs,
there's little urgency to deploy hybrid PQ certificates, by the time
these need to be fielded, it should be more clear which PQ signature
schemes have survived cryptanalysis long enough to warrant trust.
And a hybrid with just one of P256 or Ed25519 should be quite
sufficient, to promote interoperable deployment we should make it clear
that both are "MTI" for clients that support any hybrid scheme (that
is while support for hybrids is not MTI, those that do support hybrids
MUST support both Ed25519 and P256 for the "classical" component).
Similarly, in the coming years we should have a sense of which PQ
signature algorithms are also "conditionally MTI" (to coin a term) for
clients that support a non-zero set of pure PQ or hybrid algorithms.
That is, we should (not quite yet, but in a reasonable time-frame) focus
on designating an interoperable "conditionally MTI" suite of pure and
hybrid signature algorithms that will be supported by all clients that
support, respectively, and hybrid signatures.
At that point it will be sufficient to field:
- A pure classical certificate with RSA or ECDSA
- Zero or more pure PQ certificates, among which, if any are used,
at least one is a "conditionally MTI" pure PQ algorithm.
- Zero or more hybrid PQ certificates, among which, if any are used,
at least one is a "conditionally MTI" hybrid.
As a hypothetical example, if these remain unbroken.
- Conditionally MTI pure: ML-DSA (plus one more TBD)
- Conditionally MTI hybrid: Above + either P256 or Ed25519
Presto-magic, no zoo, each server need only support its current
choice of classical algorithms, plus one pure or hybrid scheme.
All of this handled via the extant TLS protocol, with no complex
extensions.
On Wed, Jun 18, 2025 at 03:40:05PM -0700, Watson Ladd wrote:
>
> More specifically, it's not clear to me why these are desirable
> mechanisms. Unlike confidentiality mechanisms, authentication
> mechanisms cannot be broken retrospectively. We already have a
> mechanism for negotiation that has functioned to enable transition
> from RSA to ECDSA, largely seamlessly. The scope in the document and
> justification of a smooth transition is already demonstrably met with
> no real change to libraries to implement this. I don't see anything
> in the introduction of the draft that makes the case here, unlike the
> one you cite as an alternative.
+1.
On Thu, Jun 19, 2025 at 01:30:00AM +0200, Yaroslav Rosomakho wrote:
> One of the key use cases is to simplify PKI architectures for closed
> environments that will have to deal with a mix of clients.
See above, let's focus on the real problem, that mix of clients is
sure to include TLS implementations that don't support the various
(IMNSHO redundant) complex schemes from X9.146 or this proposal.
We should instead focus on defining MTI combinations that pave a
path to interoperability for clients that support a pure or hybrid
PQ signature scheme, without a zoo of TLS extensions that make it
difficult to reason about TLS.
On Thu, Jun 19, 2025 at 01:47:28AM +0200, Yaroslav Rosomakho wrote:
>
> With a composite certificate approach two separate chains are sufficient
> only if one serves classic-only clients and composite-only clients that are
> compatible with a given choice of composites. PQ-only clients or clients
> with other opinions about components of PQ/T will require an additional
> chain for every variation.
But they are not sufficient given that these modifications to TLS look
quite complex, and I think unlikely to gain broad support. Let's
keep the protocol stable, and put the focus on taming the zoo.
--
Viktor.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
