Hi Dan, If memory serves, this came via discussion on the list in July 2021 after my presentation at IETF 105. At the time we presented a choice between two main approaches: one where each part of the combination was fully negotiated with corresponding data structures for everything, and a simpler approach where all combinations were fixed in code points with concatenated data structures. Stronger support came for the latter. There were some voices advocating for supporting more than 2 algorithms, and some advocating for only 2. I don't believe there was a vote taken, just the sense that there was stronger support for only 2.
Looking at the document as it stands, since it uses new named group code points for each combination and simply concatenates key shares (for transmission) and shared secrets (in the key schedule), it would be straightforward to let it specify that you concatenate *all* the key shares / shared secrets in the appropriate order, rather than just 2. As this document doesn't specify particular combinations, it would be up to later documents to actually put forward the case for a particular set of 3 or more algorithms being a worthwhile combination. Douglas > On Aug 5, 2021, at 15:22, Dan Brown <danibr...@blackberry.com> wrote: > >> -----Original Message----- >> From: TLS <tls-boun...@ietf.org> On Behalf Of Douglas Stebila >> We wanted to see if there is any further feedback on our draft "Hybrid key >> exchange in TLS 1.3" ... We have not received any new feedback from the > working group >> since we posted our last non-trivial update in October 2020. > > Allowing 3 or more key exchange methods in a hybrid combination should > somehow be an option, for a user who can afford the extra cost and is > risk-averse and has high-value data to protect. > > I was told this issue (2 versus 2+) was already discussed on the list, but I > must have forgotten (or missed) that conversation. > > A workaround is to nest TLS into TLS, to get more types of key exchange, or > to apply the extra key exchanges at the application layer, on top of TLS, > for those (few) who want the extra security. These workarounds imply > applying symmetric crypto twice, which does not help against the quantum > threat. > > > > > ---------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
