Minutes IETF99: cfrg
minutes-99-cfrg-00

CFRG Minutes
IETF 99 Prague, Czech Republic
July 18, 2017  15:50 - 17:50  Congress Hall I,

Chairs:  Alexey Melnikov and Kenny Paterson

Materials: https://datatracker.ietf.org/meeting/99/session/cfrg
Video: https://www.youtube.com/watch?v=U1eQIEG6YLU
Scribe: Stephen Farrell

15:50 CFRG status update from CFRG chairs
      (5 mins; Kenny Paterson)

15:55 Re-keying Mechanisms for Symmetric Keys
      (10 + 10; Stanislav V. Smyshlyaev)
      https://datatracker.ietf.org/doc/draft-irtf-cfrg-re-keying/)

Q&A:

Yoav Nir: what about 3DES? Is it broken or just 64-bit?
SS: not in scope of the draft, which is about ciphers that don't
have any theoretical problems. Personal opinion: 3DES should not be in draft.
YN: what about 32-bit ciphers?
SS: not a problem if cipher has no weakness, just limit on how much data can be
encrypted.

Daniel Franke: I've been jokingly subtitling draft is "make 3DES great again".
Bad life decision to revive 3DES, but this draft a good way to take a cipher
where best attack is generic attack but where bounds are not great and
make them more comfortable.
SS: agree, thanks for reading the draft.

How many have read draft? Maybe 20
Willing to review: Russ Housley + ???

16:15 Verifiable Random Functions
      (10 + 10; Sharon Goldberg)
      https://tools.ietf.org/html/draft-goldbe-vrf-01

Q&A:

Vladimir Smyslov: Performace slow vs. classical PRF ?
SG: yes, you would not want to replace a PRF with a VRF.

Bryan Ford: VRFs are nice, e.g. distributed password protection
with trusted vs. untrusted public key, same as DCAF encoding?
SG: not sure about DCAF, explains draft.
KP: doesn't think one can use DCAF because you need discrete log?
BF: thought it was a way of avoiding co-factor problems.

Geoffrey Eskin: How many bytes in a proof and how fast?
SG: not sure about performance, for 25519 proof is 256+128+256 bits long
(Y,c,s).

KP: Room, should CFRG adopt? Hum.
Hum for adoption: reasonably loud hum.
Hum against adoption: silence in scribe's ears.

16:35 Collective Edwards-Curve Digital Signature Algorithm
      (10 + 10; Bryan Ford)
      https://datatracker.ietf.org/doc/draft-ford-cfrg-cosi/

Q&A:

SF: how would CFRG know that an RFC for this was done
unless there are applications waiting for it?
BF: we are using this for a number of things, would like to hear
from more people, not sure.

PHB: Very interested in this. Wants to split DH keys between TPM and
elsewhere in application - can I do that as easily for
signing?
BF: this isn't a drop-in replacement for Ed25519.
PHB: would like to re-use Ed25519 verify.
BF: could be an open issue to add to the list, could redesign that way.

Richard Barnes: combination here of crypto constructions and protocol
considerations, how mixed are those here? Can they be separated?
BF: crypto part is mostly done via papers from the
literature, protocol part is TBD (in terms of decisions),
CFRG seems like the place where those two skills are
in one room.

Russ Housley: interested (as PHB) in verification code
re-use, but need all of public keys to do verification?
BF: list of public keys needed somewhere but maybe
not at verification function (but related key attacks
mightn't make it easy), m-of-n cases also cause some
variations; back and forth on this with RH, discussion of
dealers, combiners, Shamir sharing, bit masks, set-up trade-offs,
privacy and accountability trade-offs, etc.

Vasily Nickolev: participants need secure connection
with leader, how does that affect performance, is it
still faster than CMS multi-signature?
BF: once you get to 100s-1000s of co-signers, want to avoid all signers
contacting leader; unlikely to be first use case anyway. Can avoid full
complexity in the majority of applications.

AM: Who would review this draft? About 6 people.

16:55 The Transition from Classical to Post-Quantum Cryptography
      (5 + 5; Kenny Paterson for Paul Hoffman)
      https://tools.ietf.org/html/draft-hoffman-c2pq-01

Q&A:

PHB: interested in sizes and performance of options to know
if/when it's practical to do some asymmetric PQ stuff or if
do we need to fall back to Kerberos on a large scale.
KP: not about algorithms, but timescale, so unlikely to have
that in this document.

David McGrew: don't discourage 256 bit AES.
KP: I think it says that already in the draft.

SF: +1 to PHB's desire for input on sizes and
performances as known today for the possible options, sizes more
important, doesn't need to be in same document nor finalised.
KP: NIST competition will flush out concrete proposals with parameters,
and then we should have ballpark/order of magnitude estimates.
SF: good to have that information available, not necessarily in an RFC or soon.

Daryl Piper: a lot of guessing here, not sure what the point is of blessing a
draft that does not suggest a concrete way forward. KP: I'll let Paul respond
to that.

AM: How many are interested in working on this, reviewing it? 7-8 hands in room
+ 2 on jabber. How many say they think it's a waste of time and we shouldn't be
doing it here: none.

17:05 Hash-Based Signatures
      (10 + 5; David McGrew)
      https://datatracker.ietf.org/doc/draft-mcgrew-hash-sigs/
      See also: http://eprint.iacr.org/2017/349.pdf; 
      http://eprint.iacr.org/2017/349.pdf; https://github.com/cisco/hash-sigs

Q&A:

Jeffery Eskin: it would be nice to have sizes of signatures
and keys documented in the specification.
DMcG: good comment.

KP: I'm confused about the figures.
DMcG: last column is the ratio.

SF: in addition to size information, would be good to know the trade-offs,
maybe a presentation at CFRG in future?
DMcG: published code is decent wrt that; it's a long topic, would make sense to
document some of the choices and trade-offs.

Chairs noted request for last call.

17:20 KangarooTwelve
      (10 + 5; Quynh Dang for Beno�t Viguier)
      https://tools.ietf.org/html/draft-viguier-kangarootwelve-00

Q&A:

Kyle Rose: takes 3 inputs, msg, len, string/label? We've argued about
labels before as hash inputs.
QD: I believe it's optional.

KP: what does NIST think of this, in terms of standardising?
QD: not sure about future, but in the past we adopted stuff
from IETF, e.g. HMAC happened, CFRG curves being considered,
so could happen who knows? Kangaroo12 security seems good but perf.
is two times better than SHAKE128 for short messages, and much faster
for long messages. It's one size fits all.

17:35 Two proposals: ECC mod 8^91 + 5 and DH mod 630(427!+1)+1
      (10 + 5; Andrew Allen for Dan Brown)

Q&A:

Scott Fluhrer: what is the co-factor for the curve?
DB: it's 72.

KP: wrt rfc7919, why is this better?
DB: RFC prime has special compact form;
fewer symbols may leave less room for backdoor;
den Boer reduction means CDH security closely related to
DLOG security, not checked details for rfc7919 but expects
proof to break down.

AOB: None.

17:50 Close of CFRG meeting