Hi Ekr, Tiru, all,I believe the draft seems to be moving in a wrong direction compared to what I proposed based on a related formal analysis. While being a proponent of hybrid authentication, I*oppose* the current direction of the draft as it breaks the existing proofs -- symbolic and most likely computational too. My main concern is that the property that authors are trying to achieve is unclear. Given that the draft is useful in the transition period, it has to move fast and in a systematic formal way -- neither of which appears to be realized under the current approach.
If there is sufficient interest in dual certs, I can write my proposal as a draft after completing my formal analysis of my idea.
On 25.06.26 18:49, Eric Rescorla wrote:
Could you please clarify whether you mean superior in the sense of security or development convenience or something else?Overall, if we are to support the simultaneous use of PQ and traditional signatures in TLS, I think that composites are a superior approach.
One factor that I think is worth considering here is the pace at which this draft is moving. If it takes one year to address the feedback from IETF 123, what value would it add in the "transition" which is rapidly decreasing?As far as I can tell, the only real benefit of this design is that it allows you to perform a transition of the form traditional -> simultaneous PQ/T -> pure PQ while avoiding the need to issue separate composite certificates.
I agree. This seems insecure to me, and needs formal analysis for confirmation.With that said, even on its own terms I think this draft is trying to get too clever. Specifically by: [...] - Only signing a partial transcript.
At a high level, it's not clear to me that this encodes the right semantics. As covered in quite a bit of detail in Chrome's roadmap [0], we have to distinguish between the algorithm encoded in the EE's certificate and the algorithms used to sign that certificate and other certificates in the chain, and there are benefits to requiring a PQ PKI even if you don't have PQ keys (stage 3 in Google's roadmap).
Thanks for sharing the reference [0].
I agree this seems to open corner cases for security problems in TLS and formal analysis is required here.# Only Signing a Partial Transcript Instead of signing the whole transcript, as everything else in TLS does, each algorithm just signs the transcript corresponding to its own certificates. As I understand it, you are doing this for domain separation reasons, but the consequence is that we are in uncharted territory about the security of TLS, and in particular that neither signature is endorsing the other's certificates. Do you have any analysis for what this does to the security of TLS?
Just for clarity, are you thinking about any specific attack if the headers are not in the transcript hash? If so, can you explain the attack that you are thinking about.Incidentally, the way you have specified this seems to remove the Certificate message's headers, which would otherwise be in the transcript, as per S 4.4.1 of RFC 8446.
It seems like there ought to be some other way to provide domain separation.
I previously shared some thoughts with the authors which were not incorporated.
Best regards, -Usama
[0] https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
