Minutes IETF106: cfrg
minutes-106-cfrg-00

CFRG meeting 20 Nov 2019

Wednesday, November 20, 2019
13:30-15:00, room: Canning

Chairs:  Alexey Melnikov, Nick Sullivan, Kenny Paterson (not present)

Administrivia...

RG document status:
  - RFC published on re-keying
  - Argon2 document is nearly done
  - various active drafts -- h2c, vrf, kangaroo12, voprf, hpke.

  Q (Colin Perkins) on changes to Argon2 draft, thought there would be an
  update, talk later.

Crypto review panel update
  - lots of good work done, thanks!
  - many nominations received for new membership.
  - New members for 2020-2021 to be announced next week.

PAKE selection process update
  - narrowed it down to 2 balanced and 2 augmented PAKEs
  - Round 2 of selection to follow

-----------------------------------------

Status of PAKE Selection Process - Stanislav Smyshlyaev
  - Process recap
  - 8 PAKEs, 4 balanced and 4 augmented, were submitted
  - great team of reviewers
  - reviews collected on github-- https://github.com/cfrg/pake-selection
  - all reviews were gathered and reviewed again by 4 reviewers (Bjoern
  Tackmann, Russ Housley, Yaron Sheffer, Stanislav Smyshlaev), selected 4 PAKEs
  for next round:
       * SPAKE2 (balanced)
       * CPace (balanced)
       * OPAQUE (augmented)
       * AuCPace (augmented)
  - we can now select 1 (or 0) of each
  - additional questions for 4 candidate PAKEs to be collected
       * use same constant for SPAKE2, can constant use h2c
       * others
  - expect Round 2 to start, new reviews for 4 candidates by 14-2-2020
  - expect chairs to present reviews and specify what happens when selection is
  over
       * detailed description of protocol published as RFC
       * test vectors
       * guidelines

No questions.

-----------------------------------------

Hash to curve update -- Chris Wood

  - removed Icart
  - promoted simplified SWU for weierstrass curves
  - shallue-van de Woestijne parameterizations now applies to any curve
  - bunch of minor updates-- guidance for mapping functions and alternate
  base-to-hash
    functions, clarify output to sign to align with vrf draft, new Z selection
    code
  - next steps: add test vectors, finish ongoing implementations, RGLC? Chairs
  don't
    object

Q: Stanislav-- needed for PAKEs, review needed, happy to review document
A: yes, the review panel
Chairs concur

-----------------------------------------

HPKE -- Richard Barnes

  - minor technical changes, "single-shot" API, clarification and cleanup, test
  vectors - analysis by Benjamin Lipp based on reasonable assumptions to get
  IND-CCA2 public key
    encryption, all 4 modes analyzed.

Q: Chris-- want to make analysis general for any KEM but now focusing on DH
A: yes, if you want to help please help

  - next steps, implementation interop, finish analysis, start RGLC? Chairs
  think
    we can do CFRG LC

Q: Chris-- encrypted SNI may depend on this so timelines are sensitive, other
stuff
   has started using HPKE so we may want to get this out sooner rather than
   later
A: RFC or stable?
Q: well, stable...dunno
Chairs: when it gets stable enough we'll do RGLC

Deoxys-  Thomas Peyrin

  - Proposing 2 modes for an AE primitive
  - get efficiency gain and avoid pitfalls of misordering, feature of
  authenticated-only - CAESAR competition picked this as a winner in "Defense
  in depth" category. - problem is a limit on the number of queries based on
  birthday paradox, solution is to
    get a beyond-birthday mode beyond 2^(n/2) potentially up to full 2^n
  - security will remain quite high even as queries grow
  - want nonce-misuse resistance. Nonce misuse is a big problem with AE, need
  robust defense
    even if the nonce is reused (some) security is retained
  - design review (see slides)-- it's tweakable, allowing for a selection from
  a family of
    permutationsof the block cipher mode, different modes allow for different
    amounts of tweakery
  - it's very efficient and unpatented
  - SCT AEAD Mode uses this AE
    * 2 pass, since it has nonce-misuse resistance
    * very efficient, almost no overhead for small messages
    * provably secure, strong MRAE security notion
    * inverse-free (for decrypt)
    * no patent
  - new proposed mode ZMAC/ZAE
    * little more efficient but more complex
  - comparison between AES-GCM-SIV and Deoxys
    * Deoxys was CAESAR winner, best tradeoffs for efficiency and flexibility
    * GCM is sensitive to timing attacks, this not so much
    * SCT is inverse free, more efficient in hardware
    * higher security for number of queries
    * Deoxys is more efficient on smaller packets, AES-GCM-SIV more efficient
    on larger ones

Q: Dmitri Belyavsky -- did you study applying ways to deal with side channel
attack
   protection?
A: we are studying this, we're working on modes to provide this, ongoing work

Q: Vasili Shishkin -- how much cryptanalysis has been done?
A: it's on the website

Q: Stanislav --  we have more modes for AEAD, we might want to select 1 or more
of the
   best AEAD modes and make a CFRG recommendation, a la our PAKE process, for
   AEAD
A: the crypto community already went through this work, different portfolios for
   selection, this one the "defense in depth" portfolio
Q: yes but if there are other properties needed, important for different
schemes,
   is fully parellelizable better than nonce misuse resistance, etc, things to
   look at
Chairs: yes, we will keep an eye on this space

-----------------------------------------

Committing AE-- Nick

  - how is this different than regular AE? AE where it's hard to find a
  ciphertext with
    multiple correct decryptions, binding committments
  - intuitively, imagine a safe and a key. this breaks down if keys are
  adversarial,
    if there are multiple possible decryptions this binds to a single one.
  - e.g. CTR is not committing, it can be decrypted with any key, GCM is not
  committing - where is cAE needed? Message franking, OPAQUE which is fragile
  without cAE, MLS may
    need this because it ensures transcript consistency
  - why do we need an RFC? Fewer mistakes and better designs. Lots of knobs to
  tweak, need
    guidance on threat models, requirements, use cases.

Q: Stanislav -- thanks for good overview of problem, committing schemes are
addressing one of
   main pitfals, good to have this advance

Q: PHB -- very helpful, want to see it go forward. Good way of seeing if keys
derived are
   "solid"

-----------------------------------------

Mult-for-7748 -- Richard Barnes

  - multiplication is hard. Sometimes nice to multiply both the public and
  private keypairs
    of an elliptic curve to get a new point
  - commutivity is not true for x448
  - high order bit is set, "clamped". We can create a mult operation that can
  take whichever
    is clamped, x or n-x
  - for some x, neither x nor n-x is clamped and then the operation fails, it's
  rare but
    it happens. Private key holder can detect this failure but public key
    holder can't.
  - Questions: is there interest? Good for CFRG?

Q: Yaron Sheffer -- can this be done with out-of-the-box libraries or will
people have to
   write this all themselves?
A: it's possible to use X25519 libraries as they stand now, yes if you pull out
the private
   key. One benefit of doing and RFC is it will get into the libraries without
   having to reach inside.

-----------------------------------------

End of meeting!