[{"author": "Michael Richardson", "text": "

I don't know what Octopus means, but I like it.

", "time": "2023-07-26T00:02:12Z"}, {"author": "Mohammad Al Abbadi", "text": "

\"It depends\" is sounding a lot like \"you can't\"

", "time": "2023-07-26T00:08:55Z"}, {"author": "Benjamin Kaduk", "text": "

And hence, getting annoyed enough to write a draft about it

", "time": "2023-07-26T00:10:22Z"}, {"author": "Richard Barnes", "text": "

this whole presentation is like \"yes, this is why we moved from client certs to WebAuthn\"

", "time": "2023-07-26T00:10:22Z"}, {"author": "Daniel Gillmor", "text": "

\"it depends\" absolutely means \"you can't do it reliably\". David is absolutely right to try to get this sorted out.

", "time": "2023-07-26T00:10:34Z"}, {"author": "Benjamin Kaduk", "text": "

\"But it doesn't have to be this way\"

", "time": "2023-07-26T00:10:36Z"}, {"author": "Richard Barnes", "text": "

\"doctor, it hurts why i try to use client certs\"

", "time": "2023-07-26T00:10:39Z"}, {"author": "Deb Cooley", "text": "

SMH

", "time": "2023-07-26T00:10:53Z"}, {"author": "Daniel Gillmor", "text": "

i ran into all of these issues -- except for the hardware stuff -- in the process of trying to write RFC 9216 which i thought would be relatively straightforward.

", "time": "2023-07-26T00:11:55Z"}, {"author": "Daniel Gillmor", "text": "

\"kafka-esque nightmare\" was my conclusion

", "time": "2023-07-26T00:12:13Z"}, {"author": "Stephen Farrell", "text": "

a doc like that seems sensible, if well done

", "time": "2023-07-26T00:12:53Z"}, {"author": "Roman Danyliw", "text": "

Stephen, can you please say that at the mic.

", "time": "2023-07-26T00:13:25Z"}, {"author": "Stephen Farrell", "text": "

sure

", "time": "2023-07-26T00:13:32Z"}, {"author": "Roman Danyliw", "text": "

Daniel, can you please say that at the mic

", "time": "2023-07-26T00:13:34Z"}, {"author": "Benjamin Kaduk", "text": "

That's a load of baloney that the IETF doesn't do APIs

", "time": "2023-07-26T00:13:54Z"}, {"author": "Jonathan Hoyland", "text": "

Also we have 0% chance of people actually going and updating their crypto gubbins

", "time": "2023-07-26T00:14:04Z"}, {"author": "David Woodhouse", "text": "

https://mailarchive.ietf.org/arch/msg/saag/XTUjNkDxorqNs4WI2zkuwrh1LyI/

", "time": "2023-07-26T00:14:11Z"}, {"author": "Mohammad Al Abbadi", "text": "

It's only an API if it comes from the API region of the internet

", "time": "2023-07-26T00:14:49Z"}, {"author": "Carsten Bormann", "text": "

Ben: It is a popular way to push away work (which is a legitimate objecive!)

", "time": "2023-07-26T00:15:06Z"}, {"author": "Richard Barnes", "text": "

otherwise it's just a sparkling interface

", "time": "2023-07-26T00:15:18Z"}, {"author": "Benjamin Kaduk", "text": "

I am in support of us being able/willing to push away work! But we have other reasons we can give, that hold up better under close examination

", "time": "2023-07-26T00:15:42Z"}, {"author": "Richard Barnes", "text": "

\"doctor it hurts when i use S/MIME\"

", "time": "2023-07-26T00:15:46Z"}, {"author": "Michael Richardson", "text": "

EKR, that just doesn't work. Applications talk protocols to HSMs, and they talk STUFF to corporate CA, and while ACME can sure help, it doesn't really solve anything. There are applications beyond the browser.

", "time": "2023-07-26T00:16:04Z"}, {"author": "Benjamin Kaduk", "text": "

... did Stephen just say to do more things in LAMPS? Is the world ending?

", "time": "2023-07-26T00:16:58Z"}, {"author": "Michael Richardson", "text": "

What about dispatch to a rechartered UTA?

", "time": "2023-07-26T00:17:14Z"}, {"author": "Richard Barnes", "text": "

@Michael Richardson ACME aside, the underlying point is that this is focused on manually moving certs around from one app to another, which is an anti-pattern

", "time": "2023-07-26T00:17:21Z"}, {"author": "Thom Wiggers", "text": "

Unlimited Additional Mechanisms

", "time": "2023-07-26T00:17:25Z"}, {"author": "Stephen Farrell", "text": "

I've no problem if it's done elsewhere but it does actually fit the intent of lamps

", "time": "2023-07-26T00:17:27Z"}, {"author": "Daniel Gillmor", "text": "

this \"we don't do API\" is nonsense, and we should stop saying it.

", "time": "2023-07-26T00:17:38Z"}, {"author": "Leif Johansson", "text": "

support the work

", "time": "2023-07-26T00:17:46Z"}, {"author": "Jonathan Hoyland", "text": "

What's the proposed end product? A BCP?

", "time": "2023-07-26T00:17:50Z"}, {"author": "Michael StJohns", "text": "

Let me be clear. - only the pics 1,8 and 2 stuff is in scope for lamps

", "time": "2023-07-26T00:17:55Z"}, {"author": "Benjamin Kaduk", "text": "

dkg; might be worth saying that at the mic and getting it in the minutes, even if the chairs shut us down for being in a rathole

", "time": "2023-07-26T00:18:16Z"}, {"author": "Jonathan Hoyland", "text": "

Or rather a BCP that no library in existence follows

", "time": "2023-07-26T00:18:20Z"}, {"author": "Stephen Farrell", "text": "

@Jonathan Hoyland yeah that's the danger

", "time": "2023-07-26T00:18:36Z"}, {"author": "Richard Barnes", "text": "

LAMPS == zombie PKIX

", "time": "2023-07-26T00:18:48Z"}, {"author": "Michael Richardson", "text": "

Richard Barnes said:

\n
\n

Michael Richardson ACME aside, the underlying point is that this is focused on manually moving certs around from one app to another, which is an anti-pattern

\n
\n

Yeah, \"app\"? maybe too much smartphone thinking? :-) You are assuming a complete ecosystem within the monolithic application. Are you saying that LIBREOFFICE has to speak ACME in order to sign PDFs? And know how to talk to all the HSMs I might want to store my stuff on?

", "time": "2023-07-26T00:18:53Z"}, {"author": "David Woodhouse", "text": "

openconnect does. And has a test suite of torture tests which validates it.

", "time": "2023-07-26T00:19:06Z"}, {"author": "Stephen Farrell", "text": "

+1 to dkg for this topic

", "time": "2023-07-26T00:19:18Z"}, {"author": "Phillip Hallam-Baker", "text": "

here here

", "time": "2023-07-26T00:19:24Z"}, {"author": "Carsten Bormann", "text": "

+1 dkg!

", "time": "2023-07-26T00:19:34Z"}, {"author": "Roman Danyliw", "text": "

dkg: testimony entered in the record

", "time": "2023-07-26T00:19:49Z"}, {"author": "David Woodhouse", "text": "

https://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am tests

", "time": "2023-07-26T00:20:00Z"}, {"author": "Eric Rescorla", "text": "

Well, we did GSSAPI

", "time": "2023-07-26T00:20:11Z"}, {"author": "Roman Danyliw", "text": "

eBPF?

", "time": "2023-07-26T00:20:40Z"}, {"author": "Alex Chernyakhovsky", "text": "

eBPF is ... not really an API. It's even more than an API.

", "time": "2023-07-26T00:20:58Z"}, {"author": "Jonathan Hoyland", "text": "

Eric Rescorla said:

\n
\n

Well, we did GSSAPI

\n
\n

Yeah, and encoded broken channel bindings forevermore.

", "time": "2023-07-26T00:21:00Z"}, {"author": "Daniel Gillmor", "text": "

just because we've done bad APIs doesn't mean we shouldn't do APIs

", "time": "2023-07-26T00:21:35Z"}, {"author": "Daniel Gillmor", "text": "

by that logic, we probably shouldn't do network protocols either

", "time": "2023-07-26T00:21:44Z"}, {"author": "Lucas Pardue", "text": "

TTFCB 21 mins

", "time": "2023-07-26T00:22:20Z"}, {"author": "Eric Rescorla", "text": "

Hey, I didn't say anything about GSS being bad

", "time": "2023-07-26T00:22:20Z"}, {"author": "Daniel Gillmor", "text": "

@Jonathan Hoyland did

", "time": "2023-07-26T00:22:32Z"}, {"author": "Eric Rescorla", "text": "

Fair enough

", "time": "2023-07-26T00:22:39Z"}, {"author": "Richard Barnes", "text": "

Does anyone care about this separability property?

", "time": "2023-07-26T00:23:21Z"}, {"author": "Jonathan Hoyland", "text": "

Daniel Gillmor said:

\n
\n

by that logic, we probably shouldn't do network protocols either

\n
\n

Good point. We probably shouldn't :joy:

", "time": "2023-07-26T00:23:31Z"}, {"author": "Eric Rescorla", "text": "

I just don't understand this

", "time": "2023-07-26T00:24:07Z"}, {"author": "Deb Cooley", "text": "

separability: only if you insist on having two signatures....

", "time": "2023-07-26T00:24:12Z"}, {"author": "Richard Barnes", "text": "

i don't see how separability forces verifying both

", "time": "2023-07-26T00:24:21Z"}, {"author": "Daniel Gillmor", "text": "

yeah, just don't create two signatures

", "time": "2023-07-26T00:24:23Z"}, {"author": "Jonathan Hoyland", "text": "

Richard Barnes said:

\n
\n

Does anyone care about this separability property?

\n
\n

I feel like it's channel binding in a false nose and glasses

", "time": "2023-07-26T00:24:25Z"}, {"author": "Eric Rescorla", "text": "

Like what is actually required is that you just don't accept RSA-only signatures

", "time": "2023-07-26T00:24:33Z"}, {"author": "Eric Rescorla", "text": "

(or whatever)

", "time": "2023-07-26T00:24:38Z"}, {"author": "Michael Richardson", "text": "

CRQC. I really like that. Lost in the swamps with up to our armpits with crocodiles . It won't happen for awhile maybe. But, we can't put off fighting the alligators until later.

", "time": "2023-07-26T00:25:11Z"}, {"author": "Eric Rescorla", "text": "

I have a good answer here, which is that hybrid signatures are bad

", "time": "2023-07-26T00:25:23Z"}, {"author": "Eric Rescorla", "text": "

And therefore this is also bad

", "time": "2023-07-26T00:25:40Z"}, {"author": "Deb Cooley", "text": "

+1

", "time": "2023-07-26T00:25:46Z"}, {"author": "Daniel Gillmor", "text": "

@Eric Rescorla are you saying that a deliberate composite signature is bad on its own? or just that separable hybrid signatures are bad?

", "time": "2023-07-26T00:26:55Z"}, {"author": "Richard Barnes", "text": "

i remain unconvinced that separability is actually useful

", "time": "2023-07-26T00:27:19Z"}, {"author": "John Gray", "text": "

As an author on the Composite Signatures draft, we are wondering if the non-separability property is important? We had talked about making the composite signature weakly non-separable, and are fully happy to make these changes. This is still stronger than a multi-certificate approach.

", "time": "2023-07-26T00:27:21Z"}, {"author": "Richard Barnes", "text": "

er, non-separability

", "time": "2023-07-26T00:27:26Z"}, {"author": "Jonathan Hoyland", "text": "

Jonathan Hoyland said:

\n
\n

Richard Barnes said:

\n
\n

Does anyone care about this separability property?

\n
\n

I feel like it's channel binding in a false nose and glasses

\n
\n

Channel binding can be used to give compound auth, where you prove that(in this context) that as long as either signature is generated correctly both are generated honestly.

", "time": "2023-07-26T00:27:35Z"}, {"author": "Richard Barnes", "text": "

and even if it is, there are easier ways to do it, e.g., having each signature cover an indication that a signature of the other type should be present

", "time": "2023-07-26T00:28:11Z"}, {"author": "Jonathan Hoyland", "text": "

Richard Barnes said:

\n
\n

and even if it is, there are easier ways to do it, e.g., having each signature cover an indication that a signature of the other type should be present

\n
\n

Shades of OCSP MUST-STAPLE

", "time": "2023-07-26T00:28:45Z"}, {"author": "Richard Barnes", "text": "

@Jonathan Hoyland and problematic in the same ways!

", "time": "2023-07-26T00:29:15Z"}, {"author": "Richard Barnes", "text": "

(which i say as the guy who wrote the MUST_STAPLE implementation in Firefox, which AFAIK has never been used in anger)

", "time": "2023-07-26T00:30:20Z"}, {"author": "Eric Rescorla", "text": "

The underlying problem here is that as long as the Relying Party is willing to support classical algorithm C and post-quantum algorithm P, then security relies on the weaker of the two and hybrid doesn't help

", "time": "2023-07-26T00:30:47Z"}, {"author": "Martin Thomson", "text": "

trilithium!

", "time": "2023-07-26T00:30:47Z"}, {"author": "Eric Rescorla", "text": "

And so you have three phases: C only (now). C or P (transition) and P only (post CQRC)

", "time": "2023-07-26T00:31:27Z"}, {"author": "Daniel Gillmor", "text": "

the reason you make two signatures is not for the single relying party that supports either algorithm: it's to support a mixed pool of relying parties, some of whom only support C, and some of whom only support P.

", "time": "2023-07-26T00:31:45Z"}, {"author": "Martin Thomson", "text": "

I can see a path where Richard's \"cover an indicator that another signature exists\" makes a tiny bit of sense, but even that is pretty thin

", "time": "2023-07-26T00:31:52Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor agreed, but then you need two totally distinc signatures

", "time": "2023-07-26T00:32:10Z"}, {"author": "Martin Thomson", "text": "

@Daniel Gillmor you only need multiple signatures to achieve that

", "time": "2023-07-26T00:32:11Z"}, {"author": "Eric Rescorla", "text": "

and hybrid doesn't help

", "time": "2023-07-26T00:32:13Z"}, {"author": "Mohammad Al Abbadi", "text": "

It doesn't sound like a bad approach if you don't know which of the algorithms is weaker

", "time": "2023-07-26T00:32:18Z"}, {"author": "Eric Rescorla", "text": "

Because the only thing that will definitely work now is to have C

", "time": "2023-07-26T00:32:33Z"}, {"author": "Richard Barnes", "text": "

shouldn't we be migrating from C to Rust?

", "time": "2023-07-26T00:32:47Z"}, {"author": "Daniel Gillmor", "text": "

the \"C or P (transition)\" phase for the relying party is of purely research/engineering interest, and is no more secure than the \"C only\" approach.

", "time": "2023-07-26T00:32:55Z"}, {"author": "Peter Campbell", "text": "

One of the difficulties of non-separable hybrid signatures is that you need to modify the component algorithms and this will be different for different pairs. Doing that can lead to vulnerabilities that aren't present in the component algorithms. For example, the Dilithium+ECDSA construction in the draft omits rejection sampling.

", "time": "2023-07-26T00:32:59Z"}, {"author": "Martin Thomson", "text": "

C++ is clearly a poor choice, yes

", "time": "2023-07-26T00:33:00Z"}, {"author": "Lucas Pardue", "text": "

\"sometimes\" brings up :joy:

", "time": "2023-07-26T00:33:30Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor 100% agree that it's not more secure.What it is instead is a transition mechanism

", "time": "2023-07-26T00:33:39Z"}, {"author": "Stephen Farrell", "text": "

I do think it'd be wiser of the IETF to have some kind of more broadly (than just x.509 fans) approach to signatures and a possible CRQC (after we're done being relaxed about it), so keeping on keeping on in LAMPS seems a bad plan to me

", "time": "2023-07-26T00:33:53Z"}, {"author": "Martin Thomson", "text": "

two independent signatures is LCD, this is GCM

", "time": "2023-07-26T00:34:13Z"}, {"author": "Eric Rescorla", "text": "

Because you want to get to the point where you have high confidence that you can turn off C

", "time": "2023-07-26T00:34:26Z"}, {"author": "Benjamin Schwartz", "text": "

I think we just need a message format that says \"expect signatures with both algorithms\", signed by both algorithms separately

", "time": "2023-07-26T00:34:36Z"}, {"author": "Eric Rescorla", "text": "

Which relies on actually getting use of P in the wild

", "time": "2023-07-26T00:34:37Z"}, {"author": "Daniel Gillmor", "text": "

Eric Rescorla said:

\n
\n

Daniel Gillmor 100% agree that it's not more secure.What it is instead is a transition mechanism

\n
\n

right, a chance to verify the implementations are working (\"of research/engineering interest\"), not as a security measure.

", "time": "2023-07-26T00:34:49Z"}, {"author": "Martin Thomson", "text": "

@Benjamin Schwartz do you even need that?

", "time": "2023-07-26T00:34:53Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor 100% agree with that explanation

", "time": "2023-07-26T00:35:02Z"}, {"author": "Benjamin Schwartz", "text": "

@Martin Thomson To prevent an intermediary from stripping one signature and forging the other.

", "time": "2023-07-26T00:35:09Z"}, {"author": "Benjamin Schwartz", "text": "

Hmm... OK maybe that's not quite right

", "time": "2023-07-26T00:35:26Z"}, {"author": "Eric Rescorla", "text": "

The only thing that provides security is refusing to accept C only

", "time": "2023-07-26T00:35:35Z"}, {"author": "Martin Thomson", "text": "

Bingo.

", "time": "2023-07-26T00:35:49Z"}, {"author": "Daniel Gillmor", "text": "

what about the scenario where we discover that our proposed P turns out to be bad?

", "time": "2023-07-26T00:36:10Z"}, {"author": "Eric Rescorla", "text": "

Everything else is just about getting us ready to flip that switch

", "time": "2023-07-26T00:36:14Z"}, {"author": "Martin Thomson", "text": "

@Daniel Gillmor then C had better be good.

", "time": "2023-07-26T00:36:24Z"}, {"author": "Eric Rescorla", "text": "

@Daniel Gillmor before or after a CRQC?

", "time": "2023-07-26T00:36:26Z"}, {"author": "Daniel Gillmor", "text": "

before we know of one

", "time": "2023-07-26T00:36:37Z"}, {"author": "Eric Rescorla", "text": "

Then you just turn off P

", "time": "2023-07-26T00:37:06Z"}, {"author": "Eric Rescorla", "text": "

Same as if you learned that (say) RSA was broken but you still had EC

", "time": "2023-07-26T00:37:29Z"}, {"author": "Daniel Gillmor", "text": "

and if we've flipped the switch (from \"C or P\" to \"P\"), we flip it back to \"C\"?

", "time": "2023-07-26T00:37:39Z"}, {"author": "Eric Rescorla", "text": "

Or just like give up

", "time": "2023-07-26T00:38:02Z"}, {"author": "Richard Barnes", "text": "

it's amazing how many words it takes this group to say \"no\"

", "time": "2023-07-26T00:38:03Z"}, {"author": "Eric Rescorla", "text": "

I mean suppose we learned today that EC was insecure, even though TLS 1.3 is basically only EC only

", "time": "2023-07-26T00:38:42Z"}, {"author": "Martin Thomson", "text": "

if RSA is still good, we'd have some trouble, but we'd probably stumble through

", "time": "2023-07-26T00:39:21Z"}, {"author": "Stephen Farrell", "text": "

my suggestion was to just relax, not wait for any particular thing

", "time": "2023-07-26T00:39:35Z"}, {"author": "Jonathan Hoyland", "text": "

Eric Rescorla said:

\n
\n

I mean suppose we learned today that EC was insecure, even though TLS 1.3 is basically only EC only

\n
\n

Then people would finally have to listen to my waffling about channel binding :joy:

", "time": "2023-07-26T00:40:38Z"}, {"author": "Phillip Hallam-Baker", "text": "

ECDH signatures are rather fragile...

", "time": "2023-07-26T00:40:41Z"}, {"author": "Phillip Hallam-Baker", "text": "

Like if you screw up sign two things with the same nonce... ooops.

", "time": "2023-07-26T00:41:28Z"}, {"author": "Phillip Hallam-Baker", "text": "

So I think it would need close attention and thinkage

", "time": "2023-07-26T00:41:43Z"}, {"author": "Jonathan Hoyland", "text": "

+1 MT

", "time": "2023-07-26T00:42:11Z"}, {"author": "Jonathan Hoyland", "text": "

I would be interested in thinking about this, but there was rough consensus on no

", "time": "2023-07-26T00:42:54Z"}, {"author": "Ira McDonald", "text": "

Yoav is right - the hybrid signatures objections are being used to obscure the value of SNS as a property

", "time": "2023-07-26T00:43:09Z"}, {"author": "Eric Rescorla", "text": "

Here is my attempted take on hybrid from a while ago https://mailarchive.ietf.org/arch/browse/secdispatch/

", "time": "2023-07-26T00:43:14Z"}, {"author": "Daniel Gillmor", "text": "

+1 @Christopher Wood

", "time": "2023-07-26T00:43:43Z"}, {"author": "Richard Barnes", "text": "

this WG can't dispatch to CFRG!

", "time": "2023-07-26T00:43:44Z"}, {"author": "Stephen Farrell", "text": "

so cfrg should relax for a few years too (on this topic only:-)

", "time": "2023-07-26T00:43:44Z"}, {"author": "Mike Ounsworth", "text": "

@chairs I propose that the Non-Separability \"signature combiners\" (if it's useful to pursue at all) follow the same pattern as the \"KEM combiners\" stuff where we have a CFRG draft of the core crypto primitive: draft-ounsworth-cfrg-kem-combiners, and that is referenced by the various protocol drafts that implement it, ex: draft-ounsworth-pq-composite-kem, draft-wussler-openpgp-pqc, draft-ra-cose-hybrid-encrypt.

", "time": "2023-07-26T00:44:03Z"}, {"author": "Daniel Gillmor", "text": "

Eric Rescorla said:

\n
\n

Here is my attempted take on hybrid from a while ago https://mailarchive.ietf.org/arch/browse/secdispatch/

\n
\n

this is not a very specific link, ekr

", "time": "2023-07-26T00:44:24Z"}, {"author": "Eric Rescorla", "text": "

Just read the whole link :)

", "time": "2023-07-26T00:44:38Z"}, {"author": "Eric Rescorla", "text": "

https://mailarchive.ietf.org/arch/msg/secdispatch/2Q6aYKi2u0ope-YHcRs684GBng8/

", "time": "2023-07-26T00:44:49Z"}, {"author": "Daniel Gillmor", "text": "

this link only talks about some algorithm \"Q\", which is different from \"P\"

", "time": "2023-07-26T00:45:40Z"}, {"author": "Eric Rescorla", "text": "

It's one better

", "time": "2023-07-26T00:45:50Z"}, {"author": "Eric Rescorla", "text": "

This is oddly reminiscent of SKIP

", "time": "2023-07-26T00:46:44Z"}, {"author": "Roman Danyliw", "text": "

@Barnes: Yes, technically we can't dispatch to CFRG. In the spirit of the providing constructive next steps, this could be a step the document authors could explore. + the level of interest expressed here.

", "time": "2023-07-26T00:46:48Z"}, {"author": "Peter Campbell", "text": "

@MIkeOunsworth: I don't think you can have the equivalent to the KEM combiners draft as what you'd want to do for Dilithium+ECDSA is very different to what you'd want to do for Falcon+ECDSA.

", "time": "2023-07-26T00:47:27Z"}, {"author": "Stephen Farrell", "text": "

does this have the downsides of SAVI if applied to non site-to-site cases I wonder?

", "time": "2023-07-26T00:47:29Z"}, {"author": "Phillip Hallam-Baker", "text": "

Roman, by the same logic, we can't not dispatch to CFRG either.

", "time": "2023-07-26T00:47:39Z"}, {"author": "Samuel Weiler", "text": "

Everything old is new again? https://www.freeswan.org/

", "time": "2023-07-26T00:48:52Z"}, {"author": "Mike Ounsworth", "text": "

[Quoting\u2026]
\nThat frames the question \"Are hybrid signatures useful?\" within the context of TLS and IPsec. A valid question to get to the bottom of.

\n

That may have a different answer than the question \"Are hybrid signatures useful?\" within the context of non-negotiated protocols like S/MIME, JOSE, the myriad proprietary uses of CMS.

\n

I'm leery of falling into the fallacy of \"If it's not useful for TLS, then it's not useful at all\".

", "time": "2023-07-26T00:49:10Z"}, {"author": "Michael Richardson", "text": "

https://www.rfc-editor.org/rfc/rfc9255.html doesn't say do not use RPKI for IKEv2, but it does say that it is supposed to be for ROAs ... only?

", "time": "2023-07-26T00:49:50Z"}, {"author": "Yoav Nir", "text": "

Nah. We have enough hate in our hearts for both transport mode and for AH

", "time": "2023-07-26T00:49:51Z"}, {"author": "Daniel Gillmor", "text": "

For S/MIME, a pair of separable signatures looks to me like it has all the properties it is reasonable to want.

", "time": "2023-07-26T00:50:04Z"}, {"author": "Richard Barnes", "text": "

this is just LISP in a false nose and glasses

", "time": "2023-07-26T00:50:16Z"}, {"author": "Mike Ounsworth", "text": "

Peter Campbell said:

\n
\n

@MIkeOunsworth: I don't think you can have the equivalent to the KEM combiners draft as what you'd want to do for Dilithium+ECDSA is very different to what you'd want to do for Falcon+ECDSA.

\n
\n

Fair, it's a level less abstract, but it could (and should) be that CFRG tells us how to safely combine Dilithium+ECDSA, and Falcon+ECDSA, which will be used by LAMPS, COSE/JOSE, OpenPGP, etc, rather than dispatching this to one of those protocol WGs.

", "time": "2023-07-26T00:50:43Z"}, {"author": "Daniel Gillmor", "text": "

For OpenPGP PQC, we're not bothering to contemplate hybrid signatures at all: https://www.ietf.org/archive/id/draft-wussler-openpgp-pqc-02.html#name-sphincs

", "time": "2023-07-26T00:51:47Z"}, {"author": "Michael Richardson", "text": "

@Stephen Farrell SAVI proposals get into trouble because the origin AS can't promise that traffic really has the right source address. This does not deal with that all, but rather keeps THIRD PARTIES (who are on AS1 or AS2) from spoofing AS1.

", "time": "2023-07-26T00:51:50Z"}, {"author": "Michael Richardson", "text": "

who are NOT AS1 or AS2.

", "time": "2023-07-26T00:52:12Z"}, {"author": "Eric Rescorla", "text": "

I have a preliminary question: are there any operators who want to do this?

", "time": "2023-07-26T00:52:51Z"}, {"author": "Deb Cooley", "text": "

I\u2019ve usually seen 802.1x used for this sort of thing (w/in an enclave)

", "time": "2023-07-26T00:53:35Z"}, {"author": "Michael Richardson", "text": "

@John Scudder the big providers who want to do this are digging their own funeral, and they want to do this. As for the opt-in, this is really no different than MACsec over a undersea cable.

", "time": "2023-07-26T00:53:35Z"}, {"author": "Mohammad Al Abbadi", "text": "

Are there alternatives to hybrid signatures? As in transitional solutions?

", "time": "2023-07-26T00:53:46Z"}, {"author": "Mike Ounsworth", "text": "

Daniel Gillmor said:

\n
\n

For OpenPGP PQC, we're not bothering to contemplate hybrid signatures at all: https://www.ietf.org/archive/id/draft-wussler-openpgp-pqc-02.html#name-sphincs

\n
\n

Huh?
\nFrom that doc:

\n
\n

37 Dilithium3 + ECDSA-NIST-P-256
\n38 Dilithium5 + ECDSA-NIST-P-384
\n39 Dilithium3 + ECDSA-brainpoolP256r1
\n40 Dilithium5 + ECDSA-brainpoolP384r1

\n
", "time": "2023-07-26T00:54:12Z"}, {"author": "Eric Rescorla", "text": "

\"In my imagination, crypto is free\"

", "time": "2023-07-26T00:54:15Z"}, {"author": "Roman Danyliw", "text": "

Is the relationship of this proposal to https://datatracker.ietf.org/group/savnet/about/ known?

", "time": "2023-07-26T00:54:20Z"}, {"author": "Michael Richardson", "text": "

corp1 == Facebook, corp2 == Verizon. He should have called it \"ASN1.example\".

", "time": "2023-07-26T00:54:29Z"}, {"author": "Eric Rescorla", "text": "

@Mohammad Al Abbadi more or less\" use separate keys and cerdentials

", "time": "2023-07-26T00:54:30Z"}, {"author": "Kathleen Moriarty", "text": "

Seems like additional discussion is needed

", "time": "2023-07-26T00:55:18Z"}, {"author": "Yoav Nir", "text": "

The alternative to hybrid is to use the new instead of the old, the way we transitioned from RSA to ECDSA. There can be a transition where you have separate certificates and pick a certificate based on what the client supports.

", "time": "2023-07-26T00:55:38Z"}, {"author": "Daniel Gillmor", "text": "

@Mike Ounsworth ugh, you're right, sorry, i just skipped over that and read it as Kyber + ECDH. i'll raise this issue with the authors of that draft. thanks!

", "time": "2023-07-26T00:56:05Z"}, {"author": "Michael Richardson", "text": "

There are no benefits to end users, other than a lack of spoofed source addresses.

", "time": "2023-07-26T00:56:36Z"}, {"author": "Peter Campbell", "text": "

@MikeOunsworth: Looking at the constructions in the Bindel and Hale paper, it's probably one draft for Dilithium+ECDSA and a separate draft for Falcon+ECDSA.

", "time": "2023-07-26T00:57:47Z"}, {"author": "Michael Richardson", "text": "

Ben works for an operator called META

", "time": "2023-07-26T00:57:55Z"}, {"author": "John Scudder", "text": "

I should have replied to the dispatch question with \u201cwhat about SAVI?\u201d Datatracker isn\u2019t answering so I can\u2019t check the charter, but I think so.

", "time": "2023-07-26T00:58:10Z"}, {"author": "Martin Thomson", "text": "

maybe we need to work on a middle-to-middle encryption definition before we can proceed with this

", "time": "2023-07-26T00:58:47Z"}, {"author": "Martin Thomson", "text": "

m2me

", "time": "2023-07-26T00:58:59Z"}, {"author": "Alex Chernyakhovsky", "text": "

middle-out encryption?

", "time": "2023-07-26T00:59:18Z"}, {"author": "John Scudder", "text": "

What Paul said.

", "time": "2023-07-26T00:59:18Z"}, {"author": "John Scudder", "text": "

Correction, SAVNET

", "time": "2023-07-26T01:00:09Z"}, {"author": "Eric Rescorla", "text": "

Michael Richardson said:

\n
\n

Ben works for an operator called META

\n
\n

No question

", "time": "2023-07-26T01:00:13Z"}, {"author": "Daniel Gillmor", "text": "

Martin Thomson said:

\n
\n

maybe we need to work on a middle-to-middle encryption definition before we can proceed with this

\n
\n

is that pronounce \"mimi\"?

", "time": "2023-07-26T01:00:14Z"}, {"author": "Martin Thomson", "text": "

mimi does e2ee

", "time": "2023-07-26T01:00:42Z"}, {"author": "Ted Hardie", "text": "

There was also a preso at this DISPATCH; you can review the preso to get context.

", "time": "2023-07-26T01:00:59Z"}, {"author": "Martin Thomson", "text": "

so we probably need an etee wg to work on m2me

", "time": "2023-07-26T01:01:07Z"}, {"author": "Eric Rescorla", "text": "

e2m2e2m2e

", "time": "2023-07-26T01:01:26Z"}, {"author": "Martin Thomson", "text": "

CSSSSC and CSSSSSC

", "time": "2023-07-26T01:02:00Z"}, {"author": "John Scudder", "text": "

At a very cursory skim of the SAVNET charter this is roughly in-scope. (Remember that it\u2019s an AD\u2019s prerogative to change his mind.)

", "time": "2023-07-26T01:02:01Z"}, {"author": "Martin Thomson", "text": "

Which reminds me of \"Arnold Rimmer, BSC, SSC\"

", "time": "2023-07-26T01:02:32Z"}, {"author": "Eric Rescorla", "text": "

Bronze Swimming Certificate, Silver Swimming Certificate

", "time": "2023-07-26T01:03:20Z"}]