Weak TLS handshake signature downgrade protection for PQ migration

[bwesterb]

TLS 1.3 has broken key exchange downgrade protection: if client and server both support (but not prefer) a broken curve, then they will still safely negotiate the preferred curve. (This does assume the other primitives, notably the handshake signature, are not broken.) This is not the case for TLS 1.2.

TLS 1.3 doesn't have such downgrade protection for its handshake signature schemes: a MitM can always downgrade to a broken handshake signature scheme that both client and server support.

For the migration to post-quantum cryptography, it's desirable to also be able to support broken handshake signature schemes (for lagging clients), while still having downgrade protection. MTC offers an opportunity to fix this (with the big caveat that the plain X.509+CT fallback still allows the downgrade attack.)

In #38 David proposes to add a non-critical extension to TLSSubjectInfo with a weak signature scheme, that signals (which?) stronger signature schemes are supported. A client which signalled to prefer those, but didn't get them served by the server (because of a MitM) can then abort. This works, because the authentication of assertions in MTC is post-quantum secure. (Well, actually only if the MTC CA signing keys is post-quantum.)

I think we should include support for this out of the box.

Perhaps simply adding

    SignatureScheme other<0..2^8-1>;

to TLSSubjectInfo.

[bwesterb]

"Lagging clients" is a bit misleading: if clients are to support MTC, then they can just as well support Dilithium2 from the get go. This downgrade protection helps if Dilithium2 turns out to be broken, or to support some clients that want to risk using classical signature schemes for performance reasons.

[thomwiggers]

(Well, actually only if the MTC CA signing keys is post-quantum.)

It seems weird that a client would be able to verify an MTC CA signing key that is post-quantum (and unbroken), but not use the same (unbroken) algorithm in the the handshake signature---don't you mean lagging servers that still want to participate in MTC?

[bwesterb]

It seems weird that a client would be able to verify an MTC CA signing key that is post-quantum (and unbroken), but not use the same (unbroken) algorithm in the the handshake signature

With the current proposal, there is only one MTC CA signature per CA per hour, that only Transparency Servers check (the latter point is up for discussion). That's quite a niche application. We could use a conservative scheme with large signatures such as SPHINCS+. Or we could even use stateful hash-based signatures there, using the nth one-time signature for the nth batch #27. Also, there are probably far fewer MTC CAs and TSs, than there are TLS servers and clients. So I do not think that what would work for the MTC CA signing key, works for the rest of the Web.

[thomwiggers]

Right, thanks for clearing that up. How does the client authenticate the batches it receives? If I can forge arbitrary batches because the authentication algorithm is broken or I can MITM the update process, then we still do not have this downgrade protection (with extra steps); or am I missing something?

[bwesterb]

How does the client authenticate the batches it receives?

For the case of a browser, we assume a secure update mechanism that we leave out of scope. (Browser vendor's update servers could use pinned public keys overriding MTC.) There still is a transparency issue though: how do we detect misbehaving browser vendors #58.