[TLS] Re: Fwd: New Version Notification for draft-yusef-tls-pqt-dual-certs-02.txt

[Muhammad Usama Sardar <[e-mail]>]

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:
> Overall, if we are to support the simultaneous use of PQ and
> traditional signatures in TLS, I think that composites are a superior
> approach.
Could you please clarify whether you mean superior in the sense of 
security or development convenience or something else?
> 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.
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?
> 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.
I agree. This seems insecure to me, and needs formal analysis for 
confirmation.
> 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].

> # 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?
I agree this seems to open corner cases for security problems in TLS and 
formal analysis is required here.
> 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.
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.
> 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/