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.