Thanks to the authors for this survey. I think that it is good to have this sort of work is extremely valuable in informing decisions.
I would like to see one approach come out of discussion here. I don't want the protocol to be a tapestry of options. As someone who has to maintain software, that is a disaster. To be clear, I have a fairly strong preference for the design choices in draft-kiefer-tls-ecdhe-sidh. I don't see any reason to negotiate differently. The drawback is that you might duplicate shares for groups that you offer both in combination and separately (as noted in the draft), but the gains in terms of simplicity are significant. And the size increment resulting from duplicating classic shares is dwarfed by the PQ shares, so it's not that much of a loss. I have some reservations about the way that results are integrated into the key schedule. I pushed Franziskus toward concatenation, and it's good to see analysis supporting this choice. We did however discuss a few options that I don't see in the draft. The one I am most interested in has the (EC)DHE replaced by HKDF-Extract(classic, PQ) rather than classic || PQ. Adding new steps in the ladder as suggested by 3.4.3 would require disruptive changes to stacks. I'd be opposed to that. 3.4.4 suggests using the 0 step that exists, which would conflict with other proposed uses of that entry point. I don't think that it is a good choice. Cheers, Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
