Thanks for the feedback, Martin! > 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.
Good suggestion, I've added it to the document for the next version; https://github.com/dstebila/draft-stebila-tls-hybrid-design. Douglas On Mar 20, 2019, at 04:41, Martin Thomson <m...@lowentropy.net> wrote: > 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
