> Sam just ran the analysis. The TLS 1.3 proofs they have work without > Certificate in the transcript, which is equivalent to a zero-bit > truncated hash.
I assume the client hello extension still has the certificate digest, yes? This means that the analysis probably relied on agreement of the certificate hash from the client hello. I’d imagine that a full security analysis of this mode depends on which model of certificate issuance we use. For example, is it possible for a website to use the same public key on two certificates for two different purposes? Is it possible for an attacker to obtain a certificate from a CA for a public key even though it does not know the corresponding private key? Also, is this mode intended to be used for RSA handshakes in TLS 1.2? In that case the proof of private-key possession comes quite late in the handshake. Even for signature-based ciphersuites, I would need to look closer to be convinced that the ServerKeyExchange (in TLS 1.2) and ServerCertificateVerify (in TLS 1.3) do provide sufficient guarantees on which certificate/private key was used to create the signature. Best, Karthik > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
