Minutes IETF110: cfrg
||Minutes IETF110: cfrg
CFRG Meeting at IETF 110
Date: Friday, March 12, 2021
Time: 12:00-14:00 UTC (or 13:00-15:00 UTC+1)
Jabber: firstname.lastname@example.org Notes: https://codimd.ietf.org/notes-ietf-110-cfrg
Alexey Melnikov email@example.com
Nick Sullivan firstname.lastname@example.org
Stanislav Smyshlyaev email@example.com
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
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.
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.