IETF
LAMPS
lamps@jabber.ietf.org
Wednesday, November 9, 2022< ^ >
synp has set the subject to: LAMPS Interim Meeting 2022-Apr-20
Room Configuration
Room Occupants

GMT+0
[00:06:57] cabo joins the room
[09:25:35] <zulipbot> (Massimiliano Pala) Good Morning Everybody!
[09:25:38] cabo leaves the room
[09:25:57] bhoeneis joins the room
[09:26:07] bhoeneis leaves the room
[09:27:05] bhoeneis joins the room
[09:28:19] <zulipbot> (Tim Hollebeek) Good morning, just debugging some technical difficulties
[09:29:22] <zulipbot> (Russ Housley) The chair laptop in Richmond 1 is not on the usual screen.  Not sure what to do.
[09:31:29] <zulipbot> (Tim Hollebeek) Hopefully short break as we try to get the chair laptop figured out
[09:31:42] <zulipbot> (Massimiliano Pala) ... Ahhh ... I like the smell of debugging in the morning :D Hehehehe!!!
[09:33:01] <zulipbot> (Yoav Nir) Something for the story-telling-ag, no doubt
[09:33:16] <zulipbot> (Tim Hollebeek) 3 out of 3 engineers consulted suggested that rebooting might fix it, or might make it worse
[09:33:33] <zulipbot> (Tim Hollebeek) So at least we know that our engineers are functioning normally
[09:34:21] <zulipbot> (Tim Hollebeek) 4 of 4
[09:34:51] <zulipbot> (Daniel Gillmor) wait, have you tried rebooting the engineers?
[09:35:30] <zulipbot> (Tim Hollebeek) I'm sure some engineer, somewhere, has attempted that.  I suspect it ended badly.
[09:36:00] <zulipbot> (Mike Ounsworth) Hi @**Massimiliano Pala** !
[09:36:13] <zulipbot> (Mike Ounsworth) @_**Daniel Gillmor|637** [said](https://zulip.ietf.org/#narrow/stream/68-lamps/topic/jabber/near/51870):
```quote
wait, have you tried rebooting the engineers?
```
Is that, like, taking a nap?
[09:36:44] <zulipbot> (Deb Cooley) I hope so
[09:58:29] <zulipbot> (Jake Massimo) No Panos today
[10:01:00] <zulipbot> (Sean Turner) Hi Jake!
[10:02:06] <zulipbot> (Jake Massimo) yes
[10:02:33] <zulipbot> (Jake Massimo) trrying to unmute
[10:02:46] <zulipbot> (Massimiliano Pala) Yes.
[10:02:59] <zulipbot> (Daniel Gillmor) slides disappeared here
[10:12:31] <zulipbot> (Daniel Gillmor) use the mic please
[10:16:30] <zulipbot> (Mike Ounsworth) hash-then-sign: most protocols have some kind of enveloping structure, and those often include a pre-hash at that level ... ergo including a hash in the sig alg is either A) redundant with the wrapper in the cases where it matters, or B) unnecessary in the cases were it isn't. Have I understood the arguments properly?
[10:23:28] <zulipbot> (Massimiliano Pala) Yes.
[10:26:21] <zulipbot> (Mike Ounsworth) CMS KEM-TRANS: this is another point where Panos thinks we should scrap what we have and just use HPKE.
[10:28:59] <zulipbot> (Massimiliano Pala) Is there a comment?
[10:38:31] <zulipbot> (Mike Ounsworth) One comment on cert binding is how (or whether) it differs in any significant way from RFC 5697?
[10:38:48] <zulipbot> (Massimiliano Pala) As one of the authors for composite, I think that the more tools we have in our belts, the better. There are going to be many different scenarios and if we do not have enough flexibility we might find ourselves in a corner not being able to address specific use-cases. This might translate in Billions of $$$ for replacing equipment, in some environments.
[10:40:22] <zulipbot> (Daniel Gillmor) the more flexible our mechanisms are, the more interop problems we will have.  this might translate into billions of $$$ invested in tooling that doesn't actually work because they can't talk to each other, and replacement doesn't even help.
[10:40:48] <zulipbot> (Daniel Gillmor) see also ipsec, sigh
[10:41:14] <zulipbot> (Yoav Nir) +1: With 5 ways to adopt the new technology, implementers will wait and see.
[10:42:05] <zulipbot> (Daniel Gillmor) or each pick a different one, and then you can only interop with 20% of the deployed base :/
[10:47:57] <zulipbot> (Massimiliano Pala) @Daniel: I do not agree, I think the situation is way different than IPSec specifications. We are leveraging crypto-agility mechanism that are already supported in many crypto libraries. Not everybody must support RSA in their systems, right? From this point of view, I think, the situation is very different from the example you mention.
[10:49:14] <zulipbot> (Massimiliano Pala) The interoperability layer, here, is X.509... and nobody is changing that :D
[10:51:05] <zulipbot> (Daniel Gillmor) we get vulnerabilities in widely-used X.509 utilities what, every month or two?  these are not great examples of reliable crypto-agility mechanisms
[10:52:13] <zulipbot> (Daniel Gillmor) days since last major X.509 library vulnerability announcement: 8
[10:52:39] <zulipbot> (Daniel Gillmor) (granted, https://www.openssl.org/news/secadv/20221101.txt is not a failure in the crypto-agility, but the point is those things are super complex already)
[10:56:24] <zulipbot> (Tim Hollebeek) They actually aren't super complex.  As mission critical software components go, they're actually on the simple side.
[10:56:50] <zulipbot> (Daniel Gillmor) and yet they still fail regularly ­čśČ
[10:56:51] <zulipbot> (Mike Ounsworth) @_**Daniel Gillmor|637** [said](https://zulip.ietf.org/#narrow/stream/68-lamps/topic/jabber/near/52263):
```quote
the more flexible our mechanisms are, the more interop problems we will have.  this might translate into billions of $$$ invested in tooling that doesn't actually work because they can't talk to each other, and replacement doesn't even help.
```
I some sense, breadth is the curse of X.509 + CMS: the usecases it supports are ludicrously wide: from authentication in TLS / IKE / QUIC and friends, to bulk file encryption, to multi-recipient emails, to Windows code signing.
[10:57:03] <zulipbot> (Tim Hollebeek) However, if you are arguing that not enough effort has gone into making sure the coding quality is where it needs to be, you will get no argument from me.
[10:57:29] <zulipbot> (Russ Housley) My experience with HPKE and COSE is still stinging.  I took my name off the I-D.  I am not going to work on a similar specification for CMS because all of the same issues will come up again.  HPKE is really a merger of two parts of CMS, and I think they need to remain separate.
[11:00:50] <zulipbot> (Daniel Gillmor) Russ, is there some more detailed explanation  of your views on HPKE that you can point to?  i don't think i know the history, but i'd be happy to learn from it.
[11:01:34] <zulipbot> (Mike Ounsworth) The ISARA press release referenced in Max's slides:
https://www.isara.com/company/newsroom/isara-dedicates-four-hybrid-certificate-patents-to-the-public.html
[11:02:02] <zulipbot> (Russ Housley) Long discussion on cose@ietf.org with "HPKE" in the subject
[11:11:07] <zulipbot> (Daniel Van Geest) Regarding the patents, I have the signed patent disclaimer documents in my inbox and can send to anyone who requests.  I'm also told they can be found on the USPTO site, though haven't verified myself.  I attempted to update the IETF IPR statements but there were some issues with email access for the original IPR submitter, that should be resolved soon.
[11:13:54] <zulipbot> (Mike Ounsworth) @_**Daniel Van Geest|1918** [said](https://zulip.ietf.org/#narrow/stream/68-lamps/topic/jabber/near/52453):
```quote
Regarding the patents, I have the signed patent disclaimer documents in my inbox and can send to anyone who requests.  I'm also told they can be found on the USPTO site, though haven't verified myself.  I attempted to update the IETF IPR statements but there were some issues with email access for the original IPR submitter, that should be resolved soon.
```
Clarifying question: you mean ISARA patents, not NIST Kyber patents?
[11:14:07] <zulipbot> (Daniel Van Geest) correct
[11:16:01] <zulipbot> (Daniel Gillmor) backward compatibility modes are recipes for security failure
[11:17:30] <zulipbot> (Deb Cooley) And very difficult to see how a composite structure (even K of N algorithms) will help backward compatability
[11:18:38] <zulipbot> (Jan Klau├čner) @Deb Cooley: we would like to explain that when KofN is ready
[11:20:33] <zulipbot> (Daniel Gillmor) i think massimiliano is saying that the logic for acceptance of a generic composite is just "do i support each of the included OIDs independently" is that right?
[11:20:46] <zulipbot> (Deb Cooley) sure.  but your old devices will only do one algorithm, so K has to be 1.
[11:21:25] <zulipbot> (Daniel Gillmor) (i'm talking about N of N composites here, to be clear)
[11:21:25] <zulipbot> (Mike Ounsworth) Good point @**Aron Wussler** : designing a secure shared secret combiner for EdDSA + Kyber is fairly easy. Designing a combiner that can securely handle like Kyber + static-static DH + RSA Key Trans requires a more complex combiner with more complex security analysis ... aka a much harder problem.
[11:22:06] <zulipbot> (Deb Cooley) any offline protocol (i.e mail) is going to be much harder since the sender doesn't know what the recipient can do.
[11:22:34] <zulipbot> (Deb Cooley) real time protocols - TLS, IPSec, etc - are much much easier
[11:23:00] <zulipbot> (Jan Klau├čner) @Daniel: yes, if one is not supported, the algorithms fails
[11:24:04] <zulipbot> (Daniel Gillmor) so then an implementation *can't* add support for an uncertain algorithm without adding support for it on its own
[11:24:30] <zulipbot> (Mike Ounsworth) @_**Daniel Gillmor|637** [said](https://zulip.ietf.org/#narrow/stream/68-lamps/topic/jabber/near/52509):
```quote
i think massimiliano is saying that the logic for acceptance of a generic composite is just "do i support each of the included OIDs independently" is that right?
```
Right. So here's Generic (stylized ASN.1):
``` algorithm: AlgorithmIdentifier{id-composite-key}
subjectPublicKey: CompositePublicKey {
  SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: ecPublicKey
      parameters: prime256v1
      }
    subjectPublicKey: <ec key octet string>
    },
    SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: rsaEncryption
      parameters: NULL
      }
    subjectPublicKey: <rsa key octet string>
    }
  }
```
And the equiv explicit:
```
algorithm: AlgorithmIdentifier{id-pk-example-ECandRSA}
subjectPublicKey: CompositePublicKey {
  SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: ecPublicKey
      parameters: prime256v1
      }
    subjectPublicKey: <ec key octet string>
    },
    SubjectPublicKeyInfo {
    algorithm: AlgorithmIdentifier {
      algorithm: rsaEncryption
      parameters: NULL
      }
    subjectPublicKey: <rsa key octet string>
    }
  }
```
The literal only difference is outer OID.
In both cases you have to iterate through the inner SPKIs and decide if you support them. In the Explicit case you have to *also* check some mapping table to make sure those line up with that you expected from the explicit outer OID.
[11:24:31] <zulipbot> (Jan Klau├čner) @Deb: yes, thats right. But we think also of other future use cases that do not only regard backwards compatibility where K might be 2
[11:25:10] <zulipbot> (Daniel Gillmor) that strikes me as a contradictory position.
[11:25:23] <zulipbot> (Yoav Nir) Are others actually seeing the screen share?
[11:25:36] <zulipbot> (Daniel Gillmor) no, slides are not yet visible for me.
[11:26:02] <zulipbot> (Deb Cooley) screen shares are slow...
[11:26:15] <zulipbot> (Deb Cooley) not here in the room either.
[11:26:54] <zulipbot> (Yoav Nir) We're seeing the "A screen share is being started..." message.  Maybe the meeting will end before it becomes visible.
[11:26:55] <zulipbot> (Esko Dijk) Problem with screen shares is that the sharer has to click a button a number of times ("Are your sure?" -> yes) and these questions pop up late.
[11:28:00] <zulipbot> (Sean Turner) No slides for this
[11:29:59] <zulipbot> (Tim Hollebeek) Yes, just a friendly reminder that if you have an agenda item, slides are wonderful even if brief.
[11:30:39] <zulipbot> (Jan Klau├čner) @Daniel: for this specific case we want to add the KofN draft. maybe discuss this on the list further
[11:30:52] <zulipbot> (Massimiliano Pala) @daniel, you are correct. All the PKI procedures are respected, it just adds a level of indirection to allow for validation processes to be repeated for the sequence.
[11:31:06] <zulipbot> (Massimiliano Pala) Thank everybody for the feedback and discussion!
[11:32:46] <zulipbot> (Aron Wussler) I think that the generic composite introduces several complexities:
- It allows implementers (or even worse users) to pick unreasonable mixes
- Makes KDF way more complex
- Allows attacks when reusing keys across different combinations
[11:46:19] cabo leaves the room
[11:47:45] cabo joins the room
[11:50:11] bhoeneis leaves the room
[11:58:38] <zulipbot> (Carl Wallace) These likely don't apply to the signature discussion where the generic composite question arose last weekend. I agree explicit composite more clearly locks things down to a small subset of combinations, with the (minor) downside that implementations must change to add support for OIDs that express new combinations.
[12:04:50] cabo leaves the room
[12:08:49] cabo joins the room
[12:21:20] cabo leaves the room
[12:53:54] cabo joins the room
[18:08:22] cabo leaves the room
[18:13:31] cabo joins the room
[19:14:54] cabo leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!