Subject: [TLS] draft-stebila-tls-hybrid-design comments

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Mar 2019 04:41:10 -0400

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 Mar 2019 17:45:15 +0200

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