Re: [Cfrg] Postquantum cryptography in IETF protocols

["Paterson, Kenny" <[e-mail]>]

Hi William,

You are right that there's no formally agreed approach for CFRG, but the
current approach that the *leadership* of CFRG (i.e. the co-chairs) would
like to take is that explained in my message below. But we can of course
revisit the question as a research group.

To reiterate: I would consider it a mistake for CFRG to go down the route
of standardising PQ algorithms ahead of the NIST process, aside from in
mature areas like hash-based signatures where we have a lot of research
that we can draw on. For me, the rest of the field is in too much of a
state of flux, and the expertise that might otherwise be available is
(rightly) focussed on the NIST process with its (rightly) much longer
timescales. 

I would welcome a CFRG-wide decision to look at "an interoperability
specification for PQ algorithms to be used in a hybrid context" as you put
it. But that's not the same as looking at PQ algorithms. Let's not
conflate/confuse them.

Further comments/discussion very welcome - as always.

Cheers,

Kenny 


On 22/03/2017 12:34, "William Whyte" <[e-mail]> wrote:

>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-fluhrer-qr-ikev2-03>
>>>> 
>https://tools.ietf.org/html/draft-whyte-qsh-tls13-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
><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
><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
>
>
>
>
>
>
>