Minutes IETF104: cfrg
minutes-104-cfrg-00

Minutes of CFRG at IETF104 - 27/3/19
(based on notes taken by Robin Wilton)

Chairs' update:
https://datatracker.ietf.org/doc/slides-104-cfrg-chairs-slides/

Randomness Improvements for Security Protocols
Stanislav V. Smyshlyaev
https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-improvements/
https://datatracker.ietf.org/doc/slides-104-cfrg-randomness-improvements/

-- Plan to have RGLC by May 2019.

BLS Signature Scheme
Hoeteck Wee
https://datatracker.ietf.org/doc/draft-boneh-bls-signature/
https://datatracker.ietf.org/doc/slides-104-cfrg-bls-signatures/

-- Authors request feedback on securing the scheme against rogue public-key
attacks

-- Ben Kaduk: option 1 of those proposed seems the most appropriate/robust; but
more feedback solicited for e.g. group signing. -- Watson Ladd: option 2 won't
work for blockchains. If combining 1 and 3 is "cheap", why not combine them? -
Hoeteck: "3 is not especially cheap".

-- Authors request feedback on which ciphersuites to support
-- Draft at github.com/pairingwg/bls_standard

-- Nick Sullivan: current CFRG draft on hashing to curves should be helpful.
-- Hoeteck Wee: "try-and-increment" isn't well covered in that draft.

-- Christian Grothoff: BLS also makes it possible to "blind" signatures; that's
a use case I'd be interested in.

-- Chair: support in the room for this draft? Good support indicated, will be
taken to the list for adoption call.

Hybrid Public Key Encryption
Richard Barnes
https://tools.ietf.org/html/draft-barnes-cfrg-hpke-00
https://datatracker.ietf.org/doc/slides-104-cfrg-hybrid-pke/

-- Some WGs need something like this already, so there is some time pressure.

-- Stanislav Smyshlaev: support the work and its adoption in CFRG.
-- Eric Rescorla: there are uses for this; be careful about adding lots of
features that might not be needed, over what's already in -00.

-- Chair: what's the security target for a streaming-oriented implementation?
-- Richard Barnes: document defines correct sequencing as the responsibility of
the application -- Karthik Bhargavan: it's more an attempt to specify "repeated
use of the public key component of the KEM key" rather than streaming per se.

-- Chair: support in the room for this draft? Some support indicated, will be
taken to the list for adoption call.

Next Generation Internet
Brook Schofield
https://www.ngi.eu/
https://datatracker.ietf.org/doc/slides-104-cfrg-next-generation-internet-open-calls/

-- Invitation to bid for research/innovation funding in support of NGI.
-- Contact Brook for further information: brook dot schofield at geant dot org

Overview of existing PAKEs and PAKE selection criteria
Stanislav V. Smyshlyaev
https://datatracker.ietf.org/doc/slides-104-cfrg-pake-selection/

-- Example criteria, to be complemented by the RG.

---- Does the algorithm satisfy "balanced" and "augmented" criteria as
appropriate? ---- Is there a formal security proof? Is the proof modular or
holistic? ---- Is the intended usage "stand-alone", or in an IETF protocol?

-- Watson Ladd: applications for specific types of PAKE exist. Wary of IETF's
history of trying to identify "the best" of a number of options.

-- Dan Harkins: PKEX isn't a PAKE and should not be considered further in this
context.

-- Chris North: is this selection process independent of the further
development of any of the specific PAKE options mentioned? -- Chair: some
predate the selection process, which makes it hard to discontinue work on them,
but the goal is to narrow down the list of options.

-- Hannes Tschoefenig: fair to say PAKEs haven't been successful in adoption up
to now, but IoT deployment creates some potential use cases.

-- Guilin Wang: is the schedule tight or relaxed?
-- Chairs: we want to avoid an exercise as energy-sapping as was the case for
ECC.

-- Yoav Nir: IPSEC community definitely interested in PAKE-based mechanisms for
logging in to VPN with a password.

-- Paul Wouters: IKE working group has already discussed, and their use case
requires augmented PAKE.

-- Joe Salowey: TLS group has had presentations on PAKE, but don't have
compelling requirements to date.

-- Ben Kaduk: KITTEN WG adopted SPAKE for its low message count, balanced PAKE
in order to coexist with other mechanisms already in use. Draft submitted for
publication.

-- Valery Smyslov: there's already an RFC6467 defining a framework for
integrating PAKEs with IKE2.

-- Chairs: we will convene to define next steps for the PAKE selection process.