On Fri, Apr 10, 2026 at 9:48 AM Deirdre Connolly <[email protected]> wrote:
> > is more secure > > is a point of debate. The text on #main currently does not state as fact > one side as more secure than the other > As Deirdre says, this is contested. On balance, my preference is for hybrids, but I don't think this text is correct as written, for two reasons: 1. To the extent to which we're assessing the risk of algorithmic compromise, it doesn't matter whether we actually have more confidence in the traditional algorithm than the PQ algorithm, because the risk of joint compromise will always be less for the hybrid as long as there is some chance that the PQ algorithm will be broken and the traditional one will not be. 2. Contrariwise, even if there is no possibility that there will be an algorithmic compromise of the traditional algorithm it does not follow that the hybrid is more secure than pure PQ because there might be a vulnerability in the traditional code that leads to compromise of the endpoint. If the endpoint doesn't support traditional algorithms at all, this exposure doesn't exist. As I said, my preference is for hybrids, but I think trying to produce some text that will achieve consensus that says, in essence, "hybrids are better" is quite challenging and probably not worth the effort. Rather, I think we should just encode it in the Recommended=Y field and leave it at that. -Ekr > > On Fri, Apr 10, 2026, 8:12 AM Salz, Rich <rsalz= > [email protected]> wrote: > >> How about adding this to the end of the security considerations section? >> >> In deployments where the size and computation cost of deploying a hybrid >> is negligible or otherwise not a concern, a PQ/T hybrid is more secure as >> the traditional algorithms have had more analysis than their post-quantum >> counterparts. In this case, developers SHOULD strongly consider if a PQ/T >> hybrid meets their needs. >> >> _______________________________________________ >> TLS mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
