IETF 117 in San Francisco
Tuesday July 25, 2023, 15:00-16:30 (UTC - 7)
Meetecho:
https://meetings.conf.meetecho.com/ietf117/?group=cfrg&short=&item=1
Jabber: cfrg@jabber.ietf.org
Notes: https://notes.ietf.org/notes-ietf-117-cfrg
Chairs: Stanislav Smyshlyaev (SS), Nick Sullivan (NS), and Alexey
Melnikov (AM)
Note-taker: Joseph Salowey (JS), Jonathan Hoyland (JH)
AM speaking
Document has been reviewed positively on the the list. Continuing work
on the list.
Christopher Patton (CP) - Document is awesome. Important to make the
document self-consistent.
Jonathan Hoyland (JGH) - differences between ASCII and PDF with respect
to non special symbols
Paul Hoffman (PH) - this is a work in progress
Phillip Hallam-Baker (PHB) - Would like to use mathematical symbols, but
often disappear during process
Colin Perkins (CP-IRTF) - if the group thinks non-ASCII is important
than we can make it happen.
Chris Wood (CW) - What is the status of the implementations
TL - 3 + ours - we'll make it easier to find (ours isn't open Source
yet)
Watson Ladd (WL) - I think I needed this draft earlier in Privacy Pass,
I think the draft doesn't explain to people what they need to actually
do, also taking a paper from a few months ago and putting it in a spec
is hard to check it's right.
TL - paper is not a new scheme, but variation that improves security
Armando Faz (AF) - You mentioned you changed the KDF, is there a reason
not to use Extendable Output Functions instead of SHA-based?
TL - Originally used extendable output function, however we reorganized
to hash to curve, XOF was only in Key generation.
Vasilis Kalos (VK) - We do have support for XOFs throughout scheme by
using expand_message_xof from the hash-to-curve draft. One of the
ciphersuites is defined using expand_message_xof with SHAKE256.
Presenter not available, available at end of meeting for 1 minute
summary.
IANA has assigned code points and NISTS refers to parameter sets. We
need review.
Bas Westerbaan (BW) - Happy to review the draft. Did you consider
128-bits?
SF - We did consider that. We discussed it with NIST and decided not to
go with that size. If you're going to go with a state based hash
function level one sounds a bit too close. However, if someone comes up
with a draft for it, I am not opposed.
WL - In breaking down the properties how do you talk about things that
might be more robust than others such as one-pass (lose some security
properties)
AB - For us it's an implementation property, and whilst you can have
implementation properties that can be security properties for us this is
an implementation property.
CP - Thank you this is a big space. Paper from Barbosa indifferentiable
authenticated encryption what is your take?
AB - I agree with indifferentiability, it's one of my new favourite
things. I'm going to have to study it because it's a bit new, but it's
in my queue.
CP - It would be cool to see security proofs for indistinguishability.
AB - Indiffirentiability and indistinguishability are related so it
might be ... [possible]
WL - Why aren't you doing something interactive to set up session. HPKE
isn't core to this, are there security implications?
DH - It just seemed like a logical way to address the problem. It could
be addressed at another layer, but I'm not sure what the security
pitfalls of this would be, there's a security proof attached.
CW - Suggest to split into two, compact representation is easy. can get
codepoint without RFC.
DH - How do I get a new KEM assigned and how do I sign it?
CW - Short draft that provides a stable reference. I'm not saying don't
do this, but let's not spend in-person time on stuff that can be done
over email.
CW - On the Ristretto Decaf question - does complexity make the document
longer or does it make the protocol more complex.
BH - I think it might be both. There are people who don't like Decaf and
Ristretto so much that they will complain about anything. Now that I
know Ristretto and Decaf are being used in OPAQUE we should keep them in
the CPace draft.
CW - that would be good to align with OPAQUE drafts, present things in a
consistent way terminology and notation, such as scalar multiplication.
Let's make them consistent
BH - One piece of feedback I had is that we have different perspectives
from different audiences. We might not always have the same
understanding of the reading audience.
CW - I think there are multiple audiences. FIrst there are implementers,
also security researchers. This is already covered by the document.
Implementers should be first priority.
CP - In CPace you don't use the group operation, correct?
BH - In CPace we do not use the group operation.
CP - I don't disagree with CW, consistency is the main thing, but X25519
and X448 would probably be good enough if we don't need the group
operation.
BH - That (X25519 and X448) is what the recommend cipher is. Easy to
implement.
AF - I can volunteer to do a quick revion getting consistency between
CPace and OPAQUE.
BH - I am convinced also OPAQUE could be implemented without group
operations. Didn't have time for focus on that.
AF - That suggestions reduces to making OPRFs in the x-line.
NS - Any perspective on unifying [the notation of] CPace and OPAQUE?
KL - inclined to have th draft read similarly. Not supporting ristretto
would be weird. It seems it would be nice for CPACE to support
Ristretto.
Mike Ounsworth (MO) - Looks similar to Merkle Tree certificates - how
are these different (MTL) vs. MTC. Who gets the benefits on the benefits
slide. What protocols is this best for.
JH - Both the signer and verifier get benefits. You only have to store
one side of the ladder. You only have to store the ladder once and the
signature once.
MO - Is there a tipping point? after how many signatures?
JH - In the paper we discuss how many times you have query vs how many
times cache the ladder.
PHB - I like this stuff, similar to data at rest envelope. Should be
used for distribute software. Adjacent to keytrans, in PQC interested in
two types, I want to validate the code to move to PQC, Nonrepudiation of
signatures for signatures 10 years+. Didn't use because of patent. Worth
interfacing into notay scheme.
JH - Thanks
WL - I'm not sure I got a great idea of what you're doing. You're
signing a root and if you don't have the right signature you get fetch a
newer one?
JH - You can verify a set of messages, if it is outside the original set
then you need a new signature.
WL - There is potentially a privacy concern when the browser is
retrieving something when validating the certificate.
Andrew Fregly (AF) - look at references, we around this week to explain
it.
No questions.