[{"author": "Yoav Nir", "text": "

But what if those other people are wrong?

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

I guess nicely disagree?

", "time": "2025-03-19T02:32:21Z"}, {"author": "Ben S", "text": "

Me? Wrong? That's unpossible!

", "time": "2025-03-19T02:32:43Z"}, {"author": "Michael Richardson", "text": "

Yoav Nir said:

\n
\n

But what if those other people are wrong?

\n
\n

Are they WRONG! or just wrong?!. Usually the second one.

", "time": "2025-03-19T02:33:29Z"}, {"author": "Stephen Farrell", "text": "

I hope hhe QKD part of this isn't something that hasn't to be excavated:-)

", "time": "2025-03-19T02:33:30Z"}, {"author": "Martin Thomson", "text": "

I agree with Ekr

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

I would suggest that we repurpose the 55 minutes for that discussion

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

Maybe you can split that time

", "time": "2025-03-19T02:34:51Z"}, {"author": "Michael StJohns", "text": "

+1 ekr

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

30 minutes for \"is this problem well defined, etc\"

", "time": "2025-03-19T02:35:08Z"}, {"author": "Michael Richardson", "text": "

I think that maybe we know that the charter is not perfect, so, we should not word smith charter text. I think EKR is right. We should NOT move to charter discussion unless we have full consensus to proceed.

", "time": "2025-03-19T02:35:25Z"}, {"author": "Yaron Sheffer", "text": "

The chairs don't think that the charter is perfect, either. The discussion period is supposed to be about the problem, and also about the charter at a high level, not to wordsmith it.

", "time": "2025-03-19T02:37:53Z"}, {"author": "Stephen Farrell", "text": "

we generally dislike x.509, question is: can we do as good or better?

", "time": "2025-03-19T02:38:16Z"}, {"author": "Eric Rescorla", "text": "

Well, I mean we've already run this experiment. It's called Kerberos.

", "time": "2025-03-19T02:38:40Z"}, {"author": "Eric Rescorla", "text": "

And we know the answer to the qestion

", "time": "2025-03-19T02:38:44Z"}, {"author": "Stephen Farrell", "text": "

well, we also dislike Kerberos' ASN.1 too:-)

", "time": "2025-03-19T02:39:03Z"}, {"author": "Robert Moskowitz", "text": "

Basically we do not know how to establish trust without a 3rd party introducer. e.g. Cert server. Now how to reduce the complexity, cost is a side issue.

", "time": "2025-03-19T02:39:11Z"}, {"author": "Stephen Farrell", "text": "

side note: I think he went to kerberos-- too soon;-)

", "time": "2025-03-19T02:39:50Z"}, {"author": "Wei Pan", "text": "

if single KDC is a prolem, then use multiple Kerberos KDCs

", "time": "2025-03-19T02:40:20Z"}, {"author": "Eric Rescorla", "text": "

This is topologically the same as Kerberosw

", "time": "2025-03-19T02:40:33Z"}, {"author": "Robert Moskowitz", "text": "

Cutting to the chase?

", "time": "2025-03-19T02:40:35Z"}, {"author": "David Black", "text": "

Single point of control -> single point of failure TANSTAAFL.

", "time": "2025-03-19T02:40:42Z"}, {"author": "Stephen Farrell", "text": "

we are jumping ahead, but it was the presenter's slide

", "time": "2025-03-19T02:41:00Z"}, {"author": "Stephen Farrell", "text": "

I'd be more keen on sseing why they need a new thing because of QKD

", "time": "2025-03-19T02:41:28Z"}, {"author": "Eric Rescorla", "text": "

Meetecho: I am getting terrible kerning issues on the Web client.
\nimage.png

\n
", "time": "2025-03-19T02:42:20Z"}, {"author": "Lorenzo Miniero", "text": "

@Eric Rescorla yes we've noticed, we're looking into it, apologies for that :(

", "time": "2025-03-19T02:42:47Z"}, {"author": "Paul Wouters", "text": "

we reorted the kerneing stuff. it is happeningelsewhere too

", "time": "2025-03-19T02:42:49Z"}, {"author": "Felix Linker", "text": "

@Eric Rescorla So from reading draft-dkls-uske-00, they seem to assume pre-shared keys. Seems more like key derivation to me.

", "time": "2025-03-19T02:42:57Z"}, {"author": "Eric Rescorla", "text": "

The reason there are cross-domain issues is that Kerberos is being run in a federated context.

", "time": "2025-03-19T02:43:03Z"}, {"author": "Eric Rescorla", "text": "

But if you just run one giant KDC, which is what DSKE is (well N giant KDCs), then yeah, you don't have cross-domain issues

", "time": "2025-03-19T02:43:27Z"}, {"author": "Eric Rescorla", "text": "

Felix Linker said:

\n
\n

Eric Rescorla So from reading draft-dkls-uske-00, they seem to assume pre-shared keys. Seems more like key derivation to me.

\n
\n

Yeah, you should focus on DSKE, which is topologically like running X Kerberos servers and then combining the keys

", "time": "2025-03-19T02:44:13Z"}, {"author": "Robert Moskowitz", "text": "

Always a 3rd party. It goes back at least to the Cesearean letter of credit. Why should trust you to do business.

", "time": "2025-03-19T02:44:15Z"}, {"author": "Stephen Farrell", "text": "

we're defo diving more deep in early slides than would've benefited the presenter

", "time": "2025-03-19T02:44:26Z"}, {"author": "Eric Rescorla", "text": "

Stephen Farrell said:

\n
\n

we're defo diving more deep in early slides than would've benefited the presenter

\n
\n

Well, I mean this is what happens if you are going to make a lot of controversial assertions

", "time": "2025-03-19T02:44:55Z"}, {"author": "Stephen Farrell", "text": "

yep, not saying who's at fault

", "time": "2025-03-19T02:45:09Z"}, {"author": "Michael StJohns", "text": "

kerberos like systems are problematic for mesh network securing.. basically for any non-pairwise system..

", "time": "2025-03-19T02:45:10Z"}, {"author": "Eric Rescorla", "text": "

Well, DSKE is a pairwise system

", "time": "2025-03-19T02:45:23Z"}, {"author": "Michael StJohns", "text": "

yup

", "time": "2025-03-19T02:45:30Z"}, {"author": "Stephen Farrell", "text": "

aside: I did a dissing Kerberos pressie at an IETF in 1995 - as usual I lost:-)

", "time": "2025-03-19T02:46:14Z"}, {"author": "Eric Rescorla", "text": "

Its hilarious that AO is an example use case, because nobody wants AO

", "time": "2025-03-19T02:46:37Z"}, {"author": "Eric Rescorla", "text": "

ML-KEM keys aren't 100K

", "time": "2025-03-19T02:47:00Z"}, {"author": "Stephen Farrell", "text": "

Am I wrong/right in thinking this is really about QKD? If so, hope we get to the meat soon

", "time": "2025-03-19T02:47:14Z"}, {"author": "Felix Linker", "text": "

@Eric Rescorla DSKE draft also says in intro: \"DSKE relies on pre-shared random numbers between DSKE clients and a set of so-called 'Security Hubs'.\" Sounds like key derivation to me.

", "time": "2025-03-19T02:47:14Z"}, {"author": "Eric Rescorla", "text": "

I'm not sure what you mean by \"key derivation\"

", "time": "2025-03-19T02:47:35Z"}, {"author": "Felix Linker", "text": "

You have a symmetric key and you make new ones out of it.

", "time": "2025-03-19T02:47:44Z"}, {"author": "Michael StJohns", "text": "

dske ~= psk?

", "time": "2025-03-19T02:47:48Z"}, {"author": "Eric Rescorla", "text": "

No, that's not how it works

", "time": "2025-03-19T02:47:50Z"}, {"author": "Eric Rescorla", "text": "

No, DSKE ~= Kerberos

", "time": "2025-03-19T02:47:54Z"}, {"author": "Stephen Farrell", "text": "

interesting thing though is QKD != you have a shared key (for sure)

", "time": "2025-03-19T02:48:07Z"}, {"author": "Felix Linker", "text": "

Eric Rescorla said:

\n
\n

No, DSKE ~= Kerberos

\n
\n

Both could be true

", "time": "2025-03-19T02:48:24Z"}, {"author": "Eric Rescorla", "text": "

Felix Linker said:

\n
\n

Eric Rescorla said:

\n
\n

No, DSKE ~= Kerberos

\n
\n

Both could be true

\n
", "time": "2025-03-19T02:48:33Z"}, {"author": "Michael StJohns", "text": "

did dske progress through the ietf? I see a nmber of non-ietf pages when I google it..

", "time": "2025-03-19T02:49:25Z"}, {"author": "Eric Rescorla", "text": "

Michael StJohns said:

\n
\n

did dske progress through the ietf? I see a nmber of non-ietf pages when I google it..

\n
\n

No. DSKE is what he is pitching here.

", "time": "2025-03-19T02:49:36Z"}, {"author": "Michael StJohns", "text": "

got it.. missed that.. I should have read the meeting info.. sigh

", "time": "2025-03-19T02:51:07Z"}, {"author": "Stephen Farrell", "text": "

is there a reason to be shy about the QKD angle here? (Or am I off-base thinking that's the real reason for this?)

", "time": "2025-03-19T02:51:42Z"}, {"author": "Jonathan Hammell", "text": "

Better pitched as not based on the computational hardness of public key assumptions rather than informationally theoretic secure.

", "time": "2025-03-19T02:51:47Z"}, {"author": "Martin Thomson", "text": "

The agenda did not include links to drafts. F

", "time": "2025-03-19T02:52:04Z"}, {"author": "Michael StJohns", "text": "

I feel much better! :-)

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

@mt: bof materials did have links, don't have URL handy

", "time": "2025-03-19T02:52:29Z"}, {"author": "Melchior Aelmans", "text": "

https://datatracker.ietf.org/doc/draft-mwag-dske/

", "time": "2025-03-19T02:52:36Z"}, {"author": "Martin Thomson", "text": "

The datatracker packages for the BoF did not include any of that information.

", "time": "2025-03-19T02:52:49Z"}, {"author": "Martin Thomson", "text": "

I admit that I didn't go looking all over the web, but I was not able to prepare for this meeting.

", "time": "2025-03-19T02:53:14Z"}, {"author": "Thom Wiggers", "text": "

ERK, can you slow down a little bit

", "time": "2025-03-19T02:53:23Z"}, {"author": "Thom Wiggers", "text": "

thanks :)

", "time": "2025-03-19T02:53:40Z"}, {"author": "Stephen Farrell", "text": "

@ekr: I'd prefer you goto 2xekrs:-)

", "time": "2025-03-19T02:53:46Z"}, {"author": "Michael StJohns", "text": "

yeah - found that... but can't get there from the agenda...

", "time": "2025-03-19T02:53:53Z"}, {"author": "Michael StJohns", "text": "

ekr is only at about 400 milli-ekrs...

", "time": "2025-03-19T02:54:18Z"}, {"author": "Michael StJohns", "text": "

transcription is keeping up...

", "time": "2025-03-19T02:54:47Z"}, {"author": "Stephen Farrell", "text": "

well, PKI has it's own centralising forces too

", "time": "2025-03-19T02:54:57Z"}, {"author": "Jonathan Hammell", "text": "

Transcription folks are amazing.

", "time": "2025-03-19T02:55:09Z"}, {"author": "Martin Thomson", "text": "

the in-room audio is not that great, so ekr was not 100% clear

", "time": "2025-03-19T02:55:15Z"}, {"author": "Eric Rescorla", "text": "

@MT: thanks.

", "time": "2025-03-19T02:55:31Z"}, {"author": "Michael StJohns", "text": "

I thought the transcription was automated..

", "time": "2025-03-19T02:55:32Z"}, {"author": "Olaf Kolkman", "text": "

Speaking a little slower might help.

", "time": "2025-03-19T02:55:47Z"}, {"author": "Eric Rescorla", "text": "

Apparently some of the rooms have human transcription

", "time": "2025-03-19T02:55:51Z"}, {"author": "Eric Rescorla", "text": "

Sure, I can try to speak a little slower

", "time": "2025-03-19T02:55:55Z"}, {"author": "Lorenzo Miniero", "text": "

The transcription here is automated: the only room that has human transcription the whole week is Sala Thai Ballroom

", "time": "2025-03-19T02:56:06Z"}, {"author": "Michael StJohns", "text": "

try being the operative word... :-)

", "time": "2025-03-19T02:56:11Z"}, {"author": "Eric Rescorla", "text": "

@Lorenzo: Thanks, I'm not really aware of what room people are in

", "time": "2025-03-19T02:56:25Z"}, {"author": "Michael StJohns", "text": "

thanks lorenzo..

", "time": "2025-03-19T02:56:27Z"}, {"author": "Robert Moskowitz", "text": "

We have heard you \"try' many times! Just go with the flow, ekr.

", "time": "2025-03-19T02:56:38Z"}, {"author": "Paul Wouters", "text": "

the automation helped me understand the remote speakers

", "time": "2025-03-19T02:56:47Z"}, {"author": "Jonathan Hammell", "text": "

Correction: AI transcription is impressive here.

", "time": "2025-03-19T02:57:01Z"}, {"author": "Martin Thomson", "text": "

the transcription is helping my understand the in-room speakers

", "time": "2025-03-19T02:57:06Z"}, {"author": "Michael StJohns", "text": "

I find the transcription particularly helpful for strong accents..

", "time": "2025-03-19T02:57:10Z"}, {"author": "Eric Rescorla", "text": "

Well, I'm actually just an AI deepfake

", "time": "2025-03-19T02:57:16Z"}, {"author": "Martin Thomson", "text": "

I'm not doing great with some of the accents here

", "time": "2025-03-19T02:57:18Z"}, {"author": "Melchior Aelmans", "text": "

@EKR: lol

", "time": "2025-03-19T02:57:34Z"}, {"author": "Michael StJohns", "text": "

lisa might be amused to find that out..

", "time": "2025-03-19T02:57:41Z"}, {"author": "Robert Moskowitz", "text": "

Or is the AI deepfake really ekr? :)

", "time": "2025-03-19T02:57:45Z"}, {"author": "Martin Thomson", "text": "

we're all stochastic parrots

", "time": "2025-03-19T02:57:49Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

we're all stochastic parrots

\n
\n

philosophical zombies

", "time": "2025-03-19T02:58:09Z"}, {"author": "Robert Moskowitz", "text": "

Why are they always talking about me??? ;)

", "time": "2025-03-19T02:59:07Z"}, {"author": "Eric Rescorla", "text": "

Honestly, I think the place to start here is \"does anyone want this\"

", "time": "2025-03-19T02:59:38Z"}, {"author": "Robert Moskowitz", "text": "

Yes, where is the use case? Is that in the docs anywhere, or is this a research project.

", "time": "2025-03-19T03:00:23Z"}, {"author": "Alexey Melnikov", "text": "

Use cases is the next presentation!

", "time": "2025-03-19T03:00:39Z"}, {"author": "Felix Linker", "text": "

Naive question; just skimmed over the Kerberos Wikipedia article: Kerberos servers know your symmetric key, right?

", "time": "2025-03-19T03:00:49Z"}, {"author": "Robert Moskowitz", "text": "

Thanks, Alexey

", "time": "2025-03-19T03:00:57Z"}, {"author": "Eric Rescorla", "text": "

Felix. Of course

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

I'm still struggling with the use case. As in, I'm not clear on what scenario has requirements that need a new design like this.

", "time": "2025-03-19T03:01:18Z"}, {"author": "Eric Rescorla", "text": "

That's inherent in any symmetric system

", "time": "2025-03-19T03:01:22Z"}, {"author": "Martin Thomson", "text": "

Presumably you can build a secret-sharing system whereby the central system is split into parts that don't know the key.

", "time": "2025-03-19T03:01:55Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

Presumably you can build a secret-sharing system whereby the central system is split into parts that don't know the key.

\n
\n

Yes, though it's probably easier to run N parallel servers and then send one key share through each, which is what DSKE does

", "time": "2025-03-19T03:02:30Z"}, {"author": "Robert Moskowitz", "text": "

That is done in journalist protection systems?

", "time": "2025-03-19T03:02:31Z"}, {"author": "Valery Smyslov", "text": "

Isn't this exactly what DSKE does?

", "time": "2025-03-19T03:02:37Z"}, {"author": "Eric Rescorla", "text": "

(But which, you could also do with Kerberos)

", "time": "2025-03-19T03:02:38Z"}, {"author": "Eric Rescorla", "text": "

Valery Smyslov said:

\n
\n

Isn't this exactly what DSKE does?

\n
\n

Yes. But if one thought that something that is conceptually like universal Kerberos, but just wasn't strong enough, the obvious thing to do is to extend kerberos

", "time": "2025-03-19T03:03:10Z"}, {"author": "Martin Thomson", "text": "

Right, so in what way is this better than N-way Kerberos?

", "time": "2025-03-19T03:03:14Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

Right, so in what way is this better than N-way Kerberos?

\n
\n

It's not.

", "time": "2025-03-19T03:03:30Z"}, {"author": "Felix Linker", "text": "

Eric Rescorla said:

\n
\n

Felix. Of course

\n
\n

Great thanks. Then there are indeed technical differences between Kerberos and DSKE because DSKE claims that server will not know symmetric key. But I think it's mostly irrelevant. The draft assumes pre-shared symmetric key between parties, which trivializes the problem. It seems like a synchronization protocol to do key derivation to me. (In style of symmetric ratchet.)

\n

It's misleading to call this \"key exchange.\"

", "time": "2025-03-19T03:03:30Z"}, {"author": "Christian Huitema", "text": "

More like, you have key exchanges between 2 clients and N servers, which get secure if at least M of N can be trusted.

", "time": "2025-03-19T03:03:35Z"}, {"author": "Stuart Card", "text": "

I recall reading papers on SMPC for key generation years ago. It would take me a while to find them in my archives.

", "time": "2025-03-19T03:03:38Z"}, {"author": "Eric Rescorla", "text": "

Yes, they assume you have a pre-shared key with the DSKE

", "time": "2025-03-19T03:03:56Z"}, {"author": "Stephen Farrell", "text": "

inter-realm keberos (or any moral equivalent) isn't simpler would be my guess

", "time": "2025-03-19T03:03:58Z"}, {"author": "Thom Wiggers", "text": "

was there an IPR disclosure by the way?

", "time": "2025-03-19T03:04:06Z"}, {"author": "Thom Wiggers", "text": "

https://patents.google.com/patent/US11991269B1/en

", "time": "2025-03-19T03:04:21Z"}, {"author": "Eric Rescorla", "text": "

Stephen Farrell said:

\n
\n

inter-realm keberos (or any moral equivalent) isn't simpler would be my guess

\n
\n

Well, the only reason this isn't inter-realm is that they have decreed that there is a universal server

", "time": "2025-03-19T03:04:26Z"}, {"author": "Thom Wiggers", "text": "

I may just be failing to search correctly

", "time": "2025-03-19T03:04:29Z"}, {"author": "Thom Wiggers", "text": "

or maybe that's a different variant that they've not proposed yet in which case I haven't said anything

", "time": "2025-03-19T03:05:11Z"}, {"author": "Eric Rescorla", "text": "

Felix Linker said:

\n
\n

Eric Rescorla said:

\n
\n

Felix. Of course

\n
\n

Great thanks. Then there are indeed technical differences between Kerberos and DSKE because DSKE claims that server will not know symmetric key. But I think it's mostly irrelevant. The draft assumes pre-shared symmetric key between parties, which trivializes the problem. It seems like a synchronization protocol to do key derivation to me. (In style of symmetric ratchet.)

\n

It's misleading to call this \"key exchange.\"

\n
\n

Well the reason that the DSKE server doesn't know the symmetric key is that it knows a share of the symmetric key

", "time": "2025-03-19T03:05:28Z"}, {"author": "Stephen Farrell", "text": "

@ekr: \"isn't inter-realm\" is a claim I've not bought into so far

", "time": "2025-03-19T03:05:37Z"}, {"author": "Michael StJohns", "text": "

aka \"The tyranny of the light switch\"

", "time": "2025-03-19T03:05:47Z"}, {"author": "Felix Linker", "text": "

You can achieve forward-secrecy with symmetric keys. My god. I'm getting nerd-sniped.

", "time": "2025-03-19T03:06:55Z"}, {"author": "Michael StJohns", "text": "

@ekr \"the symmetric key\" refers to which symmetric key exactly? client to kdc?

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

to be clear: a \"kerberos is old horrible stuff (with ASN.1)\" would be a different and more apt (though not yet winning) argument

", "time": "2025-03-19T03:06:56Z"}, {"author": "Martin Thomson", "text": "

This is a good point: in which domain is it desirable to drop PFS, for example?

", "time": "2025-03-19T03:07:20Z"}, {"author": "Thom Wiggers", "text": "

Felix Linker said:

\n
\n

You can achieve forward-secrecy with symmetric keys. My god. I'm getting nerd-sniped.

\n
\n

I didn't want to get into puncturable PRFs

", "time": "2025-03-19T03:07:53Z"}, {"author": "Robert Moskowitz", "text": "

aviation telemetry data

", "time": "2025-03-19T03:07:57Z"}, {"author": "Felix Linker", "text": "

Thom Wiggers said:

\n
\n

Felix Linker said:

\n
\n

You can achieve forward-secrecy with symmetric keys. My god. I'm getting nerd-sniped.

\n
\n

I didn't want to get into puncturable PRFs

\n
\n

Simple symmetric ratchet achieves PFSs and doesn't need puncturable crypto.

", "time": "2025-03-19T03:08:24Z"}, {"author": "Stephen Farrell", "text": "

last speaker seemed to be arguing for another Bof?

", "time": "2025-03-19T03:08:50Z"}, {"author": "Felix Linker", "text": "

But I agree with your point. Asymmetric crypto is good. Real argument could at most be resource constraints of PQC.

", "time": "2025-03-19T03:08:58Z"}, {"author": "Thom Wiggers", "text": "

@Felix Linker right; but in systems like this you bootstrap everything from a long-term secret

", "time": "2025-03-19T03:09:01Z"}, {"author": "Thom Wiggers", "text": "

so in that sense PFS is difficult

", "time": "2025-03-19T03:09:18Z"}, {"author": "Thom Wiggers", "text": "

https://eprint.iacr.org/2021/702 is a nice paper that does achieve PFS (but with \"fancy constructions\")

", "time": "2025-03-19T03:09:51Z"}, {"author": "Michael StJohns", "text": "

if you moved up 10k feet, what would the BOF question be? (e.g not \"should we do dske?\" but perhaps \"what are the requirements for a symmetric key establishment system in a PQ world?\") ??

", "time": "2025-03-19T03:09:53Z"}, {"author": "Martin Thomson", "text": "

This needs to be not just use cases, but use cases and an analysis of why existing protocols don't work well enough AND a demonstration that we know how to solve the problems that arise.

", "time": "2025-03-19T03:09:53Z"}, {"author": "Melchior Aelmans", "text": "

@Stephen, there will be 2 potential protocol presentations SKEX could work on

", "time": "2025-03-19T03:09:54Z"}, {"author": "Christian Huitema", "text": "

We should get rid of TCP-AO and use QUIC instead...

", "time": "2025-03-19T03:10:10Z"}, {"author": "Stephen Farrell", "text": "

are TCP-AO and MACSEC really good arguments here? be nice if they happened more, but not clear better key mgnt is what's holding 'em back

", "time": "2025-03-19T03:10:13Z"}, {"author": "Alexey Melnikov", "text": "

I unlocked the queue, but please wait till the end of the use cases presentation (about 10 minutes)

", "time": "2025-03-19T03:11:13Z"}, {"author": "Christian Huitema", "text": "

People who are sticking to 50 years old software are going to just install a new fancy protocol?

", "time": "2025-03-19T03:11:19Z"}, {"author": "Stephen Farrell", "text": "

also: where'e the immediate CRQC threat with TCP-AO?

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

TCP-AO has usage and operational practices that make this sort of thing unnecessary, as I understand it

", "time": "2025-03-19T03:11:32Z"}, {"author": "Martin Thomson", "text": "

Here's a thing: most of the PQ algorithms are cheaper than ECC

", "time": "2025-03-19T03:11:59Z"}, {"author": "Martin Thomson", "text": "

They require more bytes on the wire, but not inordinately more.

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

if you have a 20 byte/s link they're really not

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

@martin, inordinately more for spectrum I am stuck with.

", "time": "2025-03-19T03:12:49Z"}, {"author": "Thom Wiggers", "text": "

also data transmission is surprisingly expensive on devices with batteries

", "time": "2025-03-19T03:12:52Z"}, {"author": "Thom Wiggers", "text": "

and antennas

", "time": "2025-03-19T03:13:05Z"}, {"author": "Stephen Farrell", "text": "

IMO reason Kerberos failed vs. PKI 30 years ago: clock sync

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

sure, Ekr's point is a better response there

", "time": "2025-03-19T03:13:31Z"}, {"author": "Michael StJohns", "text": "

is \"must be able to supply keys to TLS in a global internet\" a requirement?

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

MSJ: I really hope not

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

didn't AGL already write a blog about that

", "time": "2025-03-19T03:14:00Z"}, {"author": "Thom Wiggers", "text": "

https://www.imperialviolet.org/2024/04/07/letskerberos.html

", "time": "2025-03-19T03:14:20Z"}, {"author": "Eric Rescorla", "text": "

To be clear, people don't even want TCP-AO when they have preprovisioned keys!

", "time": "2025-03-19T03:14:24Z"}, {"author": "Eric Rescorla", "text": "

Like, they don't want to go from TCP-MD5 to TCP-AO

", "time": "2025-03-19T03:14:34Z"}, {"author": "Michael StJohns", "text": "

@mt - so this is limited to implementation within a very limited domain and possibly specific protocols (yet to be specified)....

", "time": "2025-03-19T03:14:44Z"}, {"author": "Stephen Farrell", "text": "

MACSEC is interesting but IIUC doesn't generally involve previously unknown-to-one-another peers

", "time": "2025-03-19T03:14:57Z"}, {"author": "Randy Bush", "text": "

4808

", "time": "2025-03-19T03:15:01Z"}, {"author": "Martin Thomson", "text": "

and yet, those limited domains already have solutions (as Tiru is pointing out)

", "time": "2025-03-19T03:15:06Z"}, {"author": "Eric Rescorla", "text": "

And to be clear, I'm an author of AO, so it gives me no pleasure to say that nobody wants it

", "time": "2025-03-19T03:15:19Z"}, {"author": "Stephen Farrell", "text": "

better key mgmt for MACSEC would be a good thing though, not sure it needs to scale to Internet-scale though

", "time": "2025-03-19T03:15:49Z"}, {"author": "Stephen Farrell", "text": "

no unkonwn peers => MACSEC is simple, lose the precondition and it's no longer simpler I'd say

", "time": "2025-03-19T03:16:50Z"}, {"author": "Eric Rescorla", "text": "

I do agree that it's the case that key management is hard.

", "time": "2025-03-19T03:16:54Z"}, {"author": "Christian Huitema", "text": "

This is the VC pitch page. It goes with the patent...

", "time": "2025-03-19T03:16:55Z"}, {"author": "Jonathan Hoyland", "text": "

Does the protocol rely on a non-collusion assumption between the key servers?

", "time": "2025-03-19T03:17:00Z"}, {"author": "Michael StJohns", "text": "

patent?

", "time": "2025-03-19T03:17:03Z"}, {"author": "Michael StJohns", "text": "

of course there is...

", "time": "2025-03-19T03:17:14Z"}, {"author": "Eric Rescorla", "text": "

@Jonathan Hoyland yes, that no more than M -N are compromised

", "time": "2025-03-19T03:17:16Z"}, {"author": "Jonathan Hammell", "text": "

MACsec Dynamic CAK mode relies upon public key authentication in order to derive the symmetric CAK.

", "time": "2025-03-19T03:18:10Z"}, {"author": "Eric Rescorla", "text": "

I don't understand why one would think that this thing is easier than PKI

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

my failed idea #674: https://datatracker.ietf.org/doc/html/draft-farrelll-mpls-opportunistic-encrypt-05 :-)

", "time": "2025-03-19T03:18:29Z"}, {"author": "Jonathan Hoyland", "text": "

OK, I could be convinced that you could describe a system where you get an authentication property.

", "time": "2025-03-19T03:18:40Z"}, {"author": "Jonathan Hoyland", "text": "

If you rely on an M-N threshold assumption.

", "time": "2025-03-19T03:19:02Z"}, {"author": "Michael StJohns", "text": "

I'm having flashbacks to doing morning keying of a KG34 circa 1980

", "time": "2025-03-19T03:19:08Z"}, {"author": "Thom Wiggers", "text": "

is he saying \"if you need to go from an unencrypted protocol to an encrypted protocol, this is a change\"?

", "time": "2025-03-19T03:19:09Z"}, {"author": "Thom Wiggers", "text": "

(I don't know what MPLS is)

", "time": "2025-03-19T03:19:17Z"}, {"author": "Stephen Farrell", "text": "

MPLS is layer 2.5

", "time": "2025-03-19T03:19:29Z"}, {"author": "Eric Rescorla", "text": "

I think what he's saying is \"to go from unencrypted to encrypted is complicated because of PKI\". Which, you know, is probably true. But the question is why you would think that this thing is simpler

", "time": "2025-03-19T03:19:42Z"}, {"author": "Yoav Nir", "text": "

Wait. If they're not challenging PKI, what are they doing? The certificate part of IPsec (or TLS for that matter) is the same regardless of the bandwidth. After the handshake you use the generated keys for a lot of data

", "time": "2025-03-19T03:19:43Z"}, {"author": "Thom Wiggers", "text": "

@Stephen Farrell can you ELIC (explain like i'm a cryptographer)

", "time": "2025-03-19T03:19:50Z"}, {"author": "Stephen Farrell", "text": "

I'm not saying my failed idea ought be resurrected mind

", "time": "2025-03-19T03:19:58Z"}, {"author": "Jonathan Hoyland", "text": "

Because if we're talking minicrypt world you can't do much without some stronger security assumption.

", "time": "2025-03-19T03:20:34Z"}, {"author": "Robert Moskowitz", "text": "

MACsec uses 802.1X to get keys. Now what is behind that?

", "time": "2025-03-19T03:20:40Z"}, {"author": "Stephen Farrell", "text": "

@thom: sorry, I mostly forget it:-)

", "time": "2025-03-19T03:20:58Z"}, {"author": "Thom Wiggers", "text": "

I meant what layer 2.5 is

", "time": "2025-03-19T03:21:15Z"}, {"author": "Robert Moskowitz", "text": "

And Andy Malis and I did MACsec for Verizon a decade ago. What has changed?

", "time": "2025-03-19T03:21:21Z"}, {"author": "Christian Huitema", "text": "

In theory, you can plug multiple EAP protocols in 802.1x. Including Kerberos...

", "time": "2025-03-19T03:21:24Z"}, {"author": "A.J. Stein", "text": "

What is the \"federal infrastructure\" the presenter alludes to?

", "time": "2025-03-19T03:21:28Z"}, {"author": "Stephen Farrell", "text": "

2.5 = 3+2/2

", "time": "2025-03-19T03:21:35Z"}, {"author": "Michael StJohns", "text": "

@aj - virtual wires...

", "time": "2025-03-19T03:21:47Z"}, {"author": "Thom Wiggers", "text": "

surely 3 + 2/2 = 4

", "time": "2025-03-19T03:21:50Z"}, {"author": "Stephen Farrell", "text": "

MPLS is kinda above layer 2 but below IP layer (sorta)

", "time": "2025-03-19T03:22:02Z"}, {"author": "Yoav Nir", "text": "

For a not-WG-forming BOF, we're referring to this as \"this WG\" a lot

", "time": "2025-03-19T03:22:25Z"}, {"author": "Eric Rescorla", "text": "

yes

", "time": "2025-03-19T03:22:29Z"}, {"author": "A.J. Stein", "text": "

We talked about NIAP, then FIPS, and then talked about I guess US network infra then, Michael. I just find the desire to speak for that stuff as IETF's area of interest, one or both of those thematically, as weird.

", "time": "2025-03-19T03:22:45Z"}, {"author": "Jonathan Hammell", "text": "

Kerberos-based EAP? Is there a spec for that?

", "time": "2025-03-19T03:22:48Z"}, {"author": "Stephen Farrell", "text": "

(I sinned wrt brackets)

", "time": "2025-03-19T03:23:12Z"}, {"author": "Christian Huitema", "text": "

You can write one... But there was LEAP, for example.

", "time": "2025-03-19T03:23:27Z"}, {"author": "Yoav Nir", "text": "

There's Kerberos for IPsec

", "time": "2025-03-19T03:23:54Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

https://datatracker.ietf.org/doc/rfc3031/

", "time": "2025-03-19T03:23:57Z"}, {"author": "Robert Moskowitz", "text": "

Who is talking right now?

", "time": "2025-03-19T03:23:57Z"}, {"author": "Eric Rescorla", "text": "

There used to be Kerberos for TLS, too

", "time": "2025-03-19T03:24:05Z"}, {"author": "Thom Wiggers", "text": "

Managing 50000 certificates is surely a lot easier than managing 50000^2 symmetric keys

", "time": "2025-03-19T03:24:05Z"}, {"author": "Martin Thomson", "text": "

I don't get how the \"one little hiccup\" argument doesn't apply doubly to symmetric key distribution

", "time": "2025-03-19T03:24:12Z"}, {"author": "Stephen Farrell", "text": "

MACSEC key mgmt would be IEEE 802 though?

", "time": "2025-03-19T03:24:24Z"}, {"author": "Martin Thomson", "text": "

As Thom says, the fragility of a symmetric key distribution is orders of magnitude worse

", "time": "2025-03-19T03:24:37Z"}, {"author": "Robert Moskowitz", "text": "

For Uncrewed Aircraft Systems, we need for millions of devices and certs. See DRIP work.

", "time": "2025-03-19T03:24:43Z"}, {"author": "Martin Thomson", "text": "

How do you manage revocation?

", "time": "2025-03-19T03:24:45Z"}, {"author": "David Black", "text": "

Don't need to reinvent security to deal with hiccups. There are ways to ensure that stuff gets through w/o hiccups.

", "time": "2025-03-19T03:24:47Z"}, {"author": "Jonathan Hoyland", "text": "

@Thom Wiggers there aren't that many keys, the keys are all derived from pairwise keys shared with the trusted key servers

", "time": "2025-03-19T03:24:48Z"}, {"author": "Michael StJohns", "text": "

@aj - almost all gov't buy a virtual network or 20 layered over the telco (for want of a better term) infrastructure... logically isolated from the hoi polloi...

", "time": "2025-03-19T03:25:05Z"}, {"author": "Yoav Nir", "text": "

Eric Rescorla said:

\n
\n

There used to be Kerberos for TLS, too

\n
\n

It's telling that despite all its faults, in both cases people chose to use PKI rather than Kerberos.

", "time": "2025-03-19T03:25:05Z"}, {"author": "Eric Rescorla", "text": "

This slide is all fine, but like why does it say \"DSKE\" and not \"YANG\"

", "time": "2025-03-19T03:25:22Z"}, {"author": "Thom Wiggers", "text": "

@Jonathan Hoyland eh, I guess those derived keys are still managed

", "time": "2025-03-19T03:25:28Z"}, {"author": "Stephen Farrell", "text": "

I'd be surprised but happy if MACSEC speakers needed to setup keys with previously unknown parties, is that the claim?

", "time": "2025-03-19T03:25:30Z"}, {"author": "Eric Rescorla", "text": "

@Stephen Farrell That's what I don't see

", "time": "2025-03-19T03:25:40Z"}, {"author": "Michael StJohns", "text": "

@yoav - kerberos had its time and was a good solution for the problem when created...

", "time": "2025-03-19T03:25:43Z"}, {"author": "Jonathan Hoyland", "text": "

It's a tradeoff between generating new keys (i.e. roundtrips) and storing old keys.

", "time": "2025-03-19T03:25:57Z"}, {"author": "Michael StJohns", "text": "

@yoav... that time was many decades ago.. :-)

", "time": "2025-03-19T03:26:50Z"}, {"author": "Yoav Nir", "text": "

Michael StJohns said:

\n
\n

@yoav - kerberos had its time and was a good solution for the problem when created...

\n
\n

Not claiming otherwise. But RFC 4430 never took off for IPsec, and Kerberos for TLS isn't used either

", "time": "2025-03-19T03:26:56Z"}, {"author": "Robert Moskowitz", "text": "

One of the problems is outside of here, wrt to PKI. FAA just fought a battle for setting up a new PKI and avoided a 3year/$250k bill and did it in 2yr/$100K. Not scaliable...

", "time": "2025-03-19T03:27:06Z"}, {"author": "Michael StJohns", "text": "

I knew we were going to get to KG34 keying.. :-)

", "time": "2025-03-19T03:27:31Z"}, {"author": "A.J. Stein", "text": "

I am familiar Michael with the government domain, I don't see why it is relevant or why we want to make it so. It doesn't make this stuff more approachable or palatable imo, but that's me.

", "time": "2025-03-19T03:27:44Z"}, {"author": "Stephen Farrell", "text": "

soldier with paper == STANAG 4406 (old email stuff:-)

", "time": "2025-03-19T03:27:49Z"}, {"author": "Michael StJohns", "text": "

@aj - I think it keeps getting mentioned because each are a somewhat constrained domain... unlike the internet as a whole.

", "time": "2025-03-19T03:28:36Z"}, {"author": "Eric Rescorla", "text": "

I mean if the theory is \"we just want to push keys to all of our devices\", that's basically a standard management problem

", "time": "2025-03-19T03:28:54Z"}, {"author": "Eric Rescorla", "text": "

The solution that is being pitched here is, as Stephen says \"let anyone talk to anyone else\"

", "time": "2025-03-19T03:29:12Z"}, {"author": "Michael StJohns", "text": "

@stephen - about once a week I had to wander from my office down to another office and sign for new key material ... all of which originated at NSA

", "time": "2025-03-19T03:29:44Z"}, {"author": "Stephen Farrell", "text": "

@msj: I never saw a key, just wrote bad code to (ab)use 'em:-)

", "time": "2025-03-19T03:30:34Z"}, {"author": "Deb Cooley", "text": "

@MSJ but for the rest of the time the key updated.

", "time": "2025-03-19T03:30:48Z"}, {"author": "Eric Rescorla", "text": "

Deb Cooley said:

\n
\n

@MSJ but for the rest of the time the key updated.

\n
\n

@Deb Cooley did you use dice or coins to generate those keys?

", "time": "2025-03-19T03:31:04Z"}, {"author": "Deb Cooley", "text": "

One would hope that stuffing a key into a device only happens once.

", "time": "2025-03-19T03:31:17Z"}, {"author": "Deb Cooley", "text": "

The rest of the time it updates.

", "time": "2025-03-19T03:31:32Z"}, {"author": "David Black", "text": "

double encryption is not inherently bad/wrong.

", "time": "2025-03-19T03:31:35Z"}, {"author": "Martin Thomson", "text": "

This particular use case is clearly a network management one, as far as I can see. So ... YANG?

", "time": "2025-03-19T03:32:07Z"}, {"author": "Eric Rescorla", "text": "

Or Netconf

", "time": "2025-03-19T03:33:08Z"}, {"author": "Stephen Farrell", "text": "

too early putative BoF conclusion: maybe there's a new key mgmt need here but it's far from clear and the reqs for that (incl. threat model & model arch) would need elucidating a lot more

", "time": "2025-03-19T03:34:28Z"}, {"author": "Felix Linker", "text": "

Good to hear that people using PKIs won't be hunted down

", "time": "2025-03-19T03:34:38Z"}, {"author": "Michael StJohns", "text": "

@deb - the key entry for a KG34 involved using a stylus to move a set of permutation contacts to specific locations. You then installed the key tray into the KG34 - carefully. If you did it incautiously, a spring loaded bar would trigger and zeroize the key contacts.. requiring you to repeat the process.... this happened to me more than a few times...

", "time": "2025-03-19T03:34:49Z"}, {"author": "Michael StJohns", "text": "

@deb - the kg34 did not have a OTA mode for key update... I had to rekey it daily.

", "time": "2025-03-19T03:35:40Z"}, {"author": "Stephen Farrell", "text": "

/me claims to be ahead of fashion:-) https://datatracker.ietf.org/doc/html/draft-farrelll-mpls-opportunistic-encrypt-05

", "time": "2025-03-19T03:35:50Z"}, {"author": "Deb Cooley", "text": "

@MSJ, so this would be better, no?

", "time": "2025-03-19T03:36:19Z"}, {"author": "Martin Thomson", "text": "

Why are we suddenly talking about encrypting MPLS?

", "time": "2025-03-19T03:36:57Z"}, {"author": "Yoav Nir", "text": "

The discussion is swinging rapidly from lightbulbs to Internet backhaul

", "time": "2025-03-19T03:37:35Z"}, {"author": "Stephen Farrell", "text": "

MPLS \"not encryptable\": meh - but to be fair turning on crypto at that layer is non-trivial so the right answer might be non-obvious

", "time": "2025-03-19T03:37:39Z"}, {"author": "Robert Moskowitz", "text": "

Norm Finn said this back in '03. MACsec addresses the risk and liabilities of the network providers.

", "time": "2025-03-19T03:37:40Z"}, {"author": "Wim Henderickx", "text": "

There is 2 different set of use cases discussed here. Diego talked about IOT devices and Hooman talks about infrastructure protection.

", "time": "2025-03-19T03:37:52Z"}, {"author": "Robert Moskowitz", "text": "

TLS is about risks for the application.

", "time": "2025-03-19T03:38:10Z"}, {"author": "Michael StJohns", "text": "

@deb... maybe.

", "time": "2025-03-19T03:38:11Z"}, {"author": "Kathleen Moriarty", "text": "

@Martin - people use it for security reasons or so they think. VLANs are not protected and people talk about them/use them as if it is a secure option. Hence Stephen & Adrian's draft and this

", "time": "2025-03-19T03:38:13Z"}, {"author": "Eric Rescorla", "text": "

As far as I can tell, the only overlap with the DSKE stuff is \"PSK\"

", "time": "2025-03-19T03:38:24Z"}, {"author": "Stephen Farrell", "text": "

doesn't seem very credible that MPLS operators can't deal with a PKI

", "time": "2025-03-19T03:38:54Z"}, {"author": "Martin Thomson", "text": "

Right, that's like saying they are the same because they include bits and bytes.

", "time": "2025-03-19T03:39:01Z"}, {"author": "Eric Rescorla", "text": "

Wait, if we're just typing in the keys, I don't understand why we need a protocol

", "time": "2025-03-19T03:39:22Z"}, {"author": "Jonathan Hoyland", "text": "

256 hex characters, that's a long key.

", "time": "2025-03-19T03:39:30Z"}, {"author": "Robert Moskowitz", "text": "

Cost and time and auditors for a network provider to bring in PKI

", "time": "2025-03-19T03:39:34Z"}, {"author": "Stephen Farrell", "text": "

configuring a ciphersuite is maybe easier than LSP labels

", "time": "2025-03-19T03:39:39Z"}, {"author": "Thom Wiggers", "text": "

I think he means the keys to the distribution center?

", "time": "2025-03-19T03:39:42Z"}, {"author": "Christian Huitema", "text": "

Wi-Fi security with 802.1x has been doing distribution of PSK for a long time, using 802.1x, Radius and EAP. WIth lots of EAp options.

", "time": "2025-03-19T03:39:44Z"}, {"author": "Felix Linker", "text": "

Eric Rescorla said:

\n
\n

Wait, if we're just typing in the keys, I don't understand why we need a protocol

\n
\n

I think that's the point I tried to make earlier :)

", "time": "2025-03-19T03:39:44Z"}, {"author": "Stephen Farrell", "text": "

type in longer keys should work - bigger keyboards? :-)

", "time": "2025-03-19T03:40:15Z"}, {"author": "Eric Rescorla", "text": "

Felix Linker said:

\n
\n

Eric Rescorla said:

\n
\n

Wait, if we're just typing in the keys, I don't understand why we need a protocol

\n
\n

I think that's the point I tried to make earlier :)

\n
\n

Well, that's not what the DSKE thing is doing. But my point here is that there is a disconnect between this presentation and the previous one

", "time": "2025-03-19T03:40:24Z"}, {"author": "Robert Moskowitz", "text": "

The problem here is at network levels 8 and 9.

", "time": "2025-03-19T03:40:26Z"}, {"author": "Stuart Card", "text": "

I believe he was talking about typing in the key at the root of the tree on the current slide, not every pair of router ports.

", "time": "2025-03-19T03:40:27Z"}, {"author": "Martin Thomson", "text": "

Bob: why do you think that auditing a system based on PSKs would be easier than one based on asymmetric keys?

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

fwiw: Adrian Farrel also thought about this issue a decade ago - might be worth asking him about this

", "time": "2025-03-19T03:41:12Z"}, {"author": "Robert Moskowitz", "text": "

Because the auditors already own PKi and charge lots. They will take years to figure out how to make money on this new stuff.

", "time": "2025-03-19T03:41:19Z"}, {"author": "Martin Thomson", "text": "

Not a good reason

", "time": "2025-03-19T03:41:54Z"}, {"author": "Robert Moskowitz", "text": "

But it stops the managers.

", "time": "2025-03-19T03:42:07Z"}, {"author": "Stephen Farrell", "text": "

what's MKA? or did he say that?

", "time": "2025-03-19T03:42:14Z"}, {"author": "Eric Rescorla", "text": "

I didn't hear

", "time": "2025-03-19T03:42:18Z"}, {"author": "Eric Rescorla", "text": "

Apparently MACSec Key Agreement

", "time": "2025-03-19T03:42:43Z"}, {"author": "Thom Wiggers", "text": "

MKA is on the slides

", "time": "2025-03-19T03:42:47Z"}, {"author": "Martin Thomson", "text": "

https://community.cisco.com/t5/networking-knowledge-base/mka-macsec-key-agreement-exchange-on-the-wire/ta-p/4436083

", "time": "2025-03-19T03:42:53Z"}, {"author": "Melchior Aelmans", "text": "

https://www.ietf.org/archive/id/draft-hb-intarea-eap-mka-00.html

", "time": "2025-03-19T03:42:53Z"}, {"author": "Stephen Farrell", "text": "

you expect us to read the slides? :-)

", "time": "2025-03-19T03:43:05Z"}, {"author": "Melchior Aelmans", "text": "

:D

", "time": "2025-03-19T03:43:12Z"}, {"author": "Eric Rescorla", "text": "

I am also now kind of confused. Because the point being made right now is totally reasonable.

", "time": "2025-03-19T03:43:21Z"}, {"author": "Eric Rescorla", "text": "

But it has nothing to do with key distribution

", "time": "2025-03-19T03:43:30Z"}, {"author": "Eric Rescorla", "text": "

It's about handshake

", "time": "2025-03-19T03:43:36Z"}, {"author": "Stephen Farrell", "text": "

work to do key mgmt for MACSEC would be good - not clear if here or IEEE but good nonetheless

", "time": "2025-03-19T03:43:50Z"}, {"author": "Jonathan Hoyland", "text": "

I'm just waiting to get to the protocol piece. Who cares about the use cases if we don't have nice security proofs :P

", "time": "2025-03-19T03:43:55Z"}, {"author": "Martin Thomson", "text": "

I'm completely lost at this point. I came in with insufficient information (the agenda was useless), but now that I have more, I'm just more confused about what the scope would be

", "time": "2025-03-19T03:44:38Z"}, {"author": "Stephen Farrell", "text": "

I do recall routing folk hating AEADs 'cause of the tag length, so would not be surprised if they hate PQ 'cause of sizes (not that they said that, but maybe...)

", "time": "2025-03-19T03:45:01Z"}, {"author": "Eric Rescorla", "text": "

What is being discussed now sounds much more (conceptually) like the TLS-PSK handshake

", "time": "2025-03-19T03:45:08Z"}, {"author": "A.J. Stein", "text": "

\"Nothing too complicated\" is my favorite phrase in IETF, but also the one that induces the most fear.

", "time": "2025-03-19T03:45:12Z"}, {"author": "Felix Linker", "text": "

It seems like every time (1) someone doubts a use case's validity, (2) it's being said that that use case was only an example and (3) a new one is brought up so that we can go back to (1), hm?

\n

Also, I'm super confused about all the transport discussions. That could be because I'm just a security guy (but this looked like a security \"protocol\").

", "time": "2025-03-19T03:45:27Z"}, {"author": "Stephen Farrell", "text": "

their issue was they had setup tunnels carefully tuned to traffic and adding more crypto bytes (AEAD tags or whatever) upset their calculations - was never sure if that was a real thing or nto

", "time": "2025-03-19T03:46:06Z"}, {"author": "Michael StJohns", "text": "

ok - that was a different comment..

", "time": "2025-03-19T03:46:33Z"}, {"author": "Michael StJohns", "text": "

and this is still not a wg...

", "time": "2025-03-19T03:46:57Z"}, {"author": "Yoav Nir", "text": "

A.J. Stein said:

\n
\n

\"Nothing too complicated\" is my favorite phrase in IETF, but also the one that induces the most fear.

\n
\n

It's tempting the gods when you call your protocol something that starts with \"lightweight\" or \"simple\". They punish you with a 200+ page RFC.

", "time": "2025-03-19T03:47:18Z"}, {"author": "A.J. Stein", "text": "

Yoav gets it! :-)

", "time": "2025-03-19T03:47:35Z"}, {"author": "Stephen Farrell", "text": "

if someone could describe the hump better that may help

", "time": "2025-03-19T03:47:39Z"}, {"author": "Eric Rescorla", "text": "

Well, I mean we have a big pile of protocols that bootstrap up from a symmetric key

", "time": "2025-03-19T03:47:39Z"}, {"author": "Jonathan Hoyland", "text": "

I mean, this is literally the worst possible argument. We want a fig leaf to pass some government audit, not to provide any actual security.

", "time": "2025-03-19T03:47:40Z"}, {"author": "Stephen Farrell", "text": "

but cost of PLI << cost of ASICs?

", "time": "2025-03-19T03:48:10Z"}, {"author": "Stephen Farrell", "text": "

s/PLI/PKI/

", "time": "2025-03-19T03:48:22Z"}, {"author": "Thom Wiggers", "text": "

You can run a private PKI without paying anything to anyone

", "time": "2025-03-19T03:48:59Z"}, {"author": "Martin Thomson", "text": "

Thom: presumably you need expertise to build a good PKI

", "time": "2025-03-19T03:49:24Z"}, {"author": "Stephen Farrell", "text": "

meh, the kinds of orgs we're talking about spend $1M just to disagree about naming

", "time": "2025-03-19T03:49:31Z"}, {"author": "Jonathan Hoyland", "text": "

@Martin Thomson Not if your only goal is a fig leaf. If you don't care about security then what does it matter?

", "time": "2025-03-19T03:49:56Z"}, {"author": "Thom Wiggers", "text": "

Paying the people to run a Kerberos/DSKE/whatever-this-will-be is surely also very expensive?

", "time": "2025-03-19T03:50:49Z"}, {"author": "Martin Thomson", "text": "

Right, if this is a smokescreen, that's not something we should be doing at all. But if you are going to build a real PKI, then the necessary costs are pretty significant. Even if you don't engage auditors.

", "time": "2025-03-19T03:51:02Z"}, {"author": "Stephen Farrell", "text": "

the PKI-too-hard argument is not convincing for me, there just are ways to do that stuff in the least bad way which is tolerable

", "time": "2025-03-19T03:51:04Z"}, {"author": "Martin Thomson", "text": "

Thom: absolutely: a system like this is not fundamentally different in terms of costs

", "time": "2025-03-19T03:51:26Z"}, {"author": "Eric Rescorla", "text": "

The DSKE thing is basically isomorphic to PKI

", "time": "2025-03-19T03:51:42Z"}, {"author": "Thom Wiggers", "text": "

that is also my interpretation

", "time": "2025-03-19T03:51:58Z"}, {"author": "Martin Thomson", "text": "

Worse, something that uses symmetric keys probably shifts costs to places that you don't realize, like endpoint security

", "time": "2025-03-19T03:52:06Z"}, {"author": "Eric Rescorla", "text": "

Yes.

", "time": "2025-03-19T03:52:11Z"}, {"author": "Alexey Melnikov", "text": "

We were planning 2 presentations on \"Unmediated Symmetric Key Establishment\" and \"Distributed Symmetric Key Establishment\" before asking \"is it worth doing, etc\". Is it worth having these presentations?

", "time": "2025-03-19T03:52:17Z"}, {"author": "Eric Rescorla", "text": "

And, for instance, you don't have transparency

", "time": "2025-03-19T03:52:20Z"}, {"author": "Stephen Farrell", "text": "

yeah I don't see symmetric OPEX being less than asymmetric (if done equally well/badly)

", "time": "2025-03-19T03:52:33Z"}, {"author": "Martin Thomson", "text": "

no transparency, revocation is weird

", "time": "2025-03-19T03:52:35Z"}, {"author": "Martin Thomson", "text": "

state space for keys scales with the number of peers

", "time": "2025-03-19T03:52:51Z"}, {"author": "Michael StJohns", "text": "

and then you have an insider problem with who has the key...

", "time": "2025-03-19T03:52:54Z"}, {"author": "Martin Thomson", "text": "

you have to deal with new attacks...

", "time": "2025-03-19T03:53:09Z"}, {"author": "Stephen Farrell", "text": "

I think the speaker is making wrong assumptions about the critique

", "time": "2025-03-19T03:53:14Z"}, {"author": "Eric Rescorla", "text": "

OK, if I joined after it's closed, that's OK

", "time": "2025-03-19T03:53:28Z"}, {"author": "Yaron Sheffer", "text": "

Thanks EKR.

", "time": "2025-03-19T03:53:49Z"}, {"author": "Stephen Farrell", "text": "

post-compromise is a good point

", "time": "2025-03-19T03:54:53Z"}, {"author": "A.J. Stein", "text": "

It seems we didn't want to hear the full point before responding to it.

", "time": "2025-03-19T03:55:11Z"}, {"author": "Stephen Farrell", "text": "

ah, back to QKD!

", "time": "2025-03-19T03:55:37Z"}, {"author": "Eric Rescorla", "text": "

The key point is the one Chris just made, about doing a new public key exchange

", "time": "2025-03-19T03:56:42Z"}, {"author": "Jonathan Hoyland", "text": "

100%

", "time": "2025-03-19T03:56:54Z"}, {"author": "Stephen Farrell", "text": "

agree, unless you have/believe-in QKD

", "time": "2025-03-19T03:57:01Z"}, {"author": "Robert Moskowitz", "text": "

I have to deal with a new cert for use for 20min flight. Then another cert for the next 20min flight. Repeat 2M times.

", "time": "2025-03-19T03:57:05Z"}, {"author": "Robert Moskowitz", "text": "

MACsec is not broke.

", "time": "2025-03-19T03:58:23Z"}, {"author": "Stephen Farrell", "text": "

MACSEC isn't broken but was designed before PCS was a thing

", "time": "2025-03-19T03:58:29Z"}, {"author": "Robert Moskowitz", "text": "

802.1X not broke. Well maybe ESP is broke. :)

", "time": "2025-03-19T03:58:43Z"}, {"author": "Stephen Farrell", "text": "

@chairs: you might wanna interrupt a bit?

", "time": "2025-03-19T03:58:48Z"}, {"author": "Felix Linker", "text": "

And MACsec being (not) broken does not address Christopher's point.

", "time": "2025-03-19T03:58:53Z"}, {"author": "Alexey Melnikov", "text": "

Sure, but it is fun :-)

", "time": "2025-03-19T03:59:27Z"}, {"author": "Stuart Card", "text": "

I sure do and so do many of my customers. Link crypto is far from dead.

", "time": "2025-03-19T03:59:32Z"}, {"author": "Michael StJohns", "text": "

link crypto is one part of the solution space...

", "time": "2025-03-19T03:59:51Z"}, {"author": "John Preu\u00df Mattsson", "text": "

MACsec is fine, but maybe should be discussed in IEEEE

", "time": "2025-03-19T03:59:51Z"}, {"author": "A.J. Stein", "text": "

So this is kind of like an angry Birds of a Feather situation?

", "time": "2025-03-19T03:59:54Z"}, {"author": "Robert Moskowitz", "text": "

Need MACsec, as it addresses the providers risks.

", "time": "2025-03-19T04:00:08Z"}, {"author": "Martin Thomson", "text": "

I really don't think that link-layer protection is as big of an essential component as others seem to.

", "time": "2025-03-19T04:00:08Z"}, {"author": "Martin Thomson", "text": "

If the network was unencrypted, that would be fine, as far as I'm concerned.

", "time": "2025-03-19T04:00:20Z"}, {"author": "Stuart Card", "text": "

Defense in depth? Why can't we do crypt

", "time": "2025-03-19T04:00:42Z"}, {"author": "Robert Moskowitz", "text": "

@Martin, I disagree. Higher layer protection does not protect the providers.

", "time": "2025-03-19T04:00:57Z"}, {"author": "Stuart Card", "text": "

crypto both on the end points and on the hops?

", "time": "2025-03-19T04:00:58Z"}, {"author": "Thom Wiggers", "text": "

I appreciate that encrypting link-layer as a defense-in-depth/limiting liability concern is something that people might want to do

", "time": "2025-03-19T04:00:58Z"}, {"author": "Christian Huitema", "text": "

It seems to be mostly about placating governments who mandate L2 encryption, and allowing vendors to sell boxes doing that.

", "time": "2025-03-19T04:01:07Z"}, {"author": "Martin Thomson", "text": "

There is nothing wrong with applying crypto, it's just not a critical component.

", "time": "2025-03-19T04:01:08Z"}, {"author": "Thom Wiggers", "text": "

I just don't understand why it's currently not working

", "time": "2025-03-19T04:01:09Z"}, {"author": "Jonathan Hoyland", "text": "

@Stuart Card You can do crypto, that's fine, but it doesn't contribute to our threat model.

", "time": "2025-03-19T04:01:31Z"}, {"author": "Robert Moskowitz", "text": "

At all layers as there are different owners and different liabilities.

", "time": "2025-03-19T04:01:35Z"}, {"author": "Michael StJohns", "text": "

@mt - in some systems, LL provides peer authentication, in others it provides protection against traffic flow analysis...

", "time": "2025-03-19T04:01:45Z"}, {"author": "Martin Thomson", "text": "

traffic flow analysis at that layer is going to fail when it has no idea about what it is supposed to protect

", "time": "2025-03-19T04:02:13Z"}, {"author": "Antoine Fressancourt", "text": "

All in all, I understand public key cryptography is best in class from a security perspective, but it is not fast and lightweight enough in some use cases (like, macsec use cases) so the issue is if best in class security is not practical enough, having slightly degraded security protocols that are suited for some threat models might be better than getting rid of security altogether

", "time": "2025-03-19T04:02:17Z"}, {"author": "Eric Rescorla", "text": "

It seems to me that there are two entirely different problem statements here:

\n
    \n
  1. How do you arrange that A and B share a key
    2. \n
  2. Given that A and B share a key, how do you do a handshaek and derive new keys
    3. \n
", "time": "2025-03-19T04:02:18Z"}, {"author": "Stuart Card", "text": "

@Jonathan Hoyland whose threat model?

", "time": "2025-03-19T04:02:18Z"}, {"author": "Deb Cooley", "text": "

less metadata is exposed with lower level of encryption.

", "time": "2025-03-19T04:02:22Z"}, {"author": "Jonathan Hoyland", "text": "

@Robert Moskowitz exactly, it's part of the link owners threat model.

", "time": "2025-03-19T04:02:24Z"}, {"author": "Eric Rescorla", "text": "

So this whole protocol is basically something we have done N times (IPsec, TLS-PSK, etc.)

", "time": "2025-03-19T04:02:47Z"}, {"author": "Martin Thomson", "text": "

As for the equities of the ends of links, that's something they can use crypto for, but crypto for the stuff the link carries is best applied e2e

", "time": "2025-03-19T04:02:50Z"}, {"author": "Eric Rescorla", "text": "

and it's (2)

", "time": "2025-03-19T04:02:52Z"}, {"author": "Robert Moskowitz", "text": "

So they use MACsec. But where are the keys that are easy (cheap!) to deploy...

", "time": "2025-03-19T04:03:02Z"}, {"author": "Eric Rescorla", "text": "

Like why wouldn't you just use some existing PSK-authenticated AKE

", "time": "2025-03-19T04:03:10Z"}, {"author": "Martin Thomson", "text": "

like TLS?

", "time": "2025-03-19T04:03:24Z"}, {"author": "Felix Linker", "text": "

Eric Rescorla said:

\n
\n

Like why wouldn't you just use some existing PSK-authenticated AKE

\n
\n

Yes!

", "time": "2025-03-19T04:03:25Z"}, {"author": "Jonathan Hoyland", "text": "

@Martin Thomson There is a case for using crypto to give integrity to the link data

", "time": "2025-03-19T04:03:30Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

like TLS?

\n
\n

For instance, but I figured I'd include things I don't work on

", "time": "2025-03-19T04:03:41Z"}, {"author": "Robert Moskowitz", "text": "

@Martin. NO! When I was at Verizon, we were liable for user traffic. We would be holding the lawsuit.

", "time": "2025-03-19T04:04:00Z"}, {"author": "Martin Thomson", "text": "

Jonathan: sure, crypto is better than IP checksum, but not better than raptor or something that is specifically designed for that

", "time": "2025-03-19T04:04:10Z"}, {"author": "Martin Thomson", "text": "

Bob: maybe that liability was a good idea at the time, because people weren't encrypting, but it's possible for laws to be stupid in light of changes in the ecosystem

", "time": "2025-03-19T04:04:55Z"}, {"author": "Eric Rescorla", "text": "

Like why would you design something new to solve this problem!

", "time": "2025-03-19T04:05:07Z"}, {"author": "Robert Moskowitz", "text": "

@Martin. NO safe harbor! The lawyers win.

", "time": "2025-03-19T04:05:26Z"}, {"author": "Jonathan Hoyland", "text": "

Where does N_B come from?

", "time": "2025-03-19T04:06:19Z"}, {"author": "Robert Moskowitz", "text": "

You CANNOT say that the user SHOULD have encrypted their stuff. They are using your fiber. Shame on you.

", "time": "2025-03-19T04:06:22Z"}, {"author": "Stuart Card", "text": "

Plus link crypto simply protects more of the data on the wire, including headers at middle and lower layers. I care about traffic analysis, not just content privacy.

", "time": "2025-03-19T04:06:33Z"}, {"author": "Martin Thomson", "text": "

Bob: I'm sure that this is all internally consistent, but to say that the operator of a highway is liable for the content of trucks is silly.

", "time": "2025-03-19T04:06:47Z"}, {"author": "Michael StJohns", "text": "

@mt - consider the various military networks... SIPRNet for example. All the router to router links are encrypted.. closed networks ....

", "time": "2025-03-19T04:07:06Z"}, {"author": "Martin Thomson", "text": "

Jonathan: I think N_B and I_B would be sent together.

", "time": "2025-03-19T04:07:15Z"}, {"author": "Thom Wiggers", "text": "

I am not sure how they achieve FS if the original keys are popped

", "time": "2025-03-19T04:07:35Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Still much weaker than doing an asymmetric key exchange authenticated with a PSK....

", "time": "2025-03-19T04:07:46Z"}, {"author": "Thom Wiggers", "text": "

but I couldn't find the draft

", "time": "2025-03-19T04:07:46Z"}, {"author": "Eric Rescorla", "text": "

Martin Thomson said:

\n
\n

Jonathan: I think N_B and I_B would be sent together.

\n
\n

Surely we're not going to spend any time building a new PSK-AKE

", "time": "2025-03-19T04:07:47Z"}, {"author": "Jonathan Hoyland", "text": "

@Martin Thomson That's not what's on the slides. I also don't understand how I_A is protected.

", "time": "2025-03-19T04:07:58Z"}, {"author": "Robert Moskowitz", "text": "

Data comm got slapped with different lawsuits. But I remember a bad turn on I71 in Cleveland that resulted in big lawsuits until Ohio finally rebuilt that curve.

", "time": "2025-03-19T04:08:04Z"}, {"author": "Felix Linker", "text": "

Thom Wiggers said:

\n
\n

I am not sure how they achieve FS if the original keys are popped

\n
\n

\"Popped\" = compromised?

", "time": "2025-03-19T04:08:10Z"}, {"author": "Eric Rescorla", "text": "

Eric Rescorla said:

\n
\n

Martin Thomson said:

\n
\n

Jonathan: I think N_B and I_B would be sent together.

\n
\n

Surely we're not going to spend any time building a new PSK-AKE

\n
\n

Or for that matter analyzing a new one

\n

Or f

", "time": "2025-03-19T04:08:16Z"}, {"author": "Martin Thomson", "text": "

Ekr: I'm not making excuses for the spontaneous AKE invention going on.

", "time": "2025-03-19T04:08:19Z"}, {"author": "Thom Wiggers", "text": "

@Felix Linker yes

", "time": "2025-03-19T04:08:28Z"}, {"author": "Jonathan Hoyland", "text": "

@Eric Rescorla protocol analysis is one of my favourite things :P

", "time": "2025-03-19T04:08:48Z"}, {"author": "Eric Rescorla", "text": "

AFAICT there is no way to get FS in this context without either (1) doing a PK key exchange or (2) ratcheting the PSK

", "time": "2025-03-19T04:08:52Z"}, {"author": "Felix Linker", "text": "

Thom Wiggers said:

\n
\n

Felix Linker yes

\n
\n

Yeah, you can't. The assumption must be the same as with PFS for asymmetric key. When you rekey, you must delete old keys.

", "time": "2025-03-19T04:08:59Z"}, {"author": "Robert Moskowitz", "text": "

Didn't matter that the curve was posted at 25MPH...

", "time": "2025-03-19T04:09:04Z"}, {"author": "Felix Linker", "text": "

Thom Wiggers said:

\n
\n

but I couldn't find the draft

\n
\n

Draft is very hidden: https://mailarchive.ietf.org/arch/msg/skex/8Vgb_sHVjCunlAaNS7P7PTYNfMs/

", "time": "2025-03-19T04:09:11Z"}, {"author": "Thom Wiggers", "text": "

why shouldn't we keep inventing new protocols? got to give the protocol analysts (=me) job security!

", "time": "2025-03-19T04:09:16Z"}, {"author": "Eric Rescorla", "text": "

Thom Wiggers said:

\n
\n

why shouldn't we keep inventing new protocols? got to give the protocol analysts (=me) job security!

\n
\n

Maybe instead make some better PQ signature algorithms :)

", "time": "2025-03-19T04:09:45Z"}, {"author": "Stuart Card", "text": "

My 50,000 foot view of this: asymmetric crypto was not created to make encryption stronger but to ease key management; this is another run at scaling up key management for symmetric crypto that can be used at lower layers and possibly in some other cases where asymmetric crypto may not be a great fit. I like not having all my eggs in one basket.

", "time": "2025-03-19T04:09:47Z"}, {"author": "Thom Wiggers", "text": "

(joking aside, if properly motivated, there may be value)

", "time": "2025-03-19T04:09:47Z"}, {"author": "Martin Thomson", "text": "

@Daniel Shiu: you know that draft submissions re-opened on Monday?

", "time": "2025-03-19T04:10:48Z"}, {"author": "Thom Wiggers", "text": "

Felix Linker said:

\n
\n

Thom Wiggers said:

\n
\n

but I couldn't find the draft

\n
\n

Draft is very hidden: https://mailarchive.ietf.org/arch/msg/skex/8Vgb_sHVjCunlAaNS7P7PTYNfMs/

\n
\n

thanks. It seems the FS is achieved by ratcheting the long-term key

", "time": "2025-03-19T04:11:00Z"}, {"author": "Jonathan Hoyland", "text": "

I like how he expands AES, but not one-time pad (and not one-time password).

", "time": "2025-03-19T04:11:02Z"}, {"author": "Robert Moskowitz", "text": "

It reopened on Sunday....

", "time": "2025-03-19T04:11:09Z"}, {"author": "Thom Wiggers", "text": "

this question has three different things in it

", "time": "2025-03-19T04:12:09Z"}, {"author": "Martin Thomson", "text": "

Any one can be false for the answer to be \"no\"

", "time": "2025-03-19T04:12:22Z"}, {"author": "Thom Wiggers", "text": "

clear/well-scoped: no; useful: maybe? I can't tell...

", "time": "2025-03-19T04:12:27Z"}, {"author": "Robert Moskowitz", "text": "

All true but useful to solve.

", "time": "2025-03-19T04:12:32Z"}, {"author": "Stephen Farrell", "text": "

clear, well-scoped == no for me, others maybe

", "time": "2025-03-19T04:12:32Z"}, {"author": "Martin Thomson", "text": "

For the answer to be \"yes\", all three need to be true.

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

@mt: there's 4:-)

", "time": "2025-03-19T04:12:52Z"}, {"author": "Eric Rescorla", "text": "

I think there are two problems, one of which is clear, well-scoped, solvable, and solved (bootstrapping from a PSK to a connection) and one which is not (distributing the PSKs)

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

0, 1, 2, and 3 == 3!

", "time": "2025-03-19T04:13:19Z"}, {"author": "Jonathan Hammell", "text": "

I think that question should have been broken up.

", "time": "2025-03-19T04:13:52Z"}, {"author": "Stuart Card", "text": "

I concur: too many anded terms in the question for me to answer it.

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

Yes, should have been 3 polls

", "time": "2025-03-19T04:14:15Z"}, {"author": "Felix Linker", "text": "

Martin Thomson said:

\n
\n

0, 1, 2, and 3 == 3!

\n
\n

https://x.com/IsomorphicPhi/status/1761360604885823581

", "time": "2025-03-19T04:14:17Z"}, {"author": "Valery Smyslov", "text": "

I agree that it should be 3 polls

", "time": "2025-03-19T04:14:40Z"}, {"author": "Stuart Card", "text": "

This is the 2nd BoF I have attended this week where I thought there was a real need but it was not convincingly presented.

", "time": "2025-03-19T04:14:54Z"}, {"author": "Stephen Farrell", "text": "

I love how whether a discussion is over-heated or not is dependent on perspective:-)

", "time": "2025-03-19T04:14:58Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Asymmetric ephemeral keying is essential for key distribution. It makes sure that an attacker that has compromise of the root key cannot passivly decrypt future sessions. Doing anything else is not best practice. IETF has previousle decided to fight prevasive monitoring. Doing that mandates frequent asymmetric ephemeral keying.

", "time": "2025-03-19T04:15:12Z"}, {"author": "John Preu\u00df Mattsson", "text": "

Why did we have presentations on new proposals? We have a large number of standardized protocols for distribution of symmetric keys (Kerberos, OAuth with proof-of-possetion tokens, EAP-TLS 1.3, EAP-EDHOC etc, MIKEY-TICKET, etc, just to mention a few from the IETF). The BoF proponents completely missed to explain

\n
    \n
  1. what is missing in existing protocols
    2. \n
  2. why can these methods not be expanded.
    \nI am suprised this BoF was approved....
    3. \n
", "time": "2025-03-19T04:15:39Z"}, {"author": "Stephen Farrell", "text": "

@john: I wonder if feeding in QKD bits changes that a bit? Not sure.

", "time": "2025-03-19T04:15:44Z"}, {"author": "Eric Rescorla", "text": "

John Preu\u00df Mattsson said:

\n
\n

Asymmetric ephemeral keying is essential for key distribution. It makes sure that an attacker that has compromise of the root key cannot passivly decrypt future sessions. Doing anything else is not best practice. IETF has previousle decided to fight prevasive monitoring. Doing that mandates frequent asymmetric ephemeral keying.

\n
\n

This is, of course, not inconsistent with starting from a PSK.

", "time": "2025-03-19T04:15:45Z"}, {"author": "Yoav Nir", "text": "

Stephen Farrell said:

\n
\n

I love how whether a discussion is over-heated or not is dependent on perspective:-)

\n
\n

It did not include actual yelling

", "time": "2025-03-19T04:15:49Z"}]