[{"author": "Michele Orr\u00f9", "text": "

okok let's just use those.

", "time": "2025-03-17T06:00:15Z"}, {"author": "Alexey Melnikov", "text": "

And thus they are in the Meetecho

", "time": "2025-03-17T06:00:17Z"}, {"author": "Michele Orr\u00f9", "text": "

thanks Alexey.

", "time": "2025-03-17T06:00:18Z"}, {"author": "Valery Smyslov", "text": "

Hi, I'll be a jabber scribe for the session. If you want to relay your comment to the mic, please prepend it with MIC:

", "time": "2025-03-17T06:01:59Z"}, {"author": "Stephen Farrell", "text": "

\"pain point\": CFRG doing stuff that should've moved over to IETF (e.g. HPKE maintenance); doesn't seem to be on that list

", "time": "2025-03-17T06:07:05Z"}, {"author": "Stephen Farrell", "text": "

is now the place to comment on that?

", "time": "2025-03-17T06:07:52Z"}, {"author": "Alexey Melnikov", "text": "

Stephen: we don't really have a good process for this and this doesn't happen very often. But yes, worth thinking about

", "time": "2025-03-17T06:07:57Z"}, {"author": "Mike Ounsworth", "text": "

(hello from the RATS room)

", "time": "2025-03-17T06:08:00Z"}, {"author": "Stephen Farrell", "text": "

@alexey: s/thinking about/doing something about/ I'd say

", "time": "2025-03-17T06:08:19Z"}, {"author": "Alexey Melnikov", "text": "

Stephen: no time at the moment, bring to the mailing list?

", "time": "2025-03-17T06:08:29Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Updated charter or a FAQ seems like a good idea.

", "time": "2025-03-17T06:08:46Z"}, {"author": "Alexey Melnikov", "text": "

Stephen: Fair enough

", "time": "2025-03-17T06:08:59Z"}, {"author": "Bas Westerbaan", "text": "

Recharter or a new CFWG sounds great.

", "time": "2025-03-17T06:09:07Z"}, {"author": "Stephen Farrell", "text": "

updated charter that moves some relevant maintenance work to IETF: yes; updated charter that doesn't do that: meh

", "time": "2025-03-17T06:09:34Z"}, {"author": "Mike Ounsworth", "text": "

Stephen Farrell said:

\n
\n

\"pain point\": CFRG doing stuff that should've moved over to IETF (e.g. HPKE maintenance); doesn't seem to be on that list

\n
\n

@Deirdre Connolly will be bringing this up later today at PQUIP, right?
\nhttps://datatracker.ietf.org/doc/slides-122-pquip-ietf-is-quantum-fragile/

", "time": "2025-03-17T06:10:07Z"}, {"author": "Stephen Farrell", "text": "

I don't think the issue is PQ specific at all

", "time": "2025-03-17T06:11:10Z"}, {"author": "Mike Ounsworth", "text": "

CFME WG -- Crypto Forum Maintenance WG?

", "time": "2025-03-17T06:11:22Z"}, {"author": "Deirdre Connolly", "text": "

It isn't, but it's especially painful for the PQ transition

", "time": "2025-03-17T06:11:26Z"}, {"author": "Martin Thomson", "text": "

I don't like the CFWG idea very much. The IETF has clear processes for handling new work, which is not centered on technology, but use cases and solutions.

", "time": "2025-03-17T06:11:42Z"}, {"author": "Stephen Farrell", "text": "

CFME: doesn't sound goo

", "time": "2025-03-17T06:11:52Z"}, {"author": "Martin Thomson", "text": "

If the IETF wants to do some crypto work, then it can charter working groups to do specific things.

", "time": "2025-03-17T06:11:58Z"}, {"author": "Stephen Farrell", "text": "

s/goo/good/

", "time": "2025-03-17T06:12:00Z"}, {"author": "Martin Thomson", "text": "

For instance, HPKE should have been done in the IETF. It's engineering.

", "time": "2025-03-17T06:12:10Z"}, {"author": "Martin Thomson", "text": "

Similarly KEM combiners work is engineering, not research.

", "time": "2025-03-17T06:12:23Z"}, {"author": "Deirdre Connolly", "text": "

Shall we have a working group for all the crypto engineering specification work CFRG says it doesn't do?

", "time": "2025-03-17T06:12:30Z"}, {"author": "Stephen Farrell", "text": "

@mt: don't quite agree, initial work in CFRG makes sense but needs to be handed off

", "time": "2025-03-17T06:12:49Z"}, {"author": "Martin Thomson", "text": "

I don't think we need a single place.

", "time": "2025-03-17T06:12:53Z"}, {"author": "Stephen Farrell", "text": "

HPKE is used by TLS & MLS, one of 'em should do maintenance

", "time": "2025-03-17T06:13:18Z"}, {"author": "Bas Westerbaan", "text": "
\n

For instance, HPKE should have been done in the IETF. It's engineering.
\nSimilarly KEM combiners work is engineering, not research.

\n
\n

Where would you pyt these two today at the IETF?

", "time": "2025-03-17T06:13:19Z"}, {"author": "Martin Thomson", "text": "

The CFRG can help bootstrap stuff, but when it is clearly engineering, there needs to be a clean path to handover.

", "time": "2025-03-17T06:13:20Z"}, {"author": "Richard Barnes", "text": "

diagram not to scale

", "time": "2025-03-17T06:13:32Z"}, {"author": "Mike Ounsworth", "text": "

Yeah, we're literally talking about a \"CF Maintenance\" WG that CFRG can hand off \"completed\" work to.

", "time": "2025-03-17T06:13:57Z"}, {"author": "Martin Thomson", "text": "

@Bas well, HPKE might be a small WG; KEM combiners is not a single thing...TLS is already solving this, as is MLS

", "time": "2025-03-17T06:14:03Z"}, {"author": "Deirdre Connolly", "text": "

Unfortunately there is crypto engineering stuff that CFRG doesn't do, and doesn't require a full working group to live either temporarily or indefinitely

", "time": "2025-03-17T06:14:14Z"}, {"author": "Stephen Farrell", "text": "

@mike o: no I would not want that

", "time": "2025-03-17T06:14:20Z"}, {"author": "Daniel Gillmor", "text": "

OpenPGP is doing KEM combiners too

", "time": "2025-03-17T06:14:27Z"}, {"author": "Stephen Farrell", "text": "

we have survived without a PAKE WG for decades, and happily

", "time": "2025-03-17T06:14:53Z"}, {"author": "Deirdre Connolly", "text": "

So, there are many working groups doing cryptography

", "time": "2025-03-17T06:14:53Z"}, {"author": "Martin Thomson", "text": "

dkg: yes, and so are many others, but we have clear signals that a single solution isn't going to work

", "time": "2025-03-17T06:14:55Z"}, {"author": "Martin Thomson", "text": "

each of these groups needs to coordinate (we don't want to duplicate effort) but they don't need a single mechanism

", "time": "2025-03-17T06:15:12Z"}, {"author": "Deirdre Connolly", "text": "

Stephen Farrell said:

\n
\n

we have survived without a PAKE WG for decades, and happily

\n
\n

This is not a positive endorsement

", "time": "2025-03-17T06:15:14Z"}, {"author": "Bas Westerbaan", "text": "

@MT TLS does what works for TLS. Same for many other groups, and the outcomes are not ideal.

", "time": "2025-03-17T06:15:18Z"}, {"author": "Martin Thomson", "text": "

@bas that's a result of divergent requirements or lack of coordination. The former being a good reason to have separate solutions; the latter, less so.

", "time": "2025-03-17T06:16:05Z"}, {"author": "Stephen Farrell", "text": "

if we had a crypto maintenance WG in IETF it would be as good/bad as CFRG thanks to involving the same peopel

", "time": "2025-03-17T06:16:06Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

@bas that's a result of divergent requirements or lack of coordination. The former being a good reason to have separate solutions; the latter, less so.

\n
\n

It's very clear that TLS can do things that other protocols using cryptography cannot do

", "time": "2025-03-17T06:16:30Z"}, {"author": "Richard Barnes", "text": "

KEM combiners, so hot right now

", "time": "2025-03-17T06:16:31Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Martin Thomson said:

\n
\n

@bas that's a result of divergent requirements or lack of coordination. The former being a good reason to have separate solutions; the latter, less so.

\n
\n

It's very clear that TLS can do things that other protocols using cryptography cannot do

\n
\n

This is not a failure of coordination

", "time": "2025-03-17T06:16:41Z"}, {"author": "Deirdre Connolly", "text": "

Stephen Farrell said:

\n
\n

if we had a crypto maintenance WG in IETF it would be as good/bad as CFRG thanks to involving the same peopel

\n
\n

Disagree

", "time": "2025-03-17T06:16:50Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Deirdre Connolly said:

\n
\n

Martin Thomson said:

\n
\n

@bas that's a result of divergent requirements or lack of coordination. The former being a good reason to have separate solutions; the latter, less so.

\n
\n

It's very clear that TLS can do things that other protocols using cryptography cannot do

\n
\n

This is not a failure of coordination

\n
\n

Different goals, different charter

", "time": "2025-03-17T06:16:58Z"}, {"author": "Stephen Farrell", "text": "

disagreement is fine, TLS is also just another WG:-)

", "time": "2025-03-17T06:17:09Z"}, {"author": "Martin Thomson", "text": "

$X being special is true of all values of $X

", "time": "2025-03-17T06:17:15Z"}, {"author": "Bas Westerbaan", "text": "

Argon 2 is funny, as it's just writing down a standard of something that was invented elsewhere.

", "time": "2025-03-17T06:17:40Z"}, {"author": "Deirdre Connolly", "text": "

I'm not saying TLS is special, i'm saying different cryptographic protocols having different solutions that meet their needs is not a failure mode

", "time": "2025-03-17T06:17:44Z"}, {"author": "Richard Barnes", "text": "

TLS could clearly use a combiner that was applicable more broadly. The fact that it's not does seem like a failure.

", "time": "2025-03-17T06:17:45Z"}, {"author": "Deirdre Connolly", "text": "

Richard Barnes said:

\n
\n

TLS could clearly use a combiner that was applicable more broadly. The fact that it's not does seem like a failure.

\n
\n

Could, but would be less efficient for no security benefit

", "time": "2025-03-17T06:18:05Z"}, {"author": "Richard Barnes", "text": "

Security is not the only type of benefit that matters

", "time": "2025-03-17T06:18:22Z"}, {"author": "Christopher Wood", "text": "

@Richard FWIW, there was opposition to TLS using, e.g., X-Wing for its combiner

", "time": "2025-03-17T06:18:22Z"}, {"author": "Stephen Farrell", "text": "

there is a real tension there: people wanna go faster, other people want more analysis

", "time": "2025-03-17T06:18:24Z"}, {"author": "Martin Thomson", "text": "

I don't see a particular problem with how this has turned out in TLS.

", "time": "2025-03-17T06:18:27Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

Richard Barnes said:

\n
\n

TLS could clearly use a combiner that was applicable more broadly. The fact that it's not does seem like a failure.

\n
\n

Could, but would be less efficient for no security benefit

\n
\n

it is able to be both simpler, more efficient, easier to analyze, because of the exiting design of TLS 1.3 key schedule. This is not a failure case.

", "time": "2025-03-17T06:18:32Z"}, {"author": "Daniel Gillmor", "text": "

Bas, Argon 2 was also useful because the standard has many options; the spec was useful for guidance among the options.

", "time": "2025-03-17T06:18:32Z"}, {"author": "Martin Thomson", "text": "

dkg: that's engineering!

", "time": "2025-03-17T06:18:44Z"}, {"author": "Bas Westerbaan", "text": "

@Daniel, I don't disagree Argon is usefulm but it's against what the chairs just said the CFRG should be doing

", "time": "2025-03-17T06:18:59Z"}, {"author": "Stephen Farrell", "text": "

\"has many options\": the canonical fail of crypgraphers

", "time": "2025-03-17T06:19:01Z"}, {"author": "Daniel Gillmor", "text": "

+1 Stephen

", "time": "2025-03-17T06:19:12Z"}, {"author": "Daniel Gillmor", "text": "

\"i can't decide what to do here, so i'll leave it up to the even more ignorant consumers of my work\"

", "time": "2025-03-17T06:19:34Z"}, {"author": "Martin Thomson", "text": "

cryptographers want the most general solution, which is not very useful in practice

", "time": "2025-03-17T06:19:40Z"}, {"author": "Christopher Wood", "text": "

There are many examples that contradict the process described here on the slides :shrug:

", "time": "2025-03-17T06:19:49Z"}, {"author": "Bas Westerbaan", "text": "

100%

", "time": "2025-03-17T06:20:00Z"}, {"author": "Richard Barnes", "text": "

yeah, pretty sure nothing about the HPKE process matches this description

", "time": "2025-03-17T06:20:07Z"}, {"author": "Stephen Farrell", "text": "

for example?

", "time": "2025-03-17T06:20:08Z"}, {"author": "Richard Barnes", "text": "

(for example)

", "time": "2025-03-17T06:20:10Z"}, {"author": "Christopher Wood", "text": "

HPKE, VOPRF, Blind RSA, VDAF, BBS, ...

", "time": "2025-03-17T06:20:21Z"}, {"author": "Bas Westerbaan", "text": "

KEM combiners

", "time": "2025-03-17T06:20:27Z"}, {"author": "Stephen Farrell", "text": "

for HPKE much of the \"what do we want\" phase was in TLS yeah

", "time": "2025-03-17T06:20:43Z"}, {"author": "Deirdre Connolly", "text": "

Maybe FROST (i wasn't paying much attention before the chairs approached the FROST authors)

", "time": "2025-03-17T06:20:44Z"}, {"author": "Christopher Wood", "text": "

FROST is another example

", "time": "2025-03-17T06:20:52Z"}, {"author": "Deirdre Connolly", "text": "

:smiling_face_with_tear: 'pls read document'

", "time": "2025-03-17T06:21:46Z"}, {"author": "Deirdre Connolly", "text": "

:sob:
\nimage.png

\n
", "time": "2025-03-17T06:23:56Z"}, {"author": "Stephen Farrell", "text": "

\"velocity of the draft\" seems wrong aren't there 2?

", "time": "2025-03-17T06:24:08Z"}, {"author": "Deirdre Connolly", "text": "

Stephen Farrell said:

\n
\n

\"velocity of the draft\" seems wrong aren't there 2?

\n
\n

Currently one, the group voiced wanting two, it will be split easily

", "time": "2025-03-17T06:24:41Z"}, {"author": "Stephen Farrell", "text": "

OTOH velocity == no is pretty obvious:-)

", "time": "2025-03-17T06:24:51Z"}, {"author": "Jonathan Hoyland", "text": "

Amusing that the people who think it's going too slowly answer faster

", "time": "2025-03-17T06:25:27Z"}, {"author": "Christopher Wood", "text": "

I have contributed text and will continue to do so

", "time": "2025-03-17T06:25:28Z"}, {"author": "Daniel Gillmor", "text": "

this was the most elaborate setup i've ever seen for encouraging people to volunteer

", "time": "2025-03-17T06:25:29Z"}, {"author": "Stephen Farrell", "text": "

there was no mention of x-wing so far right?

", "time": "2025-03-17T06:26:34Z"}, {"author": "Deirdre Connolly", "text": "

No, X-Wing is a separate document

", "time": "2025-03-17T06:27:03Z"}, {"author": "Stephen Farrell", "text": "

but part of this story

", "time": "2025-03-17T06:27:17Z"}, {"author": "Stephen Farrell", "text": "

ah there we go

", "time": "2025-03-17T06:27:25Z"}, {"author": "Bas Westerbaan", "text": "

No, CFRG doesn't want it

", "time": "2025-03-17T06:27:26Z"}, {"author": "Deirdre Connolly", "text": "

The cfrg document specifies a P-256 concrete instance that is basically X-Wing with P-256 instead

", "time": "2025-03-17T06:27:28Z"}, {"author": "Stephen Farrell", "text": "

who was it wants x-wing in such a hurry btw?

", "time": "2025-03-17T06:27:49Z"}, {"author": "Martin Thomson", "text": "

A generic document is fine, because it sets out the guiderails.

", "time": "2025-03-17T06:27:59Z"}, {"author": "Martin Thomson", "text": "

An HPKE codepoint is already allocated. We're done.

", "time": "2025-03-17T06:28:12Z"}, {"author": "Richard Barnes", "text": "

@Stephen for example, this whole debate is blocking PQ in MLS right now

", "time": "2025-03-17T06:28:14Z"}, {"author": "Richard Barnes", "text": "

because we don't want to do a TLS-style bespoke thing

", "time": "2025-03-17T06:28:23Z"}, {"author": "Martin Thomson", "text": "

A specific draft that says KitchenSick or whatever isn't helpful.

", "time": "2025-03-17T06:28:37Z"}, {"author": "Stephen Farrell", "text": "

so \"we're done\" and \"we're stuck\" both?

", "time": "2025-03-17T06:28:44Z"}, {"author": "Thom Wiggers", "text": "

twelve diverging ways of doing hybrids would be bad

", "time": "2025-03-17T06:28:46Z"}, {"author": "Deirdre Connolly", "text": "

@Richard Barnes more like can't, because HPKE, which uses registered KEMs

", "time": "2025-03-17T06:28:48Z"}, {"author": "Deirdre Connolly", "text": "

Thom Wiggers said:

\n
\n

twelve diverging ways of doing hybrids would be bad

\n
\n

\"i hate to inform you\"

", "time": "2025-03-17T06:28:57Z"}, {"author": "Mike Ounsworth", "text": "

Richard Barnes said:

\n
\n

@Stephen for example, this whole debate is blocking PQ in MLS right now

\n
\n

For example, this whole debate is NOT blocking PQ in LAMPS, IPSEC, OpenPGP because we can't wait.

", "time": "2025-03-17T06:28:59Z"}, {"author": "Martin Thomson", "text": "

X-Wing being a draft is a massive failure. If the market has voted on X-Wing, we should standardize that. It should not go to ISE.

", "time": "2025-03-17T06:29:42Z"}, {"author": "Stephen Farrell", "text": "

LAMPS is not exactly the model IETF WG IMO:-)

", "time": "2025-03-17T06:29:46Z"}, {"author": "Richard Barnes", "text": "

i guess MLS is the only one trying to do things properly here :)

", "time": "2025-03-17T06:29:55Z"}, {"author": "Christopher Wood", "text": "

To clarify what I said at the mic: we need HPKE code points. That is the only thing that matters.

", "time": "2025-03-17T06:30:00Z"}, {"author": "Martin Thomson", "text": "

MLS has a working group

", "time": "2025-03-17T06:30:03Z"}, {"author": "Christopher Wood", "text": "

(To me)

", "time": "2025-03-17T06:30:05Z"}, {"author": "Martin Thomson", "text": "

Chris, same here.

", "time": "2025-03-17T06:30:14Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

X-Wing being a draft is a massive failure. If the market has voted on X-Wing, we should standardize that. It should not go to ISE.

\n
\n

Hence what about a CEWG (crypto engineering working group)

", "time": "2025-03-17T06:30:16Z"}, {"author": "Stephen Farrell", "text": "

x-wing has a codepoint; not sure the spec if 100% done though (it may be haven't looked in a while)

", "time": "2025-03-17T06:30:28Z"}, {"author": "Christopher Wood", "text": "

X-Wing is stable at this point

", "time": "2025-03-17T06:30:40Z"}, {"author": "Thom Wiggers", "text": "

Deirdre Connolly said:

\n
\n

Martin Thomson said:

\n
\n

X-Wing being a draft is a massive failure. If the market has voted on X-Wing, we should standardize that. It should not go to ISE.

\n
\n

Hence what about a CEWG (crypto engineering working group)

\n
\n

we could finally stop pretending that HPKE is not a standard

", "time": "2025-03-17T06:30:43Z"}, {"author": "Bas Westerbaan", "text": "

@Stephen Please have a look, I think it's mostly done.

", "time": "2025-03-17T06:30:46Z"}, {"author": "Raphael Robert", "text": "

Martin Thomson said:

\n
\n

MLS has a working group

\n
\n

MLS cares about interop more than other WGs maybe

", "time": "2025-03-17T06:30:54Z"}, {"author": "Martin Thomson", "text": "

X-Wing might be a reasonable case for AD sponsorship, through the IETF rather than this group, which seems incapable of agreeing on anything

", "time": "2025-03-17T06:30:55Z"}, {"author": "Stephen Farrell", "text": "

@chris: \"is stable\" doesn't mean the text is done

", "time": "2025-03-17T06:31:01Z"}, {"author": "Richard Barnes", "text": "

i have literally gotten several emails asking when we're going to make HPKE a standard

", "time": "2025-03-17T06:31:07Z"}, {"author": "Christopher Wood", "text": "

@Stephen, sure, but for the purposes of interop, it's sufficient.

", "time": "2025-03-17T06:31:24Z"}, {"author": "Martin Thomson", "text": "

Maybe we can make a new HPKE-Rubberstamp Working Group.

", "time": "2025-03-17T06:31:36Z"}, {"author": "Christopher Wood", "text": "

TBH, a working group to maintain HPKE is not a bad idea. It could incorporate Deirdre's suggestions for \"HPKEv2\", for example, in addition to dealing with matters such as algorithm codepoints

", "time": "2025-03-17T06:32:08Z"}, {"author": "Martin Thomson", "text": "

Two tasks: Move HPKE to standards track; define PQ-Hybrid KEMs

", "time": "2025-03-17T06:32:08Z"}, {"author": "Stephen Farrell", "text": "

\"it's sufficient\" vs an RFC is a thing on which many of us disagree variously

", "time": "2025-03-17T06:32:14Z"}, {"author": "Richard Barnes", "text": "

So wait, what was the outcome of that last session?

", "time": "2025-03-17T06:32:28Z"}, {"author": "Martin Thomson", "text": "

The work left on HPKE is 100% IETF work at this stage.

", "time": "2025-03-17T06:32:30Z"}, {"author": "Christopher Wood", "text": "

:shrug:

", "time": "2025-03-17T06:32:34Z"}, {"author": "Stephen Farrell", "text": "

HPKE doesn't need a WG: TLS and MLS could do what's needed but yes it shouldn't be CFRG

", "time": "2025-03-17T06:32:52Z"}, {"author": "Christopher Wood", "text": "

@Martin, shall we work on a charter for HPKEWG?

", "time": "2025-03-17T06:32:58Z"}, {"author": "Martin Thomson", "text": "

Chris, yes, let's

", "time": "2025-03-17T06:33:11Z"}, {"author": "Christopher Wood", "text": "

Great :+1:

", "time": "2025-03-17T06:33:18Z"}, {"author": "Richard Barnes", "text": "

@martin don't totally agree that HPKE is just engineering. As Dierdre's HPKE + ML-KEM work demonstrates, there are some crypto subtleties

", "time": "2025-03-17T06:33:24Z"}, {"author": "Alexey Melnikov", "text": "

@Richard: I think \"to be continued\". Lots of input and no clear consensus, IMHO

", "time": "2025-03-17T06:33:25Z"}, {"author": "Mike Ounsworth", "text": "

Also JOSE / COSE uses (or wants to use HPKE). So then do we need to decide which of those 4 WGs canonically owns HPKE?

", "time": "2025-03-17T06:33:37Z"}, {"author": "Deirdre Connolly", "text": "

Also I'll advertise my presentation later today at PQUIP touching on ~all these points: https://datatracker.ietf.org/meeting/122/materials/slides-122-pquip-ietf-is-quantum-fragile-00.pdf

", "time": "2025-03-17T06:33:47Z"}, {"author": "Bas Westerbaan", "text": "

@MT @CAW An HPKE specific PQ hybrid KEM might make choicesthat make it annoying for others to use. For instance by using the DHKEM construction. What label in the context to use, etc.

", "time": "2025-03-17T06:33:55Z"}, {"author": "Stephen Farrell", "text": "

COSE/JOSE do debate that endlessly - is anyone actually using?

", "time": "2025-03-17T06:33:59Z"}, {"author": "Deirdre Connolly", "text": "

d

\n

Richard Barnes said:

\n
\n

@martin don't totally agree that HPKE is just engineering. As Dierdre's HPKE + ML-KEM work demonstrates, there are some crypto subtleties

\n
\n

This is not HPKE, though, HPKE just 'needs a KEM', beyond that abstraction is cryptography engineering about KEMs

", "time": "2025-03-17T06:34:21Z"}, {"author": "Mike Ounsworth", "text": "

Stephen Farrell said:

\n
\n

COSE/JOSE do debate that endlessly - is anyone actually using?

\n
\n

Umm, yes. JWT is the most common bearer token format on the internet.

", "time": "2025-03-17T06:34:30Z"}, {"author": "Stephen Farrell", "text": "

I asked about using HPKE, so if that wasn't clear

", "time": "2025-03-17T06:34:52Z"}, {"author": "Stephen Farrell", "text": "

s/so/sorry/

", "time": "2025-03-17T06:34:59Z"}, {"author": "Mike Ounsworth", "text": "

Well, I don't think HPKE-in-JWT/CWT has actually been published yet, right? It's being floated as the easiest path to getting ML-KEM into JOSE/COSE, right?

", "time": "2025-03-17T06:35:42Z"}, {"author": "Deirdre Connolly", "text": "

Deirdre Connolly said:

\n
\n

d

\n

Richard Barnes said:

\n
\n

@martin don't totally agree that HPKE is just engineering. As Dierdre's HPKE + ML-KEM work demonstrates, there are some crypto subtleties

\n
\n

This is not HPKE, though, HPKE just 'needs a KEM', beyond that abstraction is cryptography engineering about KEMs

\n
\n

Although my previous investigations about the previous security assumptions based on DHKEM when trying to replace that with ML-KEM may agree with you, there are cryptographic subleties when keeping up with the latest research etc

", "time": "2025-03-17T06:35:43Z"}, {"author": "Stephen Farrell", "text": "

\"being floated\" - I bailed on the discussion after the 2nd thousand messages:-)

", "time": "2025-03-17T06:36:36Z"}, {"author": "Thom Wiggers", "text": "

I'm very ready for Deirdre's announced PQUIP rant :fire:

", "time": "2025-03-17T06:37:27Z"}, {"author": "Stephen Farrell", "text": "

where do we do the \"too much PQ too soon\" rant?

", "time": "2025-03-17T06:37:52Z"}, {"author": "Mike Ounsworth", "text": "

Stephen Farrell said:

\n
\n

where do we do the \"too much PQ too soon\" rant?

\n
\n

PQUIP is probably the right forum. PQUIP 123?

", "time": "2025-03-17T06:38:16Z"}, {"author": "Deirdre Connolly", "text": "

Stephen Farrell said:

\n
\n

where do we do the \"too much PQ too soon\" rant?

\n
\n

outside yelling at the clouds

", "time": "2025-03-17T06:38:29Z"}, {"author": "Daniel Gillmor", "text": "

PQUIP 123 would be \"too much PQ too soon\" too late

", "time": "2025-03-17T06:38:39Z"}, {"author": "Stephen Farrell", "text": "

yelling at clouds would be more productive than composite sigs I suppose;-(

", "time": "2025-03-17T06:39:21Z"}, {"author": "Thom Wiggers", "text": "

Regulatory stuff has happened already, that ship has sailed (though I have an obvious stake here)

", "time": "2025-03-17T06:39:38Z"}, {"author": "Stephen Farrell", "text": "

that ship: the vasa was a ship:-)

", "time": "2025-03-17T06:40:36Z"}, {"author": "Stephen Farrell", "text": "

it did sail for a little bit

", "time": "2025-03-17T06:40:51Z"}, {"author": "Theo de Raadt", "text": "

i sense too much \"perfect is the enemy of good\" slowing things down

", "time": "2025-03-17T06:41:13Z"}, {"author": "Michele Orr\u00f9", "text": "

post-quantum BBS pseudonyms hmmm I do have an AES proof that makes presentations only 80KB :skull:

", "time": "2025-03-17T06:41:26Z"}, {"author": "Nick Sullivan", "text": "

@Chris Wood:

\n

Regarding your statement that HPKE, VOPRF, Blind RSA, VDAF, FROST, etc., don't fit in the diagram for the CFRG. I think those are actually great examples of work that does.

\n

HPKE problem: we don\u2019t know how to do hybrid encryption safely
\nVOPRF problem: we need a safe mechanism for blinded tokens
\nBlind RSA problem: we need a safe mechanism for blinded tokens with public validation
\nVDAF problem: we don\u2019t know how to do private aggregation
\nFROST problem: for this we adopted a topic, how to do threshold signatures, not a solution
\netc.

", "time": "2025-03-17T06:41:29Z"}, {"author": "Deirdre Connolly", "text": "

NIST: image.png

\n
", "time": "2025-03-17T06:42:14Z"}, {"author": "Deirdre Connolly", "text": "

(https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf)

", "time": "2025-03-17T06:42:29Z"}, {"author": "Bas Westerbaan", "text": "
\n

we don\u2019t know how to do hybrid encryption safely

\n
\n

Even if you're correct, you're not making any progress on solving that.

", "time": "2025-03-17T06:42:42Z"}, {"author": "Deirdre Connolly", "text": "

Isn't hash to curve ~done?

", "time": "2025-03-17T06:42:44Z"}, {"author": "Thom Wiggers", "text": "

@Nick Sullivan could this maybe work if CFRG writes a \"spec\" and \"CEWG\" develops the instantiation? That could be either done sequentially or with more interaction between the two...

", "time": "2025-03-17T06:42:46Z"}, {"author": "Stephen Farrell", "text": "

hopefullly NIST won't be deprecated itself before those dates

", "time": "2025-03-17T06:42:48Z"}, {"author": "Thom Wiggers", "text": "

Bas Westerbaan said:

\n
\n
\n

we don\u2019t know how to do hybrid encryption safely

\n
\n

Even if you're correct, you're not making any progress on solving that.

\n
\n

hybrid encryption == key exchange + AES

", "time": "2025-03-17T06:43:02Z"}, {"author": "Deirdre Connolly", "text": "

Stephen Farrell said:

\n
\n

hopefullly NIST won't be deprecated itself before those dates

\n
\n

A non-zero possibility :disappointed:

", "time": "2025-03-17T06:43:22Z"}, {"author": "Christopher Wood", "text": "

@Deirdre hash-to-curve is indeed done

", "time": "2025-03-17T06:43:33Z"}, {"author": "Stephen Farrell", "text": "

CEWG idea == bad idea

", "time": "2025-03-17T06:43:39Z"}, {"author": "Deirdre Connolly", "text": "

Thom Wiggers said:

\n
\n

Bas Westerbaan said:

\n
\n
\n

we don\u2019t know how to do hybrid encryption safely

\n
\n

Even if you're correct, you're not making any progress on solving that.

\n
\n

hybrid encryption == key exchange + AES

\n
\n

isn't HPKE directly addressing this

", "time": "2025-03-17T06:43:40Z"}, {"author": "Thom Wiggers", "text": "

yeah exactly

", "time": "2025-03-17T06:44:05Z"}, {"author": "John Preu\u00df Mattsson", "text": "

At the moment, the NIST crypto team seems more active than ever :heart:

", "time": "2025-03-17T06:44:43Z"}, {"author": "Stephen Farrell", "text": "

also WRT dates/regulation: what were the original UPv6 dates?

", "time": "2025-03-17T06:44:48Z"}, {"author": "Stephen Farrell", "text": "

s/UPv6/IPv6/

", "time": "2025-03-17T06:44:59Z"}, {"author": "Nick Sullivan", "text": "

I agree with Martin that the line between engineering and research can get blurry. We should be careful not to specify engineering specs, but the part of HPKE that reviews the security analysis of the engineering construction is useful work for the CFRG to produce.

", "time": "2025-03-17T06:45:06Z"}, {"author": "Stephen Farrell", "text": "

@nick: TLS and MLS WGs seem capable of asking CFRG when needed if adding new HPKE things

", "time": "2025-03-17T06:45:46Z"}, {"author": "Raphael Robert", "text": "

chairs: the queue is still locked

", "time": "2025-03-17T06:47:24Z"}, {"author": "Nick Sullivan", "text": "

The tricky part is developing the research in tandem with the engineering. It can be done (Privacy Pass, for example, was developed along CFRG work), but it requires strong editors and collaboration.

", "time": "2025-03-17T06:47:28Z"}, {"author": "Deirdre Connolly", "text": "

Nick Sullivan said:

\n
\n

The tricky part is developing the research in tandem with the engineering. It can be done (Privacy Pass, for example, was developed along CFRG work), but it requires strong editors and collaboration.

\n
\n

extremely true

", "time": "2025-03-17T06:48:18Z"}, {"author": "Daniel Gillmor", "text": "

is \"mediator\" just renamed \"attester\" in this slid?

", "time": "2025-03-17T06:48:48Z"}, {"author": "Valery Smyslov", "text": "

@Daniel Gilmor: do you want this question be relayed to the mic?

", "time": "2025-03-17T06:50:12Z"}, {"author": "Nick Sullivan", "text": "

Thank you, Richard, for volunteering to help with the editing of the KEM Combiners work. Let's make sure that this is included in the notes :)

", "time": "2025-03-17T06:50:18Z"}, {"author": "Daniel Gillmor", "text": "

nah, it's ok

", "time": "2025-03-17T06:50:20Z"}, {"author": "Deirdre Connolly", "text": "

Yes thank you @Richard Barnes :pray: single editor collapses in a sweaty heap

", "time": "2025-03-17T06:51:14Z"}, {"author": "Nick Sullivan", "text": "

@stephen: yes, the CFRG, and the Crypto Panel in particular, is capable of providing the security considerations and references of WG docs that define code points

", "time": "2025-03-17T06:51:40Z"}, {"author": "Deirdre Connolly", "text": "

Nick Sullivan said:

\n
\n

@stephen: yes, the CFRG, and the Crypto Panel in particular, is capable of providing the security considerations and references of WG docs that define code points

\n
\n

hmm, do we have instances of how long this feedback cycle takes in the median case? (honestly curious)

", "time": "2025-03-17T06:52:29Z"}, {"author": "Stephen Farrell", "text": "

@nick: not sure what comment you're referring to there (I guess you're catching up)

", "time": "2025-03-17T06:52:38Z"}, {"author": "Nick Sullivan", "text": "

And for the notes again, Rohan Mahy volunteered to help with the writing of the KEM combiner documents.

", "time": "2025-03-17T06:53:07Z"}, {"author": "Michele Orr\u00f9", "text": "

MIC: thank you for your hard work.

\n

I checked the spec, and am concerned about the core scheme and anonymity.

\n

The core scheme is not CMZ. Where is the formal analysis of this different scheme?

\n

Concerning anonymity, it does not seem to satisfy the canonical definition of anonymity. What security definition do you satisfy?

\n

Would you be amenable to leaning to a proven construction?

", "time": "2025-03-17T06:53:15Z"}, {"author": "Deirdre Connolly", "text": "

@Michele Orr\u00f9 can you join the question queue? good to raise

", "time": "2025-03-17T06:53:55Z"}, {"author": "Stephen Farrell", "text": "

FWIW I don't think MLS or TLS WGs need crypto-panel review for at least some HPKE code-point allocations and if what they're doing is controlversial (and needs more review) people will ask for that I'd say

", "time": "2025-03-17T06:54:05Z"}, {"author": "Valery Smyslov", "text": "

I will relay this question

", "time": "2025-03-17T06:54:14Z"}, {"author": "Nick Sullivan", "text": "
\n

hmm, do we have instances of how long this feedback cycle takes in the median case? (honestly curious)

\n
\n

CFRG has provided advice in an informal capacity in the past. It hasn't been tracked in the datatracker. The CFRG is a general forum.

", "time": "2025-03-17T06:55:18Z"}, {"author": "Deirdre Connolly", "text": "

Oof these three documents interlocking feels like it will take five years

", "time": "2025-03-17T06:55:41Z"}, {"author": "Deirdre Connolly", "text": "

Nick Sullivan said:

\n
\n
\n

hmm, do we have instances of how long this feedback cycle takes in the median case? (honestly curious)

\n
\n

CFRG has provided advice in an informal capacity in the past. It hasn't been tracked in the datatracker. The CFRG is a general forum.

\n
\n

gotcha, thanks

", "time": "2025-03-17T06:55:55Z"}, {"author": "Michele Orr\u00f9", "text": "

don't worry we move fast are all in line

", "time": "2025-03-17T06:55:57Z"}, {"author": "Michele Orr\u00f9", "text": "

*and are all in line

", "time": "2025-03-17T06:56:06Z"}, {"author": "Stephen Farrell", "text": "

@nick: CFRG has a problem though: too many docs and taking too long (as does e.g. LAMPS) to that's not an RG vs WG thing

", "time": "2025-03-17T06:56:08Z"}, {"author": "Stephen Farrell", "text": "

but it is a problem

", "time": "2025-03-17T06:56:27Z"}, {"author": "Stephen Farrell", "text": "

nit: ARC is a failed protocol for fixing how DMARC breaks mailing lists, dunno if the acronym clash is worth fixing or not

", "time": "2025-03-17T07:00:37Z"}, {"author": "Daniel Gillmor", "text": "

please do fix the acronym clash.

", "time": "2025-03-17T07:01:06Z"}, {"author": "Bas Westerbaan", "text": "

What about URC? U=unlinkable.

", "time": "2025-03-17T07:01:08Z"}, {"author": "Rohan Mahy", "text": "

the name sounds like a monster from dungeons and dragons

", "time": "2025-03-17T07:01:52Z"}, {"author": "Rohan Mahy", "text": "

(URC => orc)

", "time": "2025-03-17T07:02:08Z"}, {"author": "Stephen Farrell", "text": "

the other arc is RFC8617

", "time": "2025-03-17T07:02:09Z"}, {"author": "Rohan Mahy", "text": "

Anonymous Rate Limiting Credentials (ARLC)

", "time": "2025-03-17T07:03:08Z"}, {"author": "Bas Westerbaan", "text": "

Or RAC? Rate-limited ACs

", "time": "2025-03-17T07:03:28Z"}, {"author": "Steven Valdez", "text": "

@Christopher Wood What are you imagining the scope of the cfrg-anonymous-credentials framework being? There seems to be a fuzzy line between what the engineering problems/properties of anonymous credentials are and the actual framework for the properties of the cryptographic components, the latter seems reasonable for CFRG but the former might be better in some WG?

", "time": "2025-03-17T07:04:26Z"}, {"author": "Christopher Wood", "text": "

@Steven: I envision the purpose of the document being the following:

\n
    \n
  1. Describe the purpose and syntax of anonymous credentials, allowing space for publicly vs privately verifiable credentials, different extensions, and so on
    2. \n
  2. Describe security and privacy properties for credentials
    3. \n
  3. Survey various constructions and the different considerations for them
    4. \n
", "time": "2025-03-17T07:06:59Z"}, {"author": "Christopher Wood", "text": "

I don't know if that's super clear, but I would be willing to take a first stab at writing it to make this more concrete

", "time": "2025-03-17T07:07:20Z"}, {"author": "Christopher Wood", "text": "

(And would welcome input from anyone else who wants to help)

", "time": "2025-03-17T07:07:33Z"}, {"author": "Simone", "text": "

re: ARC
\nIn the presented schema in the slides, there were clear overlaps between CMZ/BBS.

\n

A potential approach is to have a shared layer as CMZ/BBS are interchangeable.

\n

To optimize the effort of CFRG

", "time": "2025-03-17T07:07:47Z"}, {"author": "Cathie Yun", "text": "

Agreed, it is possible (and an open issue) to write ARC in relation to a generic MAC protocol: https://github.com/chris-wood/draft-arc/issues/8

", "time": "2025-03-17T07:09:15Z"}, {"author": "Thom Wiggers", "text": "

In light of earlier discussions: what is the research question here? It's getting standardized by ISO so what remains to be done except repeat the work

", "time": "2025-03-17T07:12:59Z"}, {"author": "Thom Wiggers", "text": "

or even s/repeat/rubber-stamp/

", "time": "2025-03-17T07:13:19Z"}, {"author": "Thom Wiggers", "text": "

(even recognizing that there is value in having non-paywalled standards)

", "time": "2025-03-17T07:13:37Z"}, {"author": "Martin Thomson", "text": "

I understand that we might want >1 general purpose PQ KEM, but do we want one based on LWE?

", "time": "2025-03-17T07:15:39Z"}, {"author": "Mike Ounsworth", "text": "

ISO specs are pay-walled, right? So if we want to use the thing within IETF, we need a public version of the standard?
\nIE having an IETF spec that requires you to go pay for the details somewhere else is ... icky?

", "time": "2025-03-17T07:15:51Z"}, {"author": "Martin Thomson", "text": "

We've cited ISO specs before, but I think we strongly prefer not to.

", "time": "2025-03-17T07:16:14Z"}, {"author": "Martin Thomson", "text": "

open standards!

", "time": "2025-03-17T07:16:35Z"}, {"author": "Daniel Gillmor", "text": "

agreed, ISO paywalled specs are a bad thing.

", "time": "2025-03-17T07:16:50Z"}, {"author": "Steven Valdez", "text": "

Christopher Wood said:

\n
\n

@Steven: I envision the purpose of the document being the following:

\n
    \n
  1. Describe the purpose and syntax of anonymous credentials, allowing space for publicly vs privately verifiable credentials, different extensions, and so on
    2. \n
  2. Describe security and privacy properties for credentials
    3. \n
  3. Survey various constructions and the different considerations for them
    4. \n
\n
\n

1 and 3 make sense for a CFRG doc, 2 seems like a more difficult one to have concrete properties, since the requirements and therefore the acceptable constructions will be dependent on the protocols that are building on anonymous credentials. I'd imagine the uses in PrivacyPass are going to require stronger properties than something like SPICE/Auth WGs that may want to use something in this space.

", "time": "2025-03-17T07:19:10Z"}, {"author": "Robert Moskowitz", "text": "

In that case, AD sponsored?

", "time": "2025-03-17T07:20:05Z"}, {"author": "Martin Thomson", "text": "

Of the work that the CFRG does, the work I value most is in selecting the \"best\" algorithms. Obviously, the NIST competition has sort of done that already, so the question is whether the CFRG might second-guess NIST.

", "time": "2025-03-17T07:20:21Z"}, {"author": "Stephen Farrell", "text": "

NIST are not the only gov with opinions

", "time": "2025-03-17T07:20:47Z"}, {"author": "Bas Westerbaan", "text": "

What are examplesof CFRG choosing the best thing?

", "time": "2025-03-17T07:20:54Z"}, {"author": "Bas Westerbaan", "text": "

Seems IExF in general has a hard time narrowing down options.

", "time": "2025-03-17T07:21:17Z"}, {"author": "Martin Thomson", "text": "

I didn't say best, I said \"best\"

", "time": "2025-03-17T07:21:22Z"}, {"author": "Bas Westerbaan", "text": "

*IxTF

", "time": "2025-03-17T07:21:24Z"}, {"author": "Bas Westerbaan", "text": "

@MT Sorry, I meant onenot the best.

", "time": "2025-03-17T07:21:37Z"}, {"author": "Martin Thomson", "text": "

Yeah, this group is not great at narrowing things down.

", "time": "2025-03-17T07:21:58Z"}, {"author": "Martin Thomson", "text": "

see also what Dierdre is saying

", "time": "2025-03-17T07:22:14Z"}, {"author": "Bas Westerbaan", "text": "

:)

", "time": "2025-03-17T07:22:22Z"}, {"author": "Yoav Nir", "text": "

I think you'd have to go about 10 years back to ChaCha20-Poly1305

", "time": "2025-03-17T07:22:29Z"}, {"author": "Stephen Farrell", "text": "

see also hash based sigs:-(

", "time": "2025-03-17T07:22:31Z"}, {"author": "Martin Thomson", "text": "

much consistency!

", "time": "2025-03-17T07:24:14Z"}, {"author": "Stephen Farrell", "text": "

see also current slide (having a companion that differs;-)

", "time": "2025-03-17T07:25:21Z"}, {"author": "Christopher Wood", "text": "

@Steven yeah, that may be, but I think thinking about the different properties is a good use of this group's time.

", "time": "2025-03-17T07:25:35Z"}, {"author": "Martin Thomson", "text": "

KDF(SS1, SS1, CT1, PK1, CT2, PK2, label)

", "time": "2025-03-17T07:26:17Z"}, {"author": "Rohan Mahy", "text": "

Quantum Superiority Fighter

", "time": "2025-03-17T07:26:35Z"}, {"author": "Stephen Farrell", "text": "

and the reason we want two of these is...

", "time": "2025-03-17T07:26:50Z"}, {"author": "Daniel Gillmor", "text": "

...so we have something to argue about?

", "time": "2025-03-17T07:27:09Z"}, {"author": "Martin Thomson", "text": "

dkg++

", "time": "2025-03-17T07:27:16Z"}, {"author": "Martin Thomson", "text": "

ooooOOOOooooo 2kilobytes!

", "time": "2025-03-17T07:27:34Z"}, {"author": "Stephen Farrell", "text": "

some of us manage to argue even without that

", "time": "2025-03-17T07:27:36Z"}, {"author": "Stephen Farrell", "text": "

I'd be fine with one of these things

", "time": "2025-03-17T07:27:52Z"}, {"author": "Daniel Gillmor", "text": "

cost savings of 2KiB of hashing, in 2025\u2026not super compelling.

", "time": "2025-03-17T07:28:11Z"}, {"author": "Martin Thomson", "text": "

are there any KEMs that are PQ and not LEAK-WOSSNAME secure?

", "time": "2025-03-17T07:28:31Z"}, {"author": "Richard Barnes", "text": "

+1000 @dkg

", "time": "2025-03-17T07:28:58Z"}, {"author": "Stephen Farrell", "text": "

exactly which LEAK-<name> things are worthwhile isn't entirely clear

", "time": "2025-03-17T07:29:01Z"}, {"author": "Richard Barnes", "text": "

who tf cares about hashing

", "time": "2025-03-17T07:29:06Z"}, {"author": "Martin Thomson", "text": "

if not, hash all the things

", "time": "2025-03-17T07:29:14Z"}, {"author": "Stephen Farrell", "text": "

yep kitchen's need a sink but not a fictional space plan

", "time": "2025-03-17T07:29:39Z"}, {"author": "Stephen Farrell", "text": "

s/plan/plane/

", "time": "2025-03-17T07:29:50Z"}, {"author": "Bas Westerbaan", "text": "

@dkg It's actually a ~10% reduction in CPU cylces for the whole hybrid key agreement. ML-KEM and X25519 are surprisingly fast even compared to hashes.

", "time": "2025-03-17T07:30:01Z"}, {"author": "Christopher Wood", "text": "

@Richard y u hate hashes

", "time": "2025-03-17T07:30:03Z"}, {"author": "Daniel Gillmor", "text": "

also, KItchenSinkS = KISS

", "time": "2025-03-17T07:30:15Z"}, {"author": "Bas Westerbaan", "text": "

Whether that's important isa second.

", "time": "2025-03-17T07:30:18Z"}, {"author": "Richard Barnes", "text": "

au contraire, i <3 hashes, want moar hashes

", "time": "2025-03-17T07:30:18Z"}, {"author": "Martin Thomson", "text": "

So there is also h(SS1, SS2, H(CT1, PK1), H(CT2, PK2), label)

", "time": "2025-03-17T07:30:20Z"}, {"author": "Christopher Wood", "text": "

@dkg: amazing

", "time": "2025-03-17T07:30:27Z"}, {"author": "Bas Westerbaan", "text": "

@MT, yes, that's chempat

", "time": "2025-03-17T07:30:41Z"}, {"author": "Martin Thomson", "text": "

bas, Yes, but Diedre seems to be ignoring that

", "time": "2025-03-17T07:31:13Z"}, {"author": "Stephen Farrell", "text": "

I'm +100 on only wanting 1 output

", "time": "2025-03-17T07:31:17Z"}, {"author": "Martin Thomson", "text": "

The point of this session should not be to present your idea, but work toward a resolution for a debate.

", "time": "2025-03-17T07:31:29Z"}, {"author": "Richard Barnes", "text": "

on a different topic -- are we using SHA3 here just to be cool?

", "time": "2025-03-17T07:31:36Z"}, {"author": "Christopher Wood", "text": "

@Stephen do you mean one combiner?

", "time": "2025-03-17T07:31:37Z"}, {"author": "Christopher Wood", "text": "

@Richard you said you wanted more hashes so we went with the bigger hash

", "time": "2025-03-17T07:31:49Z"}, {"author": "Stephen Farrell", "text": "

yep

", "time": "2025-03-17T07:31:49Z"}, {"author": "Daniel Gillmor", "text": "

Stephen, i get the sense that you (and i) are going to be disappointed

", "time": "2025-03-17T07:31:50Z"}, {"author": "Martin Thomson", "text": "

SHA3 has properties over SHA2 that are important in some of these, I believe.

", "time": "2025-03-17T07:31:57Z"}, {"author": "Bas Westerbaan", "text": "

@richard barnes: SHA3 is used already inside of ML-KEM, so it makes sense not to add another dependency

", "time": "2025-03-17T07:32:11Z"}, {"author": "Stephen Farrell", "text": "

@dkg: of course - people won't back down from their fav

", "time": "2025-03-17T07:32:14Z"}, {"author": "Mike Ounsworth", "text": "

Sorry, I'm in RATS and not seeing the presentation. What's the advantage of
\nh(SS1, SS2, H(CT1, PK1), H(CT2, PK2), label)
\nover
\nh(SS1, SS2, CT1, PK1, CT2, PK2, label)
\n?

", "time": "2025-03-17T07:32:55Z"}, {"author": "Mike Ounsworth", "text": "

Martin Thomson said:

\n
\n

SHA3 has properties over SHA2 that are important in some of these, I believe.

\n
\n

If you do SHA2, then you need HMAC-SHA2

", "time": "2025-03-17T07:33:16Z"}, {"author": "Martin Thomson", "text": "

Mike: the advantage would be that you can save the hash and not have to run the hash over the large ciphertext every time.

", "time": "2025-03-17T07:33:32Z"}, {"author": "Stephen Farrell", "text": "

I'd prefer not allocating code points until we know if we want >1 output

", "time": "2025-03-17T07:33:38Z"}, {"author": "Martin Thomson", "text": "

It's not a meaningful different to me.

", "time": "2025-03-17T07:33:39Z"}, {"author": "Bas Westerbaan", "text": "

Perf. Pag 20 of https://eprint.iacr.org/2024/039.pdf

", "time": "2025-03-17T07:34:21Z"}, {"author": "Martin Thomson", "text": "

this is not interoperable without a ;protocol

", "time": "2025-03-17T07:34:26Z"}, {"author": "Mike Ounsworth", "text": "

Martin Thomson said:

\n
\n

Mike: the advantage would be that you can save the hash and not have to run the hash over the large ciphertext every time.

\n
\n

Although, what do you mean by \"every time\"? How often are you computing a KEM combiner without changing the ciphertext?

", "time": "2025-03-17T07:34:31Z"}, {"author": "Stephen Farrell", "text": "

I'm not very convinced by the performance issues for KEM combiners - we're also doing ECDH each time

", "time": "2025-03-17T07:35:13Z"}, {"author": "Martin Thomson", "text": "

mike: exactly

", "time": "2025-03-17T07:35:17Z"}, {"author": "Bas Westerbaan", "text": "

The difference is 10% just for ciphertext. With PK it's a bit more, so 20%?

", "time": "2025-03-17T07:36:10Z"}, {"author": "Stephen Farrell", "text": "

20% of what?

", "time": "2025-03-17T07:36:22Z"}, {"author": "Bas Westerbaan", "text": "

Encap and decap cycles

", "time": "2025-03-17T07:36:31Z"}, {"author": "Daniel Gillmor", "text": "

20% of the computational costs of sending a single advertisement to a single eyeball

", "time": "2025-03-17T07:36:45Z"}, {"author": "Stephen Farrell", "text": "

I do not agree that we want different KEM combiners

", "time": "2025-03-17T07:37:52Z"}, {"author": "Christopher Wood", "text": "

I think we should whittle this list down

", "time": "2025-03-17T07:38:02Z"}, {"author": "Christopher Wood", "text": "

Just because the draft has N>1 doesn't mean it _needs_ to have N>1

", "time": "2025-03-17T07:38:11Z"}, {"author": "Stephen Farrell", "text": "

...to 1

", "time": "2025-03-17T07:38:11Z"}, {"author": "Martin Thomson", "text": "

the whole kitchensink/qsf thing seems bad

", "time": "2025-03-17T07:38:19Z"}, {"author": "Richard Barnes", "text": "

@martin why?

", "time": "2025-03-17T07:38:51Z"}, {"author": "Daniel Gillmor", "text": "

multiple combiner options is a recipe for stubbed toes for ignorant implementers long into the future.

", "time": "2025-03-17T07:38:58Z"}, {"author": "Martin Thomson", "text": "

what others have said; one option

", "time": "2025-03-17T07:39:27Z"}, {"author": "Richard Barnes", "text": "

it seems like the doc says when it's ok to use QSF, which provides the instructions the ignorant implementor needs

", "time": "2025-03-17T07:39:39Z"}, {"author": "Thom Wiggers", "text": "

hot take: implementers should not look at this CFRG doc to construct their own, but look at docs that specify concrete instantiations

", "time": "2025-03-17T07:40:09Z"}, {"author": "Daniel Gillmor", "text": "

Richard, it tells the ignorant implementer that they need to understand more details about the specific components that they are importing.

", "time": "2025-03-17T07:40:12Z"}, {"author": "Stephen Farrell", "text": "

\"when it's ok to use QSF\" how much does it cost to explain all that over and over for decades?

", "time": "2025-03-17T07:40:16Z"}, {"author": "Martin Thomson", "text": "

how does an implementer decide that QSF is OK for, say, FrodoKEM?

", "time": "2025-03-17T07:40:24Z"}, {"author": "Deirdre Connolly", "text": "

Daniel Gillmor said:

\n
\n

cost savings of 2KiB of hashing, in 2025\u2026not super compelling.

\n
\n

tell Google that

", "time": "2025-03-17T07:40:25Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

are there any KEMs that are PQ and not LEAK-WOSSNAME secure?

\n
\n

Yes

", "time": "2025-03-17T07:40:53Z"}, {"author": "Bas Westerbaan", "text": "
\n

hot take: implementers should not look at this CFRG doc to construct their own, but look at docs that specify concrete instantiations

\n
\n

Agreed. I wish we'd just specify two or three concrete hybrids and be done with it. Hybrids will not stick around forever anyway.

", "time": "2025-03-17T07:41:01Z"}, {"author": "Stephen Farrell", "text": "

my sympathy for google's specific problems is.... limited

", "time": "2025-03-17T07:41:10Z"}, {"author": "Martin Thomson", "text": "

I would prefer that we drop all concrete instantiations and let the protocols sort things out.

", "time": "2025-03-17T07:41:29Z"}, {"author": "Thom Wiggers", "text": "

These additional hash computations at scale amount to massive amounts of additional energy used

", "time": "2025-03-17T07:41:30Z"}, {"author": "Christopher Wood", "text": "

@MT how would you propose we address this for HPKE, then?

", "time": "2025-03-17T07:42:06Z"}, {"author": "Martin Thomson", "text": "

There are cases where components need all the options, which might be true for HPKE. Otherwise, they can pick the one that is best for that protocol.

", "time": "2025-03-17T07:42:08Z"}, {"author": "Daniel Gillmor", "text": "

Thom: invasive advertising and surveillance uses many times more massive amounts of energy and yet the Googles of the world seem OK with those costs.

", "time": "2025-03-17T07:42:09Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

SHA3 has properties over SHA2 that are important in some of these, I believe.

\n
\n

SHA3 is a secure KDF, SHA2 is not, HKDF-SHA256 is

", "time": "2025-03-17T07:42:14Z"}, {"author": "Deirdre Connolly", "text": "

Mike Ounsworth said:

\n
\n

Sorry, I'm in RATS and not seeing the presentation. What's the advantage of
\nh(SS1, SS2, H(CT1, PK1), H(CT2, PK2), label)
\nover
\nh(SS1, SS2, CT1, PK1, CT2, PK2, label)
\n?

\n
\n

design team did not see one that's why we didn't include it on top of KitchenSink

", "time": "2025-03-17T07:42:51Z"}, {"author": "Martin Thomson", "text": "

TLS, for example, has this sorted under the kitchensink model already. That has basically resolved with one winner already.

", "time": "2025-03-17T07:42:59Z"}, {"author": "Stephen Farrell", "text": "

all the costs of KEM combiners are trivial compared to the traffic being protected - I don't buy the efficiency arguments at all

", "time": "2025-03-17T07:43:12Z"}, {"author": "Mike Ounsworth", "text": "

Christopher Wood said:

\n
\n

Just because the draft has N>1 doesn't mean it _needs_ to have N>1

\n
\n

So we can do a ThisIsOnlySecureForML-KEMAndThingsThatHaveTheSameSecurityPropertiesAsML-KEMCombiner(), and call that our 1 option. And let the future figure itself out.

", "time": "2025-03-17T07:43:19Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

Mike: the advantage would be that you can save the hash and not have to run the hash over the large ciphertext every time.

\n
\n

You cannot save it, the ciphertext changes each time

", "time": "2025-03-17T07:43:28Z"}, {"author": "Deirdre Connolly", "text": "

The only thing in that construction you should be saving is the hybrid shared secret

", "time": "2025-03-17T07:43:46Z"}, {"author": "Thom Wiggers", "text": "

Mike Ounsworth said:

\n
\n

Christopher Wood said:

\n
\n

Just because the draft has N>1 doesn't mean it _needs_ to have N>1

\n
\n

So we can do a ThisIsOnlySecureForML-KEMAndThingsThatHaveTheSameSecurityPropertiesAsML-KEMCombiner(), and call that our 1 option. And let the future figure itself out.

\n
\n

ITYM X-Wing

", "time": "2025-03-17T07:43:48Z"}, {"author": "Deirdre Connolly", "text": "

Stephen Farrell said:

\n
\n

I'm not very convinced by the performance issues for KEM combiners - we're also doing ECDH each time

\n
\n

I regret to inform you that ECC implementations are quite fast now

", "time": "2025-03-17T07:44:27Z"}, {"author": "Daniel Gillmor", "text": "

faster than hashing 2KiB?

", "time": "2025-03-17T07:45:00Z"}, {"author": "Martin Thomson", "text": "

so are hash implementations

", "time": "2025-03-17T07:45:02Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

how does an implementer decide that QSF is OK for, say, FrodoKEM?

\n
\n

I/someone writes down the concrete construction for them

", "time": "2025-03-17T07:45:38Z"}, {"author": "Thom Wiggers", "text": "

Daniel Gillmor said:

\n
\n

Thom: invasive advertising and surveillance uses many times more massive amounts of energy and yet the Googles of the world seem OK with those costs.

\n
\n

I would rather that they don't do that either, but that doesn't mean that we can't or shouldn't make general cryptography less expensive on the environment if we have the proofs and the opportunity.

", "time": "2025-03-17T07:45:46Z"}, {"author": "Stephen Farrell", "text": "

even ignoring dkg's fine point about ads, 2kb of javascript shite could much mor easilly be dropped

", "time": "2025-03-17T07:46:04Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

I would prefer that we drop all concrete instantiations and let the protocols sort things out.

\n
\n

lmao

", "time": "2025-03-17T07:46:05Z"}, {"author": "Mike Ounsworth", "text": "

Thom Wiggers said:

\n
\n

Mike Ounsworth said:

\n
\n

Christopher Wood said:

\n
\n

Just because the draft has N>1 doesn't mean it _needs_ to have N>1

\n
\n

So we can do a ThisIsOnlySecureForML-KEMAndThingsThatHaveTheSameSecurityPropertiesAsML-KEMCombiner(), and call that our 1 option. And let the future figure itself out.

\n
\n

ITYM X-Wing

\n
\n

Sure, if ML-KEM-768 + X25519 is the only combo you need. Otherwise I mean draft-ietf-lamps-pq-composite-kem.

", "time": "2025-03-17T07:46:12Z"}, {"author": "Jonathan Hoyland", "text": "

Channel binding!

", "time": "2025-03-17T07:47:04Z"}, {"author": "Daniel Gillmor", "text": "

Thom: the jet fuel alone from multiple IETFs where people travel to ask someone smart and trustworthy like Dierdre to bless their choices seems like it ought to be factored into these comparisons too.

", "time": "2025-03-17T07:47:11Z"}, {"author": "Martin Thomson", "text": "

shake256 is 7 cycles per byte on modern hardware; sha256 is 2; HMAC-SHA2 might be enough faster that SHA-3 isn't the best choice.

", "time": "2025-03-17T07:47:16Z"}, {"author": "Bas Westerbaan", "text": "

@dkg @MT Hashing 2kB with SHA3 is about 24k cycles on i7-11700K. MLKEM768+X25519 decaps is 116k cycles.

", "time": "2025-03-17T07:47:19Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

TLS, for example, has this sorted under the kitchensink model already. That has basically resolved with one winner already.

\n
\n

NO they do NOT - TLS 1.3 already includes everything in the protocol transcript in their key schedule, their hybrid 'combiner' is the simplest ss1 || ss2 because the protocol is already doing a split-key PRF style combiner in its key schedule

", "time": "2025-03-17T07:47:23Z"}, {"author": "Stephen Farrell", "text": "

IMO: if we end up with >1 kem combiner scheme that'll be because of people's egos and not the science or engineering. And dkg is right: we probably will.

", "time": "2025-03-17T07:47:38Z"}, {"author": "Daniel Gillmor", "text": "

Bas: thank you for bringing concrete measaurements!

", "time": "2025-03-17T07:47:53Z"}, {"author": "Martin Thomson", "text": "

Dierdre: that's a nitpick and you know it

", "time": "2025-03-17T07:48:07Z"}, {"author": "Christopher Wood", "text": "

My prediction is three combiners: X-Wing, one with a NIST curve for ML-KEM-768, and one with a NIST curve for ML-KEM-1024

", "time": "2025-03-17T07:48:11Z"}, {"author": "Christopher Wood", "text": "

(I make no claim as to whether this is the best outcome)

", "time": "2025-03-17T07:48:34Z"}, {"author": "Deirdre Connolly", "text": "

The diversity of concrete instances is not 'egos' it's the diversity of deployed crypto and requirements being encoded into hybrids

", "time": "2025-03-17T07:48:35Z"}, {"author": "Deirdre Connolly", "text": "

Martin Thomson said:

\n
\n

Dierdre: that's a nitpick and you know it

\n
\n

It's really not and it matters - the IETF is doing cryptography all over the place, not just CFRG

", "time": "2025-03-17T07:48:56Z"}, {"author": "Deirdre Connolly", "text": "

Good cryptographic design in TLS 1.3 allows easy solutions such as that one, old cryptographic design in other places in IETF forces more consideration into things like these hybrid kems over here in CFRG

", "time": "2025-03-17T07:49:38Z"}, {"author": "Mike Ounsworth", "text": "

\"TLS 1.3 Hyrbid is a KEM Combiner\" in the same way that a car is a motor. It certainly includes a motor, but if what I want is a motor to drive my kitchen food processor, then using a whole car seems overkill.
\nWe have other protocols that want a KEM combiner as a standalone component in isolation from all the other things that TLS does.

", "time": "2025-03-17T07:50:00Z"}, {"author": "Stephen Farrell", "text": "

do we have any other protocols that want more than one kem combiner scheme?

", "time": "2025-03-17T07:50:34Z"}, {"author": "Daniel Gillmor", "text": "

Bas: if you could provide a link to more details about where those numbers come from, that would be very useful. (e.g. what specifically goes into the ML-KEM+X25519 computation? is that with some particular combiner)?

", "time": "2025-03-17T07:50:52Z"}, {"author": "Thom Wiggers", "text": "

I think Bas already linked the paper earlier

", "time": "2025-03-17T07:51:30Z"}, {"author": "Thom Wiggers", "text": "

Bas Westerbaan said:

\n
\n

Perf. Pag 20 of https://eprint.iacr.org/2024/039.pdf

\n
\n

^

", "time": "2025-03-17T07:51:44Z"}, {"author": "Daniel Gillmor", "text": "

Thom, thx

", "time": "2025-03-17T07:52:07Z"}, {"author": "Quynh Dang", "text": "

https://keccak.team/sw_performance.html

", "time": "2025-03-17T07:52:08Z"}, {"author": "Thom Wiggers", "text": "

ARMv8.2a CPUs already have sha3 hardware extensions btw

", "time": "2025-03-17T07:52:43Z"}, {"author": "Bas Westerbaan", "text": "

@dkg What Thom said. I do have to add the obvious that I don't think performance is the most important consideration. I just want to push back against the idea that hashing is completely free.

", "time": "2025-03-17T07:53:53Z"}, {"author": "Christopher Wood", "text": "

This was a particularly spicy conversation. I think this group would benefit from a dedicated interim on the topic of combiners and the requirements and rationale that influence which combiners we work on (if any). We need a high bandwidth space to talk... this chat isn't it.

", "time": "2025-03-17T07:57:18Z"}, {"author": "Nick Sullivan", "text": "

Agreed, @chris wood.

", "time": "2025-03-17T07:58:22Z"}, {"author": "Alexey Melnikov", "text": "

We are officially over time, but hopefully the recording will not cut off in the middle of the last presentation

", "time": "2025-03-17T08:00:53Z"}, {"author": "Mike Ounsworth", "text": "

Christopher Wood said:

\n
\n

This was a particularly spicy conversation. I think this group would benefit from a dedicated interim on the topic of combiners and the requirements and rationale that influence which combiners we work on (if any). We need a high bandwidth space to talk... this chat isn't it.

\n
\n

This sounds like creating bandwidth for combiners. I like. I like a lot.

", "time": "2025-03-17T08:01:02Z"}, {"author": "Thom Wiggers", "text": "

NTRU != NTRU Prime by the way

", "time": "2025-03-17T08:01:48Z"}, {"author": "Bas Westerbaan", "text": "

Did I miss an IPR disclosure?

", "time": "2025-03-17T08:02:02Z"}, {"author": "Thom Wiggers", "text": "

So this is a different scheme from the one deployed by e.g. OpenSSL OpenSSH

", "time": "2025-03-17T08:02:03Z"}, {"author": "Stephen Farrell", "text": "

you mean openssh?

", "time": "2025-03-17T08:02:14Z"}, {"author": "Deirdre Connolly", "text": "

Bas Westerbaan said:

\n
\n

Did I miss an IPR disclosure?

\n
\n

for which

", "time": "2025-03-17T08:02:15Z"}, {"author": "Daniel Gillmor", "text": "

itym OpenSSH, no?

", "time": "2025-03-17T08:02:16Z"}, {"author": "Thom Wiggers", "text": "

yes, my bad

", "time": "2025-03-17T08:02:21Z"}, {"author": "Daniel Gillmor", "text": "

for ML-KEM

", "time": "2025-03-17T08:02:22Z"}, {"author": "Deirdre Connolly", "text": "

You did not miss one

", "time": "2025-03-17T08:02:45Z"}, {"author": "Thom Wiggers", "text": "

NTRU was supposed to be covered by the same patents as ML-KEM according to certain cryptographers

", "time": "2025-03-17T08:02:58Z"}, {"author": "Deirdre Connolly", "text": "

Thom Wiggers said:

\n
\n

NTRU was supposed to be covered by the same patents as ML-KEM according to certain cryptographers

\n
\n

hahahahaah

", "time": "2025-03-17T08:03:05Z"}, {"author": "Thom Wiggers", "text": "

:man_shrugging:

", "time": "2025-03-17T08:03:15Z"}, {"author": "Stephen Farrell", "text": "

doesn't NTRU predate the filings though (if the original NTRU)

", "time": "2025-03-17T08:03:17Z"}, {"author": "Deirdre Connolly", "text": "

ha i'm scanning NTRU 2019 spec and its binding properties on first glance look...poor

", "time": "2025-03-17T08:03:46Z"}, {"author": "Deirdre Connolly", "text": "

https://ntru.org/f/ntru-20190330.pdf

", "time": "2025-03-17T08:04:08Z"}, {"author": "Deirdre Connolly", "text": "

image.png

\n
", "time": "2025-03-17T08:04:16Z"}, {"author": "Deirdre Connolly", "text": "

OFC, if it lacks an FO transform

", "time": "2025-03-17T08:04:24Z"}, {"author": "Deirdre Connolly", "text": "

'lmao'

", "time": "2025-03-17T08:04:34Z"}, {"author": "Thom Wiggers", "text": "

the FO transform is line 3-5 right?

", "time": "2025-03-17T08:05:05Z"}, {"author": "Thom Wiggers", "text": "

oh wait where is encrypt

", "time": "2025-03-17T08:05:22Z"}, {"author": "Stephen Farrell", "text": "

the agreement with NIST that they only published parts of

", "time": "2025-03-17T08:05:56Z"}, {"author": "Thom Wiggers", "text": "

NTRU Prime is sloooooow

", "time": "2025-03-17T08:06:47Z"}, {"author": "Daniel Gillmor", "text": "

thanks all!

", "time": "2025-03-17T08:07:30Z"}, {"author": "Thom Wiggers", "text": "

@Deirdre Connolly I think DPKE_Decrypt might be hiding the FO

", "time": "2025-03-17T08:07:36Z"}, {"author": "Thom Wiggers", "text": "

the NIST submission definitely had FO

", "time": "2025-03-17T08:07:43Z"}]