IETF
LAMPS
lamps@jabber.ietf.org
Friday, March 25, 2022< ^ >
Meetecho has set the subject to: LAMPS at IETF 112
Room Configuration
Room Occupants

GMT+0
[08:31:40] Meetecho joins the room
[08:45:07] Evangelos Karatsiolis_web_252 joins the room
[08:45:07] Yoshiro Yoneya_web_234 joins the room
[08:45:07] Christine van Vredendaal_web_229 joins the room
[08:45:15] Yoshiro Yoneya joins the room
[08:48:16] Yoshiro Yoneya_web_234 leaves the room
[08:48:20] Yoshiro Yoneya_web_570 joins the room
[08:48:48] Daniel Gillmor_web_823 joins the room
[08:49:00] Clint McKay_web_421 joins the room
[08:49:18] Jan Klaußner_web_975 joins the room
[08:49:18] Christine van Vredendaal_web_229 leaves the room
[08:49:24] dkg joins the room
[08:49:25] Scott Fluhrer_web_539 joins the room
[08:49:47] Massimiliano Pala_web_588 joins the room
[08:50:22] Ken Takayama_web_183 joins the room
[08:50:24] <Massimiliano Pala_web_588> Good Morning Everybody!
[08:52:31] David Millman_web_287 joins the room
[08:52:39] Peter Campbell_web_989 joins the room
[08:53:25] Wesley Eddy_web_301 joins the room
[08:53:47] Christine van Vredendaal_web_541 joins the room
[08:54:07] Tim Hollebeek_web_468 joins the room
[08:54:15] Wesley Eddy_web_301 leaves the room
[08:54:44] Rich Salz_web_918 joins the room
[08:54:59] Rebecca Guthrie_web_335 joins the room
[08:55:22] <Tim Hollebeek_web_468> Good morning!  Wish I could be there in person and see you all again!
[08:55:23] Alexey Melnikov_web_386 joins the room
[08:55:46] Alison Becker_web_763 joins the room
[08:55:48] Johannes Roth_web_971 joins the room
[08:56:00] John Gray_web_515 joins the room
[08:56:27] Christian Veenman_web_248 joins the room
[08:56:38] Roman Danyliw_web_891 joins the room
[08:56:39] Michael B_web_538 joins the room
[08:56:45] Yoav Nir_web_542 joins the room
[08:56:46] Florence D_web_550 joins the room
[08:57:03] Dirk Hugo_web_210 joins the room
[08:57:07] Benjamin Kaduk_web_319 joins the room
[08:57:12] Hernâni Marques_web_256 joins the room
[08:57:16] David Millman_web_287 leaves the room
[08:57:22] Michael B_web_538 leaves the room
[08:57:26] Michael B_web_287 joins the room
[08:57:52] Sean Turner_web_991 joins the room
[08:57:56] Leonie Bruckert_web_735 joins the room
[08:58:10] Dirk Hugo_web_210 leaves the room
[08:58:35] Steffen Fries_web_628 joins the room
[08:58:41] David von Oheimb_web_406 joins the room
[08:58:43] Justus Winter_web_546 joins the room
[08:58:49] justus joins the room
[08:58:58] Russ Housley_web_130 joins the room
[08:59:14] Jonathan Hammell_web_937 joins the room
[08:59:16] cw-ietf joins the room
[08:59:38] Wei Pan_web_744 joins the room
[08:59:40] Quynh Dang_web_840 joins the room
[08:59:44] David von Oheimb_web_406 leaves the room
[08:59:48] David von Oheimb_web_602 joins the room
[08:59:51] Ties de Kock_web_293 joins the room
[08:59:52] Daniel Huigens_web_722 joins the room
[08:59:52] Corey Bonnell_web_898 joins the room
[09:00:10] Valery Smyslov_web_726 joins the room
[09:00:15] Tadahiko Ito_web_292 joins the room
[09:00:20] <Rich Salz_web_918> Thanks for being the stand-in chair for so many meetings, Alexey!
[09:00:33] Daniel Huigens_web_722 leaves the room
[09:00:37] Daniel Huigens_web_815 joins the room
[09:00:44] <Christian Veenman_web_248> Good morning!
[09:00:55] Juhamatti Kuusisaari_web_862 joins the room
[09:01:01] Alyssa Thompson_web_621 joins the room
[09:01:07] Thomas Werner_web_141 joins the room
[09:01:19] PRAT Julien_web_242 joins the room
[09:01:26] kaduk@jabber.org/barnowl joins the room
[09:01:38] Michael Jenkins_web_475 joins the room
[09:01:57] Mike Ounsworth_web_800 joins the room
[09:01:57] Juhamatti Kuusisaari_web_862 leaves the room
[09:02:02] Deb Cooley_web_505 joins the room
[09:02:07] Deb Cooley_web_505 leaves the room
[09:02:11] Deb Cooley_web_655 joins the room
[09:02:12] Daniel Huigens_web_815 leaves the room
[09:02:16] Daniel Huigens_web_742 joins the room
[09:02:17] Bas Westerbaan_web_236 joins the room
[09:02:21] Simon Romano_web_457 joins the room
[09:02:26] Shu-Fang Hsu_web_364 joins the room
[09:02:34] Guilin WANG_web_502 joins the room
[09:02:42] Bernie Hoeneisen_web_672 joins the room
[09:02:43] kaduk@jabber.org/barnowl has set the subject to: LAMPS at IETF 113
[09:02:44] Andreas Huelsing_web_183 joins the room
[09:03:29] Colin Whorlow_web_622 joins the room
[09:03:34] Daniel Huigens_web_742 leaves the room
[09:03:38] Daniel Huigens_web_909 joins the room
[09:03:42] <dkg> kaduk: it worked
[09:03:52] Stefan Santesson_web_661 joins the room
[09:04:04] <kaduk@jabber.org/barnowl> woohoo!  The in-meetecho chat doesn't show the body of the message I
used to do it, interestingly.
[09:04:05] Mike Boyle_web_940 joins the room
[09:04:10] Daniel Huigens_web_909 leaves the room
[09:04:14] Daniel Huigens_web_350 joins the room
[09:05:02] Daniel Huigens_web_350 leaves the room
[09:05:06] Daniel Huigens_web_477 joins the room
[09:05:08] Ali Noman_web_948 joins the room
[09:06:17] Thom Wiggers_web_501 joins the room
[09:06:32] David von Oheimb_web_602 leaves the room
[09:06:36] David von Oheimb_web_257 joins the room
[09:06:45] Daniel Huigens_web_477 leaves the room
[09:06:49] Daniel Huigens_web_651 joins the room
[09:08:13] Florence D_web_550 leaves the room
[09:08:13] Daphanie Nisbeth_web_128 joins the room
[09:08:17] Florence D_web_373 joins the room
[09:08:52] Armando Faz-Hernández_web_210 joins the room
[09:09:53] Jean-Michel Combes_web_931 joins the room
[09:10:10] Alan Hayward_web_832 joins the room
[09:10:28] Ludovic Perret_web_642 joins the room
[09:10:32] Daniel Huigens_web_651 leaves the room
[09:10:36] Daniel Huigens_web_344 joins the room
[09:11:17] <Roman Danyliw_web_891> Yes, PS
[09:11:26] <Tim Hollebeek_web_468> Always nice when someone hides the bodies for you.
[09:12:02] Juhamatti Kuusisaari_web_909 joins the room
[09:12:48] Juhamatti Kuusisaari_web_909 leaves the room
[09:13:50] <Sean Turner_web_991> So many enrollment protocols to progress! :)
[09:14:30] <Mike Ounsworth_web_800> +1 for "whole new body of work"
[09:14:37] <kaduk@jabber.org/barnowl> Sean: I dunno, maybe we should try to really fix the issues in the
enrollment protocols by writing a new enrollment protocol ;)
[09:14:52] <Sean Turner_web_991> @kaduk: mwhahaaha
[09:14:55] <Roman Danyliw_web_891> @tero - yes that would be the process
[09:15:07] <Massimiliano Pala_web_588> You need to enroll in the enrollment protocol mailing list first...
[09:15:08] <Yoav Nir_web_542> @kaduk: isn't that ACME?  or EST?
[09:15:12] <Sean Turner_web_991> I mean we should really move p10. Maybe I will do that ;)
[09:15:18] <kaduk@jabber.org/barnowl> The IESG can run a last-call on a "status-change document" to promote
an existing RFC from PS to IS
[09:15:38] <Mike Ounsworth_web_800> "Move CMP to IS" almost sounds like a charterable chunk of work ...
[09:15:43] Colin Whorlow_web_622 leaves the room
[09:15:45] <Thom Wiggers_web_501> I think Tero is using his phone so he doesn’t see chat, fyi
[09:15:47] Colin Whorlow_web_963 joins the room
[09:15:53] <kaduk@jabber.org/barnowl> I think
https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20/
is the documentation for such "status-change document"s
[09:15:55] Satoru Kanno_web_498 joins the room
[09:16:20] Ludovic Perret_web_642 leaves the room
[09:16:21] <Roman Danyliw_web_891> @russ -- adding this story of "CMP Updates" is first; then maybe a bis for IS later in the shepherd write-up will motivate the current editorial style
[09:16:24] Ludovic Perret_web_749 joins the room
[09:17:05] Panos Kampanakis_web_907 joins the room
[09:17:07] <Roman Danyliw_web_891> @thom-wiggers: hadn't noticed.  thanks
[09:17:10] <Russ Housley_web_130> @roman: Ack
[09:18:41] Tero Kivinen_web_261 joins the room
[09:18:56] <Massimiliano Pala_web_588> is there a registry we need to maintain?
[09:18:59] <Sean Turner_web_991> @roman: Can we move RFC 2986, which is Informational, to IS?
[09:19:26] <kaduk@jabber.org/barnowl> > it is not a candidate for any level of internet standard
[09:19:39] <dkg> why can't future expansion be to change …/.well-known/cmp/… to …/.well-known/cmp2/… ?
[09:19:54] <Sean Turner_web_991> @Massimiliiano: At this point, I beleieve it is only the "top": /cmp and /est
[09:20:06] <Tim Hollebeek_web_468> yeah, that was my question.  the previous label is the expansion point
[09:20:13] <kaduk@jabber.org/barnowl> The .well-known DEs might give you a funny look (I suppose we could
ask)
[09:20:41] <Tim Hollebeek_web_468> could even do /est/v1/arbitrarylabel
[09:20:46] <Tim Hollebeek_web_468> so it's versioned
[09:21:16] <Alexey Melnikov_web_386> Option #4 (not using .well-known) is violating HTTP recommendations, so this is not going to be good.
[09:21:53] <Sean Turner_web_991> You can avoid using .well-known, but expect a fight.
[09:23:15] <dkg> i think the .well-known DEs will give a funny look anyway, given the "discovery problems" that mcr just raised.
[09:23:20] <Sean Turner_web_991> I am good with that
[09:23:35] <Yoav Nir_web_542> example.com/.well-known/RFCxxxxx/whatever
[09:24:21] <Roman Danyliw_web_891> @sean: I'm pretty sure no, RFC2986 got published informational.  The upgrade to IS is only possible if you start as a PS.
[09:24:50] <Sean Turner_web_991> I can work with Magnus/Burt to do that.
[09:27:10] Alan Hayward_web_832 leaves the room
[09:27:14] Alan Hayward_web_930 joins the room
[09:27:25] Quynh Dang_web_840 leaves the room
[09:27:29] Quynh Dang_web_244 joins the room
[09:28:13] <Roman Danyliw_web_891> @hendrik: actions caught for reviews or re-reviews.
[09:28:46] <Mike Ounsworth_web_800> Oh lord, Sean's going full Santa!
[09:29:00] <dkg> are you sure it's not karl marx?
[09:30:20] <Rich Salz_web_918> "why not both?"
[09:31:37] Ching-Heng Ku_web_816 joins the room
[09:32:45] <dkg> i agree with Alexey
[09:33:11] <dkg> it's ok russ, carry on
[09:33:13] <dkg> we have time
[09:33:39] MichaelRichardson joins the room
[09:33:59] <dkg> i didn't read the draft yet then ! :P
[09:34:15] <MichaelRichardson> I think that Santa is probably some kind of Marxist.  
[09:34:33] Tomofumi Okubo_web_819 joins the room
[09:35:07] <MichaelRichardson> @Roman, so if we RFC2986bis, then we could actually publish as PS.  Should we do that?  I guess I can start a thread.
[09:36:01] Jean-Michel Combes_web_931 leaves the room
[09:36:05] Jean-Michel Combes_web_900 joins the room
[09:36:32] Daniel Huigens_web_344 leaves the room
[09:36:36] Daniel Huigens_web_333 joins the room
[09:36:41] Bernie Hoeneisen_web_672 leaves the room
[09:36:45] Bernie Hoeneisen_web_200 joins the room
[09:37:00] <Massimiliano Pala_web_588> CRL delegate signer.
[09:37:08] <Corey Bonnell_web_898> CRL issuer
[09:37:16] Jean-Michel Combes_web_900 leaves the room
[09:37:20] Jean-Michel Combes_web_660 joins the room
[09:38:08] Florence D_web_373 leaves the room
[09:38:12] Florence D_web_599 joins the room
[09:38:13] <Roman Danyliw_web_891> @mkr - I don't know the history of why informational was chosen for RFC2986, but if we make a bis, it could be PS (from a process perspective)
[09:39:50] zhang jun_web_755 joins the room
[09:39:52] <Sean Turner_web_991> We are just trying to drive the average time to RFC down ;)
[09:39:55] Daniel Huigens_web_333 leaves the room
[09:39:59] Daniel Huigens_web_153 joins the room
[09:40:07] <kaduk@jabber.org/barnowl> Going back a ways to the CMP well-known URI question, I did send Mark
Nottingham an email to try to get his thoughts explicitly.
[09:40:13] <Roman Danyliw_web_891> I hope this doc is clean so we can pull off sending  a -00 to the IESG?
[09:41:32] <Sean Turner_web_991> @Roman: I think it is clean, but we'll see what the reviewers find.
[09:41:49] <kaduk@jabber.org/barnowl> Do I need to take a look at something? ;)
[09:42:02] zhang jun_web_755 leaves the room
[09:42:53] Roman Danyliw_web_891 leaves the room
[09:42:57] Roman Danyliw_web_916 joins the room
[09:45:38] Christine van Vredendaal_web_541 leaves the room
[09:45:42] Christine van Vredendaal_web_607 joins the room
[09:45:42] Colin Whorlow_web_963 leaves the room
[09:45:46] Colin Whorlow_web_770 joins the room
[09:46:13] <Sean Turner_web_991> With all your free time, you can check out: https://datatracker.ietf.org/doc/draft-ietf-lamps-8410-ku-clarifications/ :)
[09:47:09] <kaduk@jabber.org/barnowl> Oh, but it's already the -00 ... so that means I should *not* look
[09:47:54] <Tero Kivinen_web_261> This sounds like having some discussion with the https://www.m3aawg.org/ would be useful. There might be more of those implementors present that can actually do something for this.
[09:48:22] Taiji Kimura_web_977 joins the room
[09:48:30] Stephan Ehlen_web_513 joins the room
[09:48:52] <Rich Salz_web_918> showing algorithm diffs as python fragments is cool!
[09:49:13] <Sean Turner_web_991> @Ben ;)
[09:49:59] Christine van Vredendaal_web_607 leaves the room
[09:50:03] Christine van Vredendaal_web_796 joins the room
[09:50:41] Christine van Vredendaal_web_796 leaves the room
[09:50:45] Christine van Vredendaal_web_200 joins the room
[09:50:55] Daniel Huigens_web_153 leaves the room
[09:50:59] Daniel Huigens_web_631 joins the room
[09:51:15] <Russ Housley_web_130> @dkg: Getting rid of legacy will take a really long time.  Consider pine as one example
[09:52:30] Christine van Vredendaal_web_200 leaves the room
[09:52:34] Christine van Vredendaal_web_727 joins the room
[09:53:00] Stavros Kousidis_web_653 joins the room
[09:53:21] <Mike Ounsworth_web_800> "There's nothing more permanent then a temporary solution"
[09:53:26] <Mike Ounsworth_web_800> *than
[09:53:38] Daniel Huigens_web_631 leaves the room
[09:53:42] Daniel Huigens_web_892 joins the room
[09:54:01] Florence D_web_599 leaves the room
[09:54:25] Florence D_web_344 joins the room
[09:57:29] Alan Hayward_web_930 leaves the room
[09:57:33] Alan Hayward_web_594 joins the room
[09:57:57] Tomofumi Okubo_web_819 leaves the room
[09:58:13] Daniel Huigens_web_892 leaves the room
[09:58:17] Daniel Huigens_web_716 joins the room
[09:58:21] Christine van Vredendaal_web_727 leaves the room
[09:58:25] Christine van Vredendaal_web_877 joins the room
[10:00:23] Taiji Kimura_web_977 leaves the room
[10:01:41] Andrew S_web_793 joins the room
[10:01:44] <Rich Salz_web_918> hahahaa
[10:01:59] Andreas Huelsing_web_183 leaves the room
[10:02:09] Massimiliano Pala_web_588 leaves the room
[10:02:13] Massimiliano Pala_web_507 joins the room
[10:02:29] Massimiliano Pala_web_507 leaves the room
[10:02:33] Massimiliano Pala_web_592 joins the room
[10:03:51] Yoshiro Yoneya_web_570 leaves the room
[10:03:55] Yoshiro Yoneya_web_303 joins the room
[10:03:58] <Jonathan Hammell_web_937> Would a failure to find "Thursday dinner plans" in the obscured headers not work?  Adding "**spam**" or whitespace before/after would not affect that.
[10:04:14] <Yoav Nir_web_542> Definitely not when you open your mail application and have to go over 100 emails, most of which are irrelevant. That's not a use case for careful inspection.
[10:04:16] <Mike Ounsworth_web_800> I feel like all 5 of them are in this room ..
[10:07:17] <Mike Ounsworth_web_800> @dkg Naīvely, you could ignore the plaintext version if there's an encrypted version, but I suppose the attack you need to prevent is that Bob and Frank see different content for the same email?
[10:09:03] Daniel Huigens_web_716 leaves the room
[10:09:07] Daniel Huigens_web_750 joins the room
[10:09:33] Aron Wussler_web_598 joins the room
[10:09:54] <justus> maybe the inner (protected) header could indicate that the outside version was obscured by the sender?
[10:10:57] <Rich Salz_web_918> agreed: impressive detail dkg&team
[10:12:40] <Sean Turner_web_991> we need to get pink shoes. Then I can always be in the box.
[10:13:12] <Ludovic Perret_web_749> julien
[10:13:44] Panos Kampanakis_web_907 leaves the room
[10:13:48] Panos Kampanakis_web_528 joins the room
[10:14:11] <Yoav Nir_web_542> ASN.1 requires trigger warnings regardless of who made it
[10:14:30] <Christian Veenman_web_248> Agreed :)
[10:15:22] Daniel Huigens_web_750 leaves the room
[10:15:26] Daniel Huigens_web_137 joins the room
[10:15:39] Colin Whorlow_web_770 leaves the room
[10:15:43] Colin Whorlow_web_540 joins the room
[10:15:56] Daniel Huigens_web_137 leaves the room
[10:16:00] Daniel Huigens_web_687 joins the room
[10:16:42] Thom Wiggers_web_501 leaves the room
[10:17:10] <kaduk@jabber.org/barnowl> Did "we" consider a short RFC that Updates: ACP to note that the
CSR/attributes usage is believed to be "wrong" (not in that phrasing)?
[10:18:13] <cw-ietf> the value field needs a tag
[10:20:42] <kaduk@jabber.org/barnowl> (RFC 8295 cites PKCS#12 to pull out the number Sean is looking for)
[10:21:13] <kaduk@jabber.org/barnowl> oops, reading on it cites a pile of PKCS, so disregard
[10:21:21] Thom Wiggers_web_455 joins the room
[10:23:24] Florence D_web_344 leaves the room
[10:23:28] Florence D_web_817 joins the room
[10:23:34] <dkg> nice squirrel
[10:26:15] <Rich Salz_web_918> "nice squirrel" is an oxymoron, Daniel.
[10:26:17] <MichaelRichardson> But, at least reading RFC8295 is what we need to do.
[10:26:31] <Massimiliano Pala_web_592> (who is "we"?)
[10:26:45] <Bas Westerbaan_web_236> Many of the AES variants are not meant to be used in practice and are less safe than you might expect. (Eg for Kyber and Dilithium)
[10:26:50] <kaduk@jabber.org/barnowl> s/nice/very representative/
[10:26:59] <MichaelRichardson> the CSR attributes update design team....
[10:27:19] <Sean Turner_web_991> @massimiliano: I believe it's a group of ACP implementers
[10:28:22] <Thom Wiggers_web_455> Why could the 3 variants of Dilithium not just get different oids
[10:28:29] <MichaelRichardson> well, at least David and I are ACP/RFC8994/RFC8995 implementers, and Dan who has other deployed EST stuff.
[10:28:34] <Massimiliano Pala_web_592> prameters?
[10:29:33] Justus Winter_web_546 leaves the room
[10:29:56] <Russ Housley_web_130> As you will see in the next few talks, each algorithm and parameter set will get a separate OID.  Thus, parameters are always absent.  The OID tells all of that.
[10:30:11] <Mike Ounsworth_web_800> but if a legacy system nether supports a PQ algorithm, nor does it support that size (ex.: pub key buffers cap at 200,000 kb), then so what?
[10:30:36] Alan Hayward_web_594 leaves the room
[10:30:40] Alan Hayward_web_556 joins the room
[10:30:55] <Mike Ounsworth_web_800> ... if you've gotta patch it to add PQ crypto lib support, then you can patch the buffer limits at the same time.
[10:30:58] Justus Winter_web_876 joins the room
[10:31:11] <Sean Turner_web_991> That's the CAT pic extension
[10:31:24] <Roman Danyliw_web_916> OIDs for greasing for certificates?
[10:31:39] <Sean Turner_web_991> 3709 put the cat pic in ;)
[10:31:58] <dkg> i'm out of the queue because that was my question: are we talking about private keys or public keys.  sounds like he's focusing on private keys
[10:32:24] <Bas Westerbaan_web_236> related to private key question on a different rfc: https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1
[10:32:31] Wei Pan_web_744 leaves the room
[10:32:35] Wei Pan_web_710 joins the room
[10:33:52] <Massimiliano Pala_web_592> That is what I feared - exactly as reported, when I implemented our own code I would have really liked that we could use OID + SecLevel as parameters ... so, I did wrap the current approach and it really helped the practical aspects of working with the keys (especially for ease of use/display for the final user). It is unfortunate we will have to type so much more in our code... hehehehe... when we will add hash-n-sign to the mix... prepare your copy&paste capabilities....
[10:34:23] <Sean Turner_web_991> @dkg: Will send an email, but I think your example I-Ds looks good WRT the KU selections.
[10:34:23] <Bas Westerbaan_web_236> I wouldn't call it private-key compression, but rather deterministic key regeneration
[10:34:38] <Sean Turner_web_991> @bas nice!
[10:34:56] <Tim Hollebeek_web_468> sounds like a synonym for lossless compression
[10:35:19] <Tim Hollebeek_web_468> which is a property that's essential in this case anyway :)
[10:35:34] <Bas Westerbaan_web_236> That's really bad. The Kyber and Dilithium AES variants are not as safe as the claimed level!
[10:35:42] <John Gray_web_515> We did a research project a couple years ago and added Megabytes of data into certificate and watched some stuff blow up, but surprisingly a lot of things continued to work...  https://www.inderscience.com/info/inarticle.php?artid=117887
[10:37:02] <Yoav Nir_web_542> A lot of things copied their x509 library from some library like OpenSSL.  There's not all that many different x509 implementations out there.
[10:37:30] <kaduk@jabber.org/barnowl> > a lot of things copied their x509 library from ... OpenSSL
"they chose poorly"
[10:38:05] <Yoav Nir_web_542> Using OpenSSL >>> rolling your own
[10:38:22] <Mike Ounsworth_web_800> @dkg (self-correction) I think he mentioned that it's not the endpoint-agent itself that's the problem, it's the transport layers to get the keys to the endpoint agent.
[10:40:03] <Russ Housley_web_130> We have 20 minutes left in the meeting.  Need to let the speaker get to their key point.  Then, it is clear that we will need an virtual interim meeting
[10:40:16] <Sean Turner_web_991> @Russ +1
[10:40:40] Doug Montgomery_web_634 joins the room
[10:40:50] <Rich Salz_web_918> IBM has a huge deployed base in the financial biz, and they want a way to pass around long keys.
[10:41:14] <Rich Salz_web_918> Like, do you want your CCard company to be quantum-safe? :)
[10:41:26] <Mike Ounsworth_web_800> @dkg in the paper my colleague John Gray posted, see Table 3 on p. 10: we found that Firefox and OpenSSL have buffer issues; but easily fixed with a recompile. https://www.inderscience.com/info/inarticle.php?artid=117887
[10:41:55] <Massimiliano Pala_web_592> There are many protocols where there are packet size limitations that are hard to change (maybe implemented within chipsets) - compression might help this use-case, I guess.
[10:41:57] <dkg> Mike: right, and they'll need a recompile to incorporate the new algorithms anyway,  think
[10:41:57] Doug Montgomery_web_634 leaves the room
[10:42:01] Doug Montgomery_web_903 joins the room
[10:42:21] <Christian Veenman_web_248> So if I understand correctly it's basically: Compressing keys so that these legacy platforms can handle the size vs having these legacy platforms fixing the max private key size issue
[10:42:36] <dkg> (unless you're talking about, for example, a libnss upgrade behind the scenes that firefox is unaware of, but i think most firefox implementations ship with their own copy of libnss)
[10:42:36] <Christian Veenman_web_248> Or am I wrong?
[10:42:50] <Mike Ounsworth_web_800> I guess the bigger issue is, for example, if the app DB that needs to hold the keys does not have wide enough columns.
[10:43:02] <dkg> Christian -- that's what it sounds like to me.
[10:43:10] <Massimiliano Pala_web_592> Basically, buying time before you need to redesign your system.
[10:43:29] <Rich Salz_web_918> "One does not simply redesign a mainframe"
[10:43:34] <dkg> sounds like inserting a bunch of complexity into the entire interoperable ecosystem for the sake of not fiddling with the legacy bits
[10:43:36] <kaduk@jabber.org/barnowl> What was that line from earlier..."there is nothing more permanent
than a temporary solution"?
[10:43:37] <Yoav Nir_web_542> Mainframes are for the most part running updated software. There's a lot more Windows XP or 7 in production than there are mainframes with z/OS 1.x
[10:43:37] <Deb Cooley_web_655> +1 Rich
[10:43:56] Daniel Huigens_web_687 leaves the room
[10:43:57] <John Gray_web_515> We have been experimenting with PQ keys and composites and there are some certificate combinations that aren't actually that bad (4-6kb certs).   So we haven't needed to use additional compression as many schemes (like SPHINCS) for instance, already employ compression where possible to make keys as small as possible.
[10:44:00] Daniel Huigens_web_569 joins the room
[10:44:05] <Roman Danyliw_web_916> It seems like it might be an argument about how much of the overall system you might need to change.  The design I'm hearing is that the specific sub-system doing the crypto operations can be updated for PQC.  However, the sub-system that transports key is different, and this work would mitigate the need to change it
[10:44:16] <dkg> Yoav: there were *always* more windows XP systems than mainframes with z/OS
[10:44:27] <Yoav Nir_web_542> :-)
[10:45:08] <Thom Wiggers_web_455> AFAIK none of the finalists have compressed key formats by the way…
[10:45:10] <Yoav Nir_web_542> I meant proportions. A typical mainframe has 1-3 system programmers "taking care of it".  The typical PC got installed some time long ago
[10:45:39] <dkg> good luck getting your windows XP system to run dilithium via the core crypto stack 😛
[10:45:39] Colin Whorlow_web_540 leaves the room
[10:45:43] Colin Whorlow_web_539 joins the room
[10:45:49] Daniel Huigens_web_569 leaves the room
[10:45:50] <Thom Wiggers_web_455> You can store precomputed data in private keys but that’s implementation hacks
[10:45:53] Daniel Huigens_web_989 joins the room
[10:46:21] <Bas Westerbaan_web_236> (That's done in RSA private keys.)
[10:46:22] Daniel Huigens_web_989 leaves the room
[10:46:26] Daniel Huigens_web_462 joins the room
[10:47:11] <Thom Wiggers_web_455> (Fair)
[10:47:13] <Russ Housley_web_130> @Thom: I do not agree with the ASN.1 in the draft, but it shows a trade-off in size by sending/not sending values that can be computed.  Size / compute trade-off.
[10:47:50] <Deb Cooley_web_655> why is this draft here?  and not CFRG?  or even working w/ NIST?
[10:48:09] Simon Romano_web_457 leaves the room
[10:48:11] <Mike Ounsworth_web_800> So, is the very high-level to allow PQC priv keys to be a set of RNG seeds needed to regenerate the priv key, rather than the full priv key data?
[10:48:19] <Scott Fluhrer_web_539> It's here because it's mostly about how to represent keys in certs
[10:48:21] <Mike Ounsworth_web_800> +1 Deb
[10:48:41] <Sean Turner_web_991> @Scott: I thought this was just about privates
[10:48:47] <Bas Westerbaan_web_236> Mike: +1. Although you could make more trade-offs of course, eg https://github.com/seanturner/draft-turner-lamps-nist-pqc-kem-certificates/issues/1#issuecomment-1061823452
[10:50:05] <MichaelRichardson> dkg, imagine that some of the infrastructure is just about how to backup the contents of TEE.
[10:50:31] <Mike Ounsworth_web_800> +1 dkg: standardizing "lossless priv key regeneration" sounds easy-ish to do in proprietary code, hard to do in public standard.
[10:50:43] <MichaelRichardson> As Dan said a moment ago, this is about the doors and elevators being too small to get the HSM in/out of the data center.
[10:51:08] Doug Montgomery_web_903 leaves the room
[10:51:10] <MichaelRichardson> But, I think that your point is generally well taken.  And stateful interfaces are gonna mess with a lot of operational stuff.
[10:51:47] <dkg> John Gray: thanks for doing that legwork!
[10:53:03] Sean Turner_web_991 leaves the room
[10:53:07] Sean Turner_web_740 joins the room
[10:53:24] <Bas Westerbaan_web_236> that's the risk early adopters take of course.
[10:53:38] <Rich Salz_web_918> we did PKCS8 for private keys (yeah okay after RSA/PKP did). And we did key formats for 25519 (used to be what, SECG-1 or something)?  Seems appropriate for IETF, esp since NIST sent them here.
[10:53:39] Florence D_web_817 leaves the room
[10:53:43] Florence D_web_819 joins the room
[10:53:58] <Florence D_web_819> I think it would be really useful to hear more about the challenges Michael's been running into.  There seems to be disagreement about if there's a problem here, or if there will be once NIST announce their algorithms.  Perhaps a ten minute presentation in LAMPS isn't the best place to get to the bottom of this.  I'm not sure what is (interim? separate paper?)
[10:54:07] <Sean Turner_web_740> @Rich and this is intended for informational so like sure
[10:54:36] <Alexey Melnikov_web_386> Florence D: or whether the proposed solution is the right one
[10:54:50] <dkg> i agree that stateful signatures are a different scope, but i'm observing that the "doors and elevators" will need to be redesigned for that use case as well
[10:54:58] Wei Pan_web_710 leaves the room
[10:55:02] Wei Pan_web_793 joins the room
[10:55:06] Thomas Werner_web_141 leaves the room
[10:55:14] <Florence D_web_819> Alexey: That too of course, but laying out the problem is the first step and it's hard to do that and propose a solution in so short a time
[10:55:27] <Alexey Melnikov_web_386> Florence D: agreed
[10:56:14] <Yoav Nir_web_542> So this is a draft that says "these here are the OIDs".  Except the OIDs are still TBD. So the draft is essentially empty now.
[10:56:19] <dkg> but the solution might just be "the constraints on your  private key distribution channels should be at least *this* big"
[10:56:40] <kaduk@jabber.org/barnowl> It's more like "the interpretation of OID <TBD> in PKIX"
[10:57:01] <kaduk@jabber.org/barnowl> "interpretation and use", I guess
[10:57:23] Shu-Fang Hsu_web_364 leaves the room
[10:57:24] <Rich Salz_web_918> @dkg: but if you can effectively widen the channels by compression, why wouldn't you want to do that interoperably?
[10:58:14] <dkg> Rich: if everyone implements it, yes.  if it means that some keys are uninterpretable by some systems, then you're actually harming interop
[10:58:31] <kaduk@jabber.org/barnowl> "What do we want?"
"WG adoption!"
"When do we want it?"
"Now!"
[10:58:39] <dkg> +1 to avoiding parameters
[10:58:56] <Yoav Nir_web_542> But how are those octets in the octet string going to be compresssed?
[10:58:58] <Rich Salz_web_918> @dkg: we're not the protocol police, to quote a trope.
[10:58:58] <Mike Ounsworth_web_800> How do I speakL?
[10:59:11] <Yoav Nir_web_542> click the mic icon
[10:59:12] <kaduk@jabber.org/barnowl> local mute
[10:59:19] <kaduk@jabber.org/barnowl> meetecho thinks you are sending
[10:59:23] <Rich Salz_web_918> @yoav: i think that's the point  -- specifying how.
[10:59:27] <Quynh Dang_web_244> looks nice.
[10:59:38] Tero Kivinen_web_261 leaves the room
[10:59:55] <Alexey Melnikov_web_386> Mike: or use chat, we can relay
[11:00:04] <Sean Turner_web_740> to be clear Panos has swayed me to the one alg per I-D.
[11:00:15] <Mike Ounsworth_web_800> I'll type
[11:00:31] Christian Veenman_web_248 leaves the room
[11:00:44] Alan Hayward_web_556 leaves the room
[11:00:45] <John Gray_web_515> I was going to ask about Signatures as well.   Should there be one for that.
[11:00:46] <Mike Ounsworth_web_800> @Sean: note that there are some important security considerations around KEMs: I think you draft needs to limit the shared secret length for each KEM
[11:00:46] <Rich Salz_web_918> bye all
[11:00:48] Alan Hayward_web_144 joins the room
[11:00:54] <Yoav Nir_web_542> Interim should be after the announcement
[11:00:54] Scott Fluhrer_web_539 leaves the room
[11:00:57] <Tim Hollebeek_web_468> thanks everyone for some great discussion!
[11:00:58] <Bas Westerbaan_web_236> thank you all!
[11:01:00] <dkg> thanks all
[11:01:02] <Massimiliano Pala_web_592> bye all! Thank you!
[11:01:03] <Quynh Dang_web_244> Thank you all.
[11:01:03] <Bas Westerbaan_web_236> thank you, Sean
[11:01:04] Meetecho leaves the room
[11:01:07] <Alexey Melnikov_web_386> Thank you
[11:01:07] Ken Takayama_web_183 leaves the room
[11:01:11] Alexey Melnikov_web_386 leaves the room
[11:01:12] Clint McKay_web_421 leaves the room
[11:01:13] Daphanie Nisbeth_web_128 leaves the room
[11:01:15] Andrew S_web_793 leaves the room
[11:01:15] Roman Danyliw_web_916 leaves the room
[11:01:16] David von Oheimb_web_257 leaves the room
[11:01:16] <Jan Klaußner_web_975> Thanks and bye!
[11:01:17] Rebecca Guthrie_web_335 leaves the room
[11:01:17] Jonathan Hammell_web_937 leaves the room
[11:01:18] Florence D_web_819 leaves the room
[11:01:18] Panos Kampanakis_web_528 leaves the room
[11:01:20] Jean-Michel Combes_web_660 leaves the room
[11:01:20] <justus> thanks
[11:01:21] Rebecca Guthrie_web_794 joins the room
[11:01:21] Russ Housley_web_130 leaves the room
[11:01:22] Christine van Vredendaal_web_877 leaves the room
[11:01:22] Yoav Nir_web_542 leaves the room
[11:01:22] justus leaves the room
[11:01:23] <Massimiliano Pala_web_592> Looking forward to the interim :)
[11:01:24] Mike Boyle_web_940 leaves the room
[11:01:25] cw-ietf leaves the room
[11:01:25] Benjamin Kaduk_web_319 leaves the room
[11:01:26] Christine van Vredendaal_web_931 joins the room
[11:01:26] Thom Wiggers_web_455 leaves the room
[11:01:31] <John Gray_web_515> Thanks everyone
[11:01:31] Daniel Huigens_web_462 leaves the room
[11:01:32] <Sean Turner_web_740> @MikeO: noted
[11:01:34] Corey Bonnell_web_898 leaves the room
[11:01:35] Ali Noman_web_948 leaves the room
[11:01:35] Yoshiro Yoneya leaves the room
[11:01:37] Sean Turner_web_740 leaves the room
[11:01:42] Valery Smyslov_web_726 leaves the room
[11:01:47] Tim Hollebeek_web_468 leaves the room
[11:01:47] Rich Salz_web_918 leaves the room
[11:01:48] Aron Wussler_web_598 leaves the room
[11:01:48] Stavros Kousidis_web_653 leaves the room
[11:01:52] Evangelos Karatsiolis_web_252 leaves the room
[11:01:52] Michael B_web_287 leaves the room
[11:01:53] Quynh Dang_web_244 leaves the room
[11:01:54] Wei Pan_web_793 leaves the room
[11:01:56] Bernie Hoeneisen_web_200 leaves the room
[11:01:56] Michael B_web_191 joins the room
[11:01:57] Satoru Kanno_web_498 leaves the room
[11:02:00] Yoshiro Yoneya_web_303 leaves the room
[11:02:02] Christine van Vredendaal_web_931 leaves the room
[11:02:03] Ties de Kock_web_293 leaves the room
[11:02:05] PRAT Julien_web_242 leaves the room
[11:02:07] Ties de Kock_web_192 joins the room
[11:02:10] Alyssa Thompson_web_621 leaves the room
[11:02:10] Justus Winter_web_876 leaves the room
[11:02:14] Tadahiko Ito_web_292 leaves the room
[11:02:14] Alison Becker_web_763 leaves the room
[11:02:15] Johannes Roth_web_971 leaves the room
[11:02:36] Mike Ounsworth_web_800 leaves the room
[11:02:42] Rebecca Guthrie_web_794 leaves the room
[11:02:44] Daniel Gillmor_web_823 leaves the room
[11:02:44] Peter Campbell_web_989 leaves the room
[11:02:44] John Gray_web_515 leaves the room
[11:02:44] Jan Klaußner_web_975 leaves the room
[11:02:44] Leonie Bruckert_web_735 leaves the room
[11:02:44] Steffen Fries_web_628 leaves the room
[11:02:44] Michael Jenkins_web_475 leaves the room
[11:02:44] Deb Cooley_web_655 leaves the room
[11:02:44] Bas Westerbaan_web_236 leaves the room
[11:02:44] Hernâni Marques_web_256 leaves the room
[11:02:44] Guilin WANG_web_502 leaves the room
[11:02:44] Stefan Santesson_web_661 leaves the room
[11:02:44] Armando Faz-Hernández_web_210 leaves the room
[11:02:44] Ludovic Perret_web_749 leaves the room
[11:02:44] Stephan Ehlen_web_513 leaves the room
[11:02:44] Ching-Heng Ku_web_816 leaves the room
[11:02:44] Massimiliano Pala_web_592 leaves the room
[11:02:44] Colin Whorlow_web_539 leaves the room
[11:02:44] Alan Hayward_web_144 leaves the room
[11:02:44] Michael B_web_191 leaves the room
[11:02:44] Ties de Kock_web_192 leaves the room
[11:18:41] MichaelRichardson leaves the room: Disconnected: No route to host
[11:25:55] mcr joins the room
[11:46:56] kaduk@jabber.org/barnowl leaves the room
[12:57:51] mcr leaves the room
[14:53:34] dkg leaves the room: leaving