Re: [Cfrg] Postquantum cryptography in IETF protocols

That draft is in the process of being updated, but it was never intended to
propose static NTRU keys; if it looks like it does, it needs to be
clarified. NTRU key generation is fast enough that there's no need to avoid
ephemeral keys.

Cheers,

William

On Wed, Mar 15, 2017 at 1:08 PM, John Mattsson <john.mattsson@ericsson.com>
wrote:

> TLS 1.3 forbids static RSA for a reason, draft-whyte-qsh-tls13-03 seems to
> bring it back in the form of static NTRUEncrypt. I see no reason to do
> that. If someone wants to do early PCQ in TLS 1.3, I think the two lattice
> based protocols suggested by David McGrew (Frodo, New Hope) as well as
> Supersingular Elliptic Curve Igogeny Diffie-Hellman (SIDH) is the way to
> go. The lattice-based variants are fast while SIDH has much smaller
> ephemeral keys.
>
> John
>
>
>
> On 2017-03-15, 16:24, "Cfrg on behalf of Ilari Liusvaara"
> <cfrg-bounces@irtf.org on behalf of ilariliusvaara@welho.com> wrote:
>
> >On Wed, Mar 15, 2017 at 01:10:58PM +0000, Tams, Benjamin wrote:
> >> Hi Watson,
> >>
> >> > Why should we preempt the current NIST postquantum standardization
> >>efforts?
> >>
> >> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> >
> >Briefly read that document. Some quick comments:
> >
> >- Looks quite confusing. Especially the parts about HelloRetryRequest.
> >  But looking closer, that message is not used except for handling
> >  missed algorithm guess, right? So that if client guesses right (and
> >  it can make multiple guesses at cost of computation and bandwidth)
> >  there might not be HRR, right?
> >- I don't think extending TLS extensions past 64kB is feasible.
> >  Especially in ClientHello It would require changes with nasty
> >  side-effects.
> >- The document looks to be made for older draft of TLS 1.3. The
> >  way key is combined is bit unclear. I presume the key mixing
> >  should be done in two steps (adding a new step into TLS 1.3
> >  key schedule, as the two existing mixing steps are already
> >  used for PSK and DH) because that's likely the easiest to
> >  implement.
> >- Adding new handshake messages should be avoided, but AFAICT,
> >  there are none added.
> >
> >
> >-Ilari
> >
> >_______________________________________________
> >Cfrg mailing list
> >Cfrg@irtf.org
> >https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>