On Wed, Mar 20, 2019 at 04:41:10AM -0400, Martin Thomson 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. > > 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.
Yes, duplicating shares is the easiest, and in fact that is the way I took when I cooked an implementation as experiment. It basically takes the simplest way for everything: - Use one algorithm that is internally composite. - Concatenate shares - Concatenate secrets. The duplication enlarges key data by about 5% (as PQ key size is ~18.5x classic key size). > 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. Beware that construct is not CR-preserving. > 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. Furthermore, that 0 step is in wrong place (after handshake keying) for this kind of use. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
