Re: [Cfrg] Postquantum cryptography in IETF protocols

[William Whyte <[e-mail]>]

Hi Kenny,

I didn't see that mail, thanks for forwarding.

Personally I find Ben's position more convincing:

>> The other way round does neither: Just because there are Internet Drafts
specifying
PQ-safe key exchange algorithms, this does not mean they have to be
implemented. Anyway,
existing implementations are indications for the need of PQ-safe key
exchange algorithms.
Therefore, in my view, it is reasonable to specify Internet Drafts for
state-of-the-art
PQ-safe key exchange algorithms suitable for implementation.

There are organizations that need to plan for a migration now in order to
properly manage risk and that can't wait for the NIST process to complete.
Providing an interoperability specification for PQ algorithms to be used in
a hybrid context allows these organizations to start development and
prototype deployment.

I'm not sure the "current CFRG approach" has been formally decided on; it's
more "what CFRG happens to be doing at the moment". If CFRG members see
value in specifying a wider range of algorithms, the CFRG approach can be
changed.

Cheers,

William




On Wed, Mar 22, 2017 at 8:26 AM, Paterson, Kenny <[e-mail]>
wrote:

> Hi,
>
> This e-mail I sent back on 15th March laying out the CFRG leadership's
> current position on post-quantum algorithms does not appear to have made
> it into the CFRG archive and perhaps did not make it to the list. It seem
> pertinent to send it again, in view of an on-going discussion on the list.
>
> Regards
>
> Kenny
>
> On 15/03/2017 08:23, "Paterson, Kenny" <[e-mail]> wrote:
>
> >Hi Benjamin,
> >
> >Full disclosure: I am involved in one proposal being prepared for the NIST
> >process.
> >
> >
> >Wearing my CFRG co-chair's hat, I would say that Watson is correct, in the
> >sense that the current CFRG approach is to define RFCs for a few
> >relatively mature post-quantum primitives, such as hash-based signatures,
> >but to wait for the results of the NIST process for everything else.
> >
> >The NIST process is going to run for many years - it just started, and is
> >slated at 5-7 years. It will entail a significant effort by the research
> >community, which is right and proper given the current state of the field.
> >
> >Regards,
> >
> >Kenny
> >
> >On 15/03/2017 02:38, "Cfrg on behalf of Watson Ladd"
> ><[e-mail] on behalf of [e-mail]> wrote:
> >
> >>On Tue, Mar 14, 2017 at 10:31 AM, Tams, Benjamin
> >><[e-mail]> wrote:
> >>> Hi John,
> >>>
> >>>> Good that CFRG starts some more detailed discussion on PQC. It makes
> >>>>sense
> >>>> to support post-quantum key exchange for use cases that need long-term
> >>>> confidentiality (15 years). For other use cases I think it can wait
> >>>>until
> >>>> PQC key exchange algorithms has been thoroughly evaluated and
> >>>> standardized. If implemented now, it should be used in addition to
> >>>>ECDHE,
> >>>> just like Google has done with their experimental New Hope
> >>>>implementation.
> >>>
> >>> I absolutely agree with your view on the subject. Especially for those
> >>>use
> >>> cases where the attack scenario "collect today, decrypt tomorrow" is a
> >>>threat,
> >>> we should start thinking of PQ-safe key exchange methods in time. Even
> >>>if
> >>> they eventually turn out to be insecure; we can now combine them with
> >>> classical key exchange algorithms. We have nothing to lose.
> >>>
> >>> There is already IETF work addressing PQ-security in Internet
> >>>protocols, e.g.
> >>> IKE and an Internet Draft for a Quantum-Safe Hybrid Ciphersuite for TLS
> >>>
> >>> https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-03
> >>> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> >>>
> >>> On the other hand, there is (to my knowledge) no specification for a
> >>>PQ-safe
> >>> patent-free key exchange algorithm suitable for implementation. In
> >>>fact, in
> >>> https://tools.ietf.org/html/draft-whyte-qsh-tls13-03
> >>> only NTRUEncrypt is specified but is subject to patents.
> >>>
> >>> A possible first step is that CFRG creates an Internet Draft. In fact,
> >>> the algorithm New Hope has already been implemented as a plugin for
> >>> strongSwan (IPSec implementation for the Linux kernel)
> >>>
> >>>
> >>>https://github.com/strongswan/strongswan/tree/
> master/src/libstrongswan/p
> >>>l
> >>>ugins/newhope
> >>>
> >>> So why do we not start with a draft for which the above implementation
> >>>can
> >>> serve as a reference implementation?
> >>
> >>Why should we preempt the current NIST postquantum standardization
> >>efforts?
> >>>
> >>> Kind regards,
> >>> Benjamin
> >>>
> >>>
> >>> _______________________________________________
> >>> Cfrg mailing list
> >>> [e-mail]
> >>> https://www.irtf.org/mailman/listinfo/cfrg
> >>
> >>
> >>
> >>--
> >>"Man is born free, but everywhere he is in chains".
> >>--Rousseau.
> >>
> >>_______________________________________________
> >>Cfrg mailing list
> >>[e-mail]
> >>https://www.irtf.org/mailman/listinfo/cfrg
> >
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>