CFRG Meeting at IETF 110 Date: Friday, March 12, 2021 Time: 12:00-14:00 UTC (or 13:00-15:00 UTC+1) Meetecho: https://meetings.conf.meetecho.com/ietf110/?group=cfrg&short=&item=1 Jabber: cfrg@jabber.ietf.org Notes: https://codimd.ietf.org/notes-ietf-110-cfrg Chairs Alexey Melnikov alexey.melnikov@isode.com Nick Sullivan nick@cloudflare.com Stanislav Smyshlyaev smyshsv@gmail.com Scribe Alexey Melnikov MINUTES Colin Perkins (CP): For Argon2 can the chairs confirm that the change is satisfactory? Alexey Melnikov (AM): Haven’t had a chance to look yet. KangarooTwelve (Giles Van Assche (GVA)) GVA: Work is finished modulo confirmations No questions were asked CPace (Björn Haase (BH)) Stanislav Smyshlyaev (SS): Have you thought about the problems with integration with other protocols, given the precommunication steps? BH: In apps where the identites are established beforehand you can integrate the identity into the channel identifier. If the identity is only established as part of protocol, you can’t easily integrate that at the beginning, but you can insert the identities into the final key confirmaiton round. Not a real problem as it will be authenticated as part of the transcript in the higher level construct. Armando Faz (AF) : What is the issue with cofactor clearing in the H2C draft? BH: The advantage is when you clear the cofacttor you will receive the result in affine coords. When you multiply by cofactor, it returns results in projective coordinates. You have an extra step to transform them into affine. AF: All operations can be done in projective coordinates. Also they are easy, it’s x4 or x8. WL: If another EC is defined, do you need to redefine CPace or is it obvious what to do? BH: The news is that all constructions are secure. Ristretto doesn’t match the H2C draft. WL: You can commute the isogeny in elligator and the multiplication if you really care. OPAQUE (Chris Wood (CAW)) Richard Barnes (RB): Is somebody interested in using external keys? Chris Wood (CAW): Might be useful for future use cases where the key derivation is unclear. RB: Could we add this flexibility in the future? CAW: Details are subtle enough that we were worried that if not dealt with now it might not be clear how to do it in future. SS: Regarding client enumeration - Could you elaborate on option 2? Do the changes have an effect on the security proofs? CAW: The changes do not affect the security proofs, confirmed by Jurgen. It’s an application level attack. VOPRFs (Armando Faz (AF)) No questions were asked RSA blind signatures (Chris Wood) Kirsty Paine: This solves a PrivacyPass (PP) Charter item, have you spoken to the PP group about this? Do they like this solution? Is it one amongst many? CAW: No clear consensus on the PP mailing list. Ben Schwartz (BS): PP cchair, there is +ve interest, the mentioned thread mostly focussed on BLS signatures, but there was potential interest. Tommy Pauly (TP): The charter is not meant to select a particular algorithm, it’s supposed to have some level of crypto agility, so PP is unlikely to exclude any sort of suitable algorithm. CAW: When working on the PP spec we’re trying to make sure that PP can take any underlying primitive. TP: Blind sigs is def. something Apple is interested in, in terms of adoption I want to highlight a comment from John Mattsson, if we do this we don’t want to rule out other types of blind signatures. Having something easy to deploy in the suite would be a good first step. CAW: This is very similar to things that are deployed in production now, and it seems safe. BS: The VOPRF draft here defines an abstract API, do you see Blind Signatures having the same API? CAW: The intent was for it to have the same shape as the VOPRF API, but I’m hesitant to fold it in, because it has different semantics. We might decide which we use at the PP layer, and call into one of these. BS: PP shouldn’t be calling into Blind RSA specifically. CAW: We haven’t had a chance in PP yet to call into different crypto primitives WL: VOPRFs and Blind Signatures have different semantics so we shouldn’t merge them. Frederic Jacobs (FJ): We don’t want to generalise the contsruction too quickly either, some of the other options require multi-step issueance etc. so we should wait until we have some more understanding of exactly what API requirements will be. FROST (Chelsea Komolo (CK)) Phillip Hallam-Baker (PHB): Please also consider the case where you have a crypto co-processor and you want an application to delegate a partial signature to the co-processor and bind the operation to the CPU. CK: Are you advocating for the DKG model then? PHB: Yes, the key generation will be distributed, but doesn’t need to be distributed with Shamir secret sharing. Just needs to bind an implementation to a specific device. RB: The DKG is pretty separable, can we simplify this draft by not including the DKG at all? CK: It’s def. not a requirement, and I think the DKG should be in its own realm. Key committing AEAD (Julia Len (JL)) SS: What do you want to standardise? Can you create a key committing AEAD from another non key committing, but otherwise strong AEAD? JL: Yes RB: Short-term: Encrypt-then-HMAC, see the work in SFRAME, Long-term: Explore the design space. Martin Thomson (MT): The two options zero pad and the hash key check have fixed overheads and you have to do a hash key check, can you have a 32 byte input, or does it need to be 64 bytes? JL: You don’t need that many bytes, that’s just what ChaCha uses. BS: This is for low-entropy key spaces, it would be good for the CFRG to describe the minimum entropy necessary for use with AEADs. VOPRF with public metadata (Chris Wood) FJ: Is it possible to abstract the Key Augmentation mechanism outside of VOPRF, maybe we can use the same mechanism to construct a blind signature based on ECs. CAW: Yes, because the key derivation is not specific to the OPRF at all. AOB PHB: W.r.t. threshold encryption, I sent in a draft and it hasn’t had a call for adoption in over a year. SS: It was discussed on the list. NS: We discussed the topic, but we haven’t got to threshold encryption. PHB: When is that likely to happen? NS: I think the reason we didn’t rush to a call for adoption was lack of interest. Does anyone else in the RG have interest? (No new entries to the mic line.) CAW: Should the RG be collecting standard reference implementations for VOPRFs, and other things? CAW: The Sage implementation shows how to understand the protocol, but cannot be deployed. Should we collect C implementations, etc.? SS: I think we should.