Subject: [Cfrg] Fwd: New Version Notification for draft-whyte-select-pkc-qsh-00.txt

From: William Whyte <[email-masked]>
Date: Sun, 20 Sep 2015 22:52:40 -0400

Hi list,

following up on our discussion in Prague, I and my colleagues John Schanck
and Zhenfei Zhang have submitted an internet draft containing criteria that
can be used to select algorithms suitable for use in the quantum safe
hybrid (or "mix-in") context.

The MUST criteria are:

   The candidate algorithm MUST provide 128 bit security in the quantum-
   safe setting.

   If the candidate algorithm is subject to decryption failures, these
   MUST happen with a probability of less than 2^-74 (such that 128
   billion devices (2^7 * 2^30) each initiating 128 billion connections
   (2^7 * 2^30) will with high probability encounter no decryption
   failures).

   The candidate algorithm MUST have a set of publicly accessible
   documents specifying common techniques and implementation choices.
   [[ to the extent necessary to allow the development of interoperable
   implementations ]]

   MUST have a stable reference implementation available
   for the candidate algorithm.  The code needs to be rigorously tested
   and reviewable.

The SHOULD criteria are:

   The implementation SHOULD also be open source to allow for public
   auditing.

   The candidate algorithm MAY have a reference implementation for
   SUPERCOP.  Performance of the implementation on SUPERCOP MAY be taken
   into consideration when selections are made.

   Algorithms with provable constant time implementations SHOULD be
   preferred. However, this is not an absolute requirement as the QSH
   setting uses ephemeral keys and an implementation of QSH SHOULD only
   decrypt once with any key, so an attacker is unlikely to gain
   sufficient information from the time of a single decryption to
   recover the plaintext.

   The candidate algorithm MAY be standardized by another standards
   body, such as ANSI X.9, IEEE, or ETSI.  Algorithms that maintain
   creditability among multiple standards bodies SHOULD be preferred.

   The candidate algorithm MAY be either non-patented or patented but
   with FRAND (Free or Reasonable and Non-Discriminatory) licensing
   statement made and all relevant IETF IP declarations provided.

We've included some recommended NTRUEncrypt parameter sets as permissible
by these criteria, but this is a first draft and isn't yet intended to be
an exhaustive list. All feedback is welcome on both the criteria themselves
and whether there are other algorithms that meet them. (For example, there
may well be a spec of McBits detailed enough to support interoperability --
we didn't look hard for this in the the interests of getting this first
draft out, but if McBits meets the criteria it should of course go in).

Cheers,

William

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sun, Sep 20, 2015 at 10:42 PM
Subject: New Version Notification for draft-whyte-select-pkc-qsh-00.txt
To: Zhenfei Zhang <[email-masked]>, William Whyte <
[email-masked]>, "John M. Schanck" <
[email-masked]>

A new version of I-D, draft-whyte-select-pkc-qsh-00.txt
has been successfully submitted by William Whyte and posted to the
IETF repository.

Name:           draft-whyte-select-pkc-qsh
Revision:       00
Title:          Criteria for selection of public-key cryptographic
algorithms for quantum-safe hybrid cryptography
Document date:  2015-09-20
Group:          Individual Submission
Pages:          14
URL:
https://www.ietf.org/internet-drafts/draft-whyte-select-pkc-qsh-00.txt
Status:         https://datatracker.ietf.org/doc/draft-whyte-select-pkc-qsh/
Htmlized:       https://tools.ietf.org/html/draft-whyte-select-pkc-qsh-00

Abstract:
   Authenticated key exchange mechanisms instantiated with cryptosystems
   based on integer factorization, finite field discrete log, or
   elliptic curve discrete log, are believed to be secure now but are
   vulnerable to a harvest-then-decrypt attack where an attacker who
   cannot currently break the mechanism records the traffic anyway, then
   decrypts it at some point in the future when quantum computers become
   available.  The Quantum-safe Hybrid approach is a modular design,
   allowing any authenticated key exchange mechanism to be protected
   against the harvest-then-decrypt attack by exchanging additional
   secret material protected with an ephemeral key for a quantum-safe
   public key cryptographic algorithm and including that secret material
   in the Key Derivation Function (KDF) run at the end of the key
   exchange.  This approach has been proposed in TLS as the Quantum-safe
   Hybrid handshake mechanism for Transport Layer Security protocol
   (QSH_TLS).  This document provides a guideline to criteria for
   selecting public key encryption algorithms approved for experimental
   use in the quantum safe hybrid setting.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 21 Sep 2015 13:50:07 +0100

Hi William,

>    statement made and all relevant IETF IP declarations provided.

That's a good statement of a what I figure may be a formally
acceptable (if novel) IPR condition. However,...

In the real world, I would confidently predict that any algorithm
that is in practice encumbered will not be widely deployed. I think
we've seen plenty of evidence for that opinion.

My personal conclusion from all of that is that anyone spending time
here on developing or reviewing proposals that involve encumbered
crypto algorithms is simply wasting that time. I do get that others
can validly have different opinions on that, but wearing an IETF hat,
I'd argue that this RG is far more useful the more it deals with
what might get widespread deployment at "Internet scale" (or some
such phrasing).

So, I'd suggest instead to adopt the IPR goals that this RG set for
itself when considering new curves. IIRC, that boils down to saying
that only things believed to be in practice unencumbered should ever
be considered in any detail.

One could also perhaps add a condition that only things with IPR
declarations likely to be acceptable by today's most common open-source
crypto libraries should be considered.

Cheers,
S.

PS: Note that I'm not arguing the pros and cons of patenting algorithms
above - if someone has some patent there is nothing to stop them from
making their algorithm freely usable. (Hence the "in practice" phrase
above.)

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 21 Sep 2015 16:12:22 +0000

In my 2+ decades of IETF/IRTF experience, the choice has been to stay away
from patented non-free algorithms, period. Thus an acceptable candidate
algorithm must be FPARF (Free or Patented and Royalty-Free for use in IETF
protocols :).

As a side-note, I’ve yet to see a license-able product that claims to NOT
subscribe to "Reasonable and Non-Discriminatory licensing”, so that’s
pretty much a null-statement (or no-op,  depending on your preference :).

P.S. I concur with Stephen: "anyone spending time here on developing or
reviewing proposals that involve encumbered crypto algorithms is simply
wasting that time."
-- 
Regards,
Uri Blumenthal

On 9/21/15, 8:50 , "Cfrg on behalf of Stephen Farrell"
<[email-masked] on behalf of [email-masked]> wrote:
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>https://mail.ietf.org/mailman/listinfo/cfrg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 21 Sep 2015 21:06:07 +0200

> algorithm must be FPARF (Free or Patented and Royalty-Free for use in IETF

I believe we have seen evidence that even the qualifier "for use in IETF
protocols" is too limiting.  Many crypto libraries cannot know for what
purpose their APIs will be used for, so limiting the ability to use an
algorithm for "an IETF protocol" is in practice a non-starter for
deployment.

> reviewing proposals that involve encumbered crypto algorithms is simply

+1

/Simon

---

From: Brian Smith <[email-masked]>
Date: Mon, 21 Sep 2015 13:11:07 -0700

> algorithm for "an IETF protocol" is in practice a non-starter for

I strongly agree. Plus, the IETF benefits a lot from non-IETF-standard
protocols. We would not have HTTP/2 if there were essential patents that
were restricted to IETF protocols only, as Google's pre-IETF work on the
SPDY was essential to making HTTP/2 as good as it is. It would be good to
see an official statement from the leadership to the effect that we'll not
do work on protocols and algorithms with such field of use restrictions.

Cheers,
Brian

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 22 Sep 2015 07:11:31 +0000

Simon Josefsson <[email-masked]> writes:

>algorithm for "an IETF protocol" is in practice a non-starter for deployment.

It really depends on what it is.  For example every single IETF standards
group has seen fit to invent their own PRF and no-one uses the one from
standard X in standard Y, so even a far more restrictive qualifier "for use
only in IETF protocol X" wouldn't make any difference (if you want to use a
PRF standalone, just go with HKDF and you're done, you don't need some oddball
protocol-specific PRF).

More generally, there are lots of mechanisms that are really only used with
specific protocols, with there being no demand for using them elsewhere.  For
example no-one's ever come to me and asked to use TLS' (EC)DH -> premaster-
secret -> master-secret mechanism in anything else, nor the SSH equivalent, or
PGP's weird IV-handling mechanism, or S/MIME's key wrapping, or a pile of
other protocol-specific mechanisms.  They want a black box that does TLS (or
PGP, or whatever), not any individual component thereof.

So while I would like to have blanket permission to use X, for a lot of X's
having their use tied to a particular protocol, or IETF standards in general,
has no real consequences because they're not used outside the protocol anyway.

Peter.