Hi Ilari,
I fully agree with Scott's email below and have the same questions.In addition, I was a bit surprised to see the word 'dangerous' for which I have a related formal analysis based on which FWIW, I deem what Scott has described to be secure at the /symbolic/ (not /computational/) level. So I would like to understand what I have got wrong in my analysis.
In particular, our paper on this analysis was reviewed (and unfortunately rejected) at USENIX'26 but the reviewers did not have any technical objection to this part of the paper. I am sharing that to state that it was reviewed, and I am /genuinely/ interested in knowing what is considered 'dangerous' in this case. It's maybe some subtle point, but I would like to understand that. I'd appreciate it if you could explain that point so I can study more about it to reflect it in my formal models, and propose some solutions to the authors.
I acknowledge that symbolic analysis has limitations. Has 'dangerous' got something to do with cryptography? Do you recommend getting confirmation via computational proof in tools like CryptoVerif? or do you have an intuition where the proof will break at the computational level?
Thank you. Sincerely, -Usama On 30.04.26 17:42, Scott Fluhrer (sfluhrer) wrote:
Would you care to expand on that? Why is it dangerous?My understanding (and do correct me if I'm wrong) is that the proposal under discussion is that the server (or client in an mTLS scenario) sends multiple Certificate messages (to convey the multiple public keys) and multiple Certificate Verify messages, each of which signs with a different public key (and algorithm).As an example, the server might send both an RSA certificate (and certificate verify) and an ML-DSA certificate (and certificate verify); the client checks both, and proceeds only if both verify.I don't see why this is cryptographically dangerous. If the RSA certificate/signature is secure, then the authentication is secure, and likewise the ML-DSA certificate/signature. Of course, an implementation might have a bug where it doesn't check one of the certificates/signatures properly, but that's actually fairly easy to test.I do see a complication of how the client specifies its authentication policy; that is, what set of certificates it insists on authenticating (e.g. just one certificate is fine, or does it require both a classical and a postquantum certificate), but that detail can be handled within the protocol; it does not occur to me that it would be 'dangerous'.Now, I am not specifically advocating this approach; I believe that we will want to support hybrid authentication in some form, but I personally don't have a strong opinion on how that is done (whether parallel certificates as suggested here, or with composite certificates or possibly a third method). I'm just interested in your reasoning - why is the possibility of multiple things that don't interact considered excessive dangerous flexibility?
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
