On Mon, Feb 9, 2026 at 12:46 AM Muhammad Usama Sardar < [email protected]> wrote:
> Hi authors, > > Please accept my sincere apologize that it is too late in the process. I > tried to avoid all the PQ discussions for quite some time, but I think the > WG is giving repeated reminders that it is unavoidable. I am totally fine > if the following clarification requests cannot be accommodated in the > draft, but I would like to understand it anyway. > > Since RFC8446bis is in the publication queue, I was wondering if there is > some specific dependency on RFC8446 compared to RFC8446bis. In other words, > is there a good reason for using RFC8446 instead of RFC8446bis? > Not that I know of. > Another question I have is about the following paragraph of security > considerations: > > > The same security considerations as those described in [hybrid] apply to > the approach used by this document. The security analysis relies crucially > on the TLS 1.3 message transcript, and one cannot assume a similar > hybridisation is secure in other protocols. > > Security considerations of [hybrid] talk about [GIACON], [BINDEL], > [FLUHRER], [LUCKY13], [RACCOON], and [AVIRAM]. So, when the above paragraph > says "The security analysis" in the paragraph, which one is intended? > [GIACON] has the main ideas, which are applied to TLS 1.3 in [BINDEL]. > In general, is it the correct interpretation of the sentence: the proposed > hybridization may not apply even to closely related protocols like EDHOC, > and each protocol would require its own security analysis? > >From a quick look I see EDHOC has a message transcript for which this approach is certainly fine, but the devil is in the details. Best, Bas > Thanks. > > -Usama > _______________________________________________ > 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]
