IETF
LAMPS
lamps@jabber.ietf.org
Monday, November 8, 2021< ^ >
Meetecho-alex has set the subject to: LAMPS at IETF 111
Room Configuration
Room Occupants

GMT+0
[06:21:16] Glen joins the room
[06:21:23] Glen leaves the room
[15:30:23] Yoshiro Yoneya joins the room
[15:45:03] Yoshiro Yoneya_web_848 joins the room
[15:45:03] Russ Housley_web_155 joins the room
[15:45:03] Daphanie Nisbeth_web_335 joins the room
[15:45:03] Steffen Klassert_web_351 joins the room
[15:45:03] Ken Takayama_web_959 joins the room
[15:45:03] Tobia Castaldi_web_214 joins the room
[15:45:03] Yuji Suga_web_226 joins the room
[15:45:03] Michael Jenkins_web_659 joins the room
[15:45:03] Deb Cooley_web_420 joins the room
[15:45:05] dkg joins the room
[15:45:16] Daniel Gillmor_web_841 joins the room
[15:46:31] Alessandro Toppi_web_711 joins the room
[15:46:35] Rebecca Guthrie_web_530 joins the room
[15:47:14] Tadahiko Ito_web_351 joins the room
[15:47:52] Yuji Suga_web_226 leaves the room
[15:47:56] Yuji Suga_web_187 joins the room
[15:48:00] <Russ Housley_web_155> Can I please get a volunteer for notes in CodiMD?
[15:48:34] Carl Mehner_web_972 joins the room
[15:49:09] Yuji Suga_web_187 leaves the room
[15:49:13] Yuji Suga_web_872 joins the room
[15:49:37] Tim Hollebeek_web_732 joins the room
[15:51:07] Hendrik Brockhaus_web_939 joins the room
[15:51:12] Alison Becker_web_256 joins the room
[15:52:43] Jessica Fitzgerald-McKay_web_718 joins the room
[15:54:18] Quynh Dang_web_779 joins the room
[15:55:05] <Russ Housley_web_155> Thank you Deb!
[15:55:34] Sorin Faibish_web_697 joins the room
[15:55:50] Roman Danyliw_web_408 joins the room
[15:56:03] Tero Kivinen_web_992 joins the room
[15:56:20] Meetecho joins the room
[15:56:26] Robert Moskowitz_web_494 joins the room
[15:56:44] Ira McDonald_web_813 joins the room
[15:56:58] Sean Turner_web_276 joins the room
[15:57:02] Florence D_web_165 joins the room
[15:57:02] Bob Moskowitz joins the room
[15:57:03] Yuji Suga_web_872 leaves the room
[15:57:07] Paul Watrobski_web_461 joins the room
[15:57:07] Yuji Suga_web_934 joins the room
[15:57:21] Korry Luke_web_121 joins the room
[15:57:25] Daniel Van Geest_web_673 joins the room
[15:57:50] Michael Rosa_web_290 joins the room
[15:57:51] Alyssa Thompson_web_438 joins the room
[15:57:51] Peter Campbell_web_223 joins the room
[15:57:58] Christopher Inacio_web_399 joins the room
[15:58:05] John Gray_web_282 joins the room
[15:58:10] Leonie Bruckert_web_721 joins the room
[15:58:11] <Deb Cooley_web_420> NP and thanks in advance for taking notes in acme!!
[15:58:27] Jonathan Hammell_web_502 joins the room
[15:58:28] Peter Campbell_web_223 leaves the room
[15:58:32] Peter Campbell_web_903 joins the room
[15:58:46] Jen Hufford_web_528 joins the room
[15:59:03] Meetecho has set the subject to: LAMPS at IETF 112
[15:59:16] Elena Bakos Lang_web_749 joins the room
[15:59:19] Wei Pan_web_819 joins the room
[15:59:22] Nicholas Gajcowski_web_686 joins the room
[15:59:24] Michael Richardson_web_953 joins the room
[15:59:51] Mike Ounsworth_web_290 joins the room
[15:59:53] Dan Harkins_web_909 joins the room
[15:59:57] Yoav Nir_web_504 joins the room
[16:00:00] afregly@verisign.com_web_631 joins the room
[16:00:04] Scott Fluhrer_web_564 joins the room
[16:00:07] Bernie Hoeneisen_web_812 joins the room
[16:00:18] Olle Johansson_web_397 joins the room
[16:00:46] <Yoav Nir_web_504> Ooh. Barter still works
[16:00:51] John Preuß Mattsson_web_121 joins the room
[16:00:56] <Deb Cooley_web_420> IKR????
[16:01:06] mcr joins the room
[16:01:13] Ali Noman_web_830 joins the room
[16:01:40] Steffen Fries_web_732 joins the room
[16:01:40] Corey Bonnell_web_268 joins the room
[16:01:52] Mike Boyle_web_670 joins the room
[16:01:56] <dkg> "we're going to have impersonal attacks" ha ha
[16:02:15] <mcr> . o O ( can my robot attack your robot? )
[16:02:28] Joseph Salowey_web_887 joins the room
[16:02:32] <dkg> let's not debate personhood of robots here today
[16:02:54] Justus Winter_web_995 joins the room
[16:02:56] Chris Inacio joins the room
[16:03:07] PRAT Julien_web_323 joins the room
[16:04:13] Ludovic Perret_web_656 joins the room
[16:05:19] <Bob Moskowitz> Compared to personhood of corporations?  If they have it, why not robots?  Seems the next nature step on the slope.
[16:05:32] Stefan-Lukas Gazdag_web_536 joins the room
[16:05:47] Greg Schumacher_web_191 joins the room
[16:06:03] Benjamin Kaduk_web_431 joins the room
[16:06:30] <Mike Ounsworth_web_290> Microsoft Tay said she was self-aware, but I didn't buy it :/
[16:07:03] Peter Campbell_web_903 leaves the room
[16:07:07] Peter Campbell_web_103 joins the room
[16:07:08] Tomofumi Okubo_web_156 joins the room
[16:07:32] Alexey Melnikov_web_174 joins the room
[16:07:51] <Bob Moskowitz> 3
[16:08:10] cw-ietf joins the room
[16:08:40] <Sean Turner_web_276> yeah knock off those algorithms!
[16:09:16] <Mike Ounsworth_web_290> Note: the authors don't really know much about ANSI X9.9. We assume it's right to strike it off the list?
[16:10:26] kaduk@jabber.org/barnowl joins the room
[16:11:35] <mcr> X9.9 is a challenge/response system, originally based on 1DES, later3DES.
[16:11:41] <Sean Turner_web_276> @MikeO If you've never seen it is probably okay to drop
[16:11:44] Rich Salz joins the room
[16:11:55] <mcr> (not time based)
[16:12:00] <Mike Ounsworth_web_290> lol, awesome
[16:12:36] <mcr> I'm sure that it's still out there, but I doubt it is used for certificate enrolment.  I posit it was never deployed.
[16:12:56] <mcr> I guess that it was used to authorize the enrolment.
[16:13:20] Satoru Kanno_web_258 joins the room
[16:13:24] <Bob Moskowitz> X9.  Check banking.
[16:13:37] <mcr> yeah, but did the banks use it as part of CMP.
[16:14:03] <Tadahiko Ito_web_351> secp2r1 should be secp256r1?
[16:14:15] <Sean Turner_web_276> This seems like an entirely sane approach!
[16:14:45] <Russ Housley_web_155> X9.9 was single DES MAC
[16:15:25] <Roman Danyliw_web_408> We could also chose to do both.
[16:15:33] <Roman Danyliw_web_408> They summarize different things.
[16:15:51] <Sean Turner_web_276> +1 to what Russ said
[16:15:57] <Roman Danyliw_web_408> SVG!
[16:16:16] <mcr> goat is great!!!
[16:16:19] <Roman Danyliw_web_408> After four columns ;-)
[16:16:55] <dkg> please do include a table.  don't care about the txt version, since native HTML produced these days shows a good table.
[16:17:04] <Ira McDonald_web_813> I like adding the table - very helpful
[16:17:15] <Dan Harkins_web_909> Is AES-192 used anywhere?
[16:17:23] <Deb Cooley_web_420> no
[16:17:30] <Dan Harkins_web_909> s/192/256/
[16:17:31] <Yoav Nir_web_504> No. Never
[16:17:34] <Deb Cooley_web_420> but it is matchy matchy
[16:17:41] Alessandro Toppi_web_711 leaves the room
[16:17:45] Alessandro Toppi_web_239 joins the room
[16:18:05] <Yoav Nir_web_504> It has the same performance as AES-256 and a little bit less security
[16:18:54] <Rich Salz> @Sean ping me if you want me to join.  dispatch is going well/quickly.
[16:20:40] bhoeneis joins the room
[16:21:11] <Roman Danyliw_web_408> The format in the LAMPS document was fine.  It was a OpenSSL bug/feature mismatch.  See https://github.com/openssl/openssl/issues/16971.
[16:21:19] <dkg> @Hendrik: i note that the table suggests that SHAKE256 is a hash algorithm, but it's not -- it's an XOF, and is explicitly discouraged as a hash algorithm in the NIST spec
[16:21:24] <Roman Danyliw_web_408> See for https://mailarchive.ietf.org/arch/msg/spasm/pZy4Se2G9XSQUc0uUzckn_SGl1E/ the work-around.
[16:22:08] Yuan Tian_web_160 joins the room
[16:22:59] Alessandro Toppi_web_239 leaves the room
[16:23:03] Alessandro Toppi_web_993 joins the room
[16:23:05] Kohei Isobe_web_551 joins the room
[16:23:19] Valery Smyslov_web_520 joins the room
[16:24:21] <Mike Ounsworth_web_290> @dkg I think SHAKE is in there on the same lines that use Ed225519 / Ed448 cause I think it's needed? In the first one we list "SHA256/SHAKE128", on the second we just have "SHAKE256" ... maybe that should be "SHA256/SHAKE256" ?
[16:24:24] <Bob Moskowitz> And that is so strange when you look at how SHAKE is built from the Keccak function compared parallel with SHA3.
[16:24:31] <Mike Ounsworth_web_290> s/SHA256/SHA512
[16:25:32] <dkg> i understand that ed448 uses shake256 internally -- but it's used as an XOF, not a hash function
[16:25:54] <Mike Ounsworth_web_290> Or maybe it's unceccessary to list SHAKE at all if it's already implicit by listing "Ed25519 / Ed448" ?
[16:26:42] <dkg> i suppose it depends on the purpose of the table -- but it would be unfortunate if the draft results in a reader identifying SHAKE256 as a hash function, in explicit contradiction of how it's publicly specified.
[16:27:16] <dkg> we're discussing that in the OpenPGP WG's design team as well: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/82
[16:27:41] <Mike Ounsworth_web_290> Interesting.
[16:27:57] Jessica Fitzgerald-McKay_web_718 leaves the room
[16:28:01] Jessica Fitzgerald-McKay_web_178 joins the room
[16:28:05] <Mike Ounsworth_web_290> Maybe better to then do EC: Ed448(SHAKE256) | Hash: SHA512 ?
[16:29:25] Daniel Gillmor_web_841 leaves the room
[16:29:58] <Quynh Dang_web_779> @dkg, you were correct. Currently, we plan to allow SHAKEs for being used as hash functions in RSA-PSS and ECDSA.
[16:30:14] <Quynh Dang_web_779> in draft FIPS 186-5.
[16:30:58] dkg leaves the room
[16:31:05] dkg joins the room
[16:31:13] <John Preuß Mattsson_web_121> I think the SHAKE should be refer to as a variable length hash function. The term XOF is just confusing. NIST tries to not call SHAKE a hash function, but then writes "ParallelHash is a variable-length hash function"
[16:31:37] Yuji Suga_web_934 leaves the room
[16:31:41] Yuji Suga_web_926 joins the room
[16:31:59] <Sean Turner_web_276> for the record - no concerns
[16:31:59] <Quynh Dang_web_779> On technical terms, I agree with John.
[16:32:58] <Roman Danyliw_web_408> I can batch all of these for IESG review.
[16:33:12] Yuan Tian_web_160 leaves the room
[16:33:16] Yuan Tian_web_542 joins the room
[16:33:16] <Roman Danyliw_web_408> We can independently perform WGLC/IETF LC.
[16:33:23] Sorin Faibish_web_697 leaves the room
[16:33:27] Sorin Faibish_web_184 joins the room
[16:33:47] Korry Luke_web_121 leaves the room
[16:34:01] Daniel Gillmor_web_483 joins the room
[16:34:08] <Bob Moskowitz> WRT XOF and hashes from FIPS 202: When
an application requires a cryptographic hash function with a non-standard digest length, an XOF
is a natural alternative to constructions that involve multiple invocations of a hash function
and/or truncation of the output bits. However, XOFs are subject to the additional security
consideration that is described in Sec. A.2.
[16:34:32] <Quynh Dang_web_779> When there is a strong demand for SHAKEs being used as hash functions, please send me an email and I would be happy to discuss further with you.
[16:35:02] <Bob Moskowitz> So XOF are hashes, but since the output variable length, you better know the strength risks.
[16:36:58] <Bob Moskowitz> And since there are so many different approaches for truncating hashes or extending them for key generation, having standard approaches are muchly needed.
[16:38:06] Peter Campbell_web_103 leaves the room
[16:38:10] Peter Campbell_web_662 joins the room
[16:38:21] Yoshiro Yoneya_web_848 leaves the room
[16:38:25] Yoshiro Yoneya_web_381 joins the room
[16:39:38] Ira McDonald_web_813 leaves the room
[16:39:42] Ira McDonald_web_309 joins the room
[16:39:48] <Mike Ounsworth_web_290> ... alright. So what does that mean for including / not including SHAKE(128|256) in the CMP alg profile table?
[16:43:58] <Sean Turner_web_276> Because of the reference to 8702, I think that SHAKE is not just included because of Ed*.
[16:44:13] Olle Johansson_web_397 leaves the room
[16:44:17] Olle Johansson_web_453 joins the room
[16:44:25] <Yoav Nir_web_504> ISTM that if we want SHAKE in the documents, NIST is open to approve it for use as a hash
[16:44:33] <Bob Moskowitz> For truncated hash situations it seems to be that SHAKE128 is superior to SHA256 and some advise on trunctating.  Of course for Ed448, SHAKE256 is included.
[16:44:54] <Sean Turner_web_276> see: https://datatracker.ietf.org/doc/html/rfc8702
[16:45:15] Olle Johansson_web_453 leaves the room
[16:45:16] <Quynh Dang_web_779> @Yoav, I am not the decision maker for approving crypto at NIST.
[16:45:19] Olle Johansson_web_993 joins the room
[16:45:46] <Bob Moskowitz> But if CMP does have truncated hashes, no gain there.  Now KMAC is another issue compared to HMAC.  But that is for my CFRG talk thursday.
[16:45:57] Olle Johansson_web_993 leaves the room
[16:46:01] Olle Johansson_web_106 joins the room
[16:46:42] <Sean Turner_web_276> @Bob I do not believe they include truncated hashes
[16:47:17] <Yoav Nir_web_504> @Quynh, oh, I thought you basically ran NIST  :-)
Anyway, you said "you were correct. Currently, we plan to allow SHAKEs for being used as hash functions in RSA-PSS and ECDSA" and I take it to mean that NIST may be open to other uses as hash if there is a demand.
[16:47:30] <Jonathan Hammell_web_502> Was lack of adoption due to the difficulty of separating between other use cases of RFC 822 wrapping (e.g. message digests) and header protection?
[16:47:36] <Quynh Dang_web_779> @yoav, but I can talk to my team about it if the group and the chairs want me to do so.
[16:47:37] <Alexey Melnikov_web_174> I wouldn't rely on anybody from Microsoft fixing anything
[16:48:31] <Alexey Melnikov_web_174> @Jonathan: it was confusing between header protection and forwarded/attached message
[16:48:37] <Bob Moskowitz> We don't have a Tim Polk replacement.  Sadly said.
[16:49:28] <Bob Moskowitz> Not that Tim ran NIST security, but...
[16:49:53] <Quynh Dang_web_779> @Yoav, yes when there is a need for it, I can talk to my team. If the group and the chairs want me to have an answer for that, I'll try.
[16:50:58] <Alexey Melnikov_web_174> DKG: your latest proposal is quite horrible, considering complexities of HTML.
[16:51:09] <Deb Cooley_web_420> @quynh perhaps if you could scrub the tables and comment on whether they need to be modified?
[16:51:13] <dkg> I agree!  HTML is horrible :)
[16:51:18] <Mike Ounsworth_web_290> SHAKE: @Quynh this all started because SHAKE was mentioned in Hendrik's slides (specifically the 2nd version of the alg profiles table). It got in there when I transposed the 1st table's "Ed448 (SHAKE256) and, mistakenly it seems, split that into two columns.
[16:51:29] <Quynh Dang_web_779> Tim was the manager, but I don't think Tim ever made a cryptographic decisions without the group's input even though I had the authority to do so.
[16:51:43] <Mike Ounsworth_web_290> At this point I don't think we're asking NIST to ratify anything. On the contrary, I think we're asking for a second pair of eyes on our table(s)!
[16:51:59] <Sean Turner_web_276> @MikeO - yes ;)
[16:52:40] <Quynh Dang_web_779> I meant "he had" not "I had" :)
[16:54:04] <Mike Ounsworth_web_290> ... and now that I'm looking at it, I have no idea where SHAK-128 came from, since the first table lists "Ed25519 (SHA512)". I think the authors need to take this back to private emails.
[16:54:09] <Bob Moskowitz> No, but Tim managed a lot for us in IETF!
[16:54:52] <Quynh Dang_web_779> :) I know we all like Tim very much. He is a very nice person to work with.
[16:56:13] <mcr> Yes, Bernie understood me.
[16:56:50] <Quynh Dang_web_779> @Deb I will take a look at it when it is added to the draft.
[16:57:08] <Bob Moskowitz> More for NIST to shepherd back in PKIXs days.  Now more guidelines.  And here and do we need shake128, and as MikeO just said that there is no direct need for SHAKE in the table.
[16:57:08] <mcr> maybe objectors could speak up.
[16:57:29] <Hendrik Brockhaus_web_939> Many thanks for the discussion and input.
[16:57:54] <Sean Turner_web_276> @bob correction I think MikeO asked whether is a need to reference it
[16:58:21] Olle Johansson_web_106 leaves the room
[16:58:25] Olle Johansson_web_577 joins the room
[16:58:28] <Alexey Melnikov_web_174> As an implementor I wouldn't want to implement different header protection mechanism for encryption and for signing. This would just be too confusing.
[16:58:42] Alexey Melnikov_web_174 leaves the room
[16:59:15] <Hendrik Brockhaus_web_939> I will discuss with the co-authors and submit a updated draft. Looking forward to careful reviews by the experts. Sorry that I am not that expert here :-)
[16:59:22] <Mike Ounsworth_web_290> (sorry @Hendrik if I made this more complicated. I think your 1st version of the table had it correct)
[17:00:35] <Hendrik Brockhaus_web_939> Still we need to review Section 2.2 of the document and check what hashAlg is to be used for certConf messages with Ed448 signed certificates.
[17:01:54] <mcr> I think that the vocal opponent is in the rough.
[17:02:43] <Sean Turner_web_276> that's a great name!
[17:04:15] <Bob Moskowitz> GenerticName?  Is that correct or a typo?
[17:04:23] <Sean Turner_web_276> @bob yes ;)
[17:04:36] <Sean Turner_web_276> GeneralName ;)
[17:04:38] <Corey Bonnell_web_268> GeneralName?
[17:04:49] <kaduk@jabber.org/barnowl> At least it's not GeneticName!
[17:04:52] <Sean Turner_web_276> I knew what you meant ;)
[17:05:02] <Bob Moskowitz> I was concerned that it was a different ANS.1 object!  Whew!
[17:05:22] <Sean Turner_web_276> It was slipped in v2015 of X.509 ;)
[17:05:35] <Dan Harkins_web_909> specific non-goal: to prevent people from generating a conflicting request (e.g. specific a curve and sign with rsaEncryption).
[17:07:15] <Mike Ounsworth_web_290> Now my mind is racing on what would be in an X.509 GeneticName SAN. ... privacy concern?
[17:07:43] Steffen Klassert_web_351 leaves the room
[17:08:07] Daniel Gillmor_web_483 leaves the room
[17:08:11] Daniel Gillmor_web_463 joins the room
[17:10:10] <Bob Moskowitz> :)
[17:10:40] <mcr> A SEQUENCE of the GeneralName of all of your ancestors.  There would be an anchor for Abrahamic follows to anchor it to Abraham.
[17:10:42] dkg joins the room
[17:10:47] <dkg> yay for no parameters!
[17:10:51] <John Gray_web_282> I agree with GeneralName, its more flexible.    Name ::= CHOICE { -- only one possibility for now --
     rdnSequence  RDNSequence }
   RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
   RelativeDistinguishedName ::=
     SET SIZE (1..MAX) OF AttributeTypeAndValue
   AttributeTypeAndValue ::= SEQUENCE {
     type     AttributeType,
     value    AttributeValue }
[17:11:09] Olle Johansson_web_577 leaves the room
[17:11:37] <John Gray_web_282> Sorry about format....  Name is just Attribute type and value...   General name encapsulates different types....  That is all I meant to say...
[17:11:57] <Mike Ounsworth_web_290> OID Params vs OID Explosion. We're opting for OID Explosion?
[17:12:24] <Michael Jenkins_web_659> no to encipherOnly and decipherOnly. I forget why. Those were stuck in back in the day for somebody's scheme that never happened.
[17:12:25] <John Gray_web_282> Does an EKU of a KEM need to be defined?
[17:12:34] <mcr> Integers are cheap. I'm for assigning soonest.
[17:13:14] <mcr> I'm not for having parameters.
[17:13:22] <Bob Moskowitz> OIDs lengthing is the challenge, not necessarily more OIDs.
[17:14:37] <Bob Moskowitz> Of course with PQ stuff, a few bytes here or there are not noticeable in the total packet(s)!
[17:15:46] <Roman Danyliw_web_408> Please pose these question of timing at the SAAG meeting tomorrow.  Dustin Moody from NIST is going to be talking about the PQC project.
[17:15:53] Yuji Suga_web_926 leaves the room
[17:15:59] <Bob Moskowitz> I should point out that we are STILL waiting on FIPS 185-6 for EdDSA.  Been over long.
[17:15:59] <Sean Turner_web_276> @Roman it works!
[17:16:08] <Sean Turner_web_276> r/it/that ;)
[17:16:26] <Quynh Dang_web_779> @Bob sorry for the FIPS being so long.
[17:17:50] <Bob Moskowitz> Not your problem.  Your boss's boss's boss.  But it impacts what I am doing in Aviation's PKI and reference in ICAO's PKI CP.
[17:18:24] <Bob Moskowitz> I have been saying in presentations since Aug '20 "coming soon".  :(
[17:21:37] dkg leaves the room
[17:24:30] Michael StJohns_web_659 joins the room
[17:25:50] <dkg> this focus on authentication seems problematic -- i don't think these conclusions map to the encryption/key agreement space
[17:26:26] <Dan Harkins_web_909> @dkg, agree. I'm more worried about my keys lasting 20 years than my signature.
[17:26:41] <Dan Harkins_web_909> (keys being encryption keys)
[17:27:05] <Mike Boyle_web_670> i think it's a different discussion for key agreement. this is just an example of the analysis
[17:27:09] <mcr> data in motion vs data at rest discussion?
[17:27:11] <dkg> i guess for IKE and TLS key agreement isn't relevant (since they're all forward-secure authentication-based these days)
[17:27:56] <Bob Moskowitz> But data in motion can be saved and then it is no different than data at rest.
[17:28:08] <mcr> why are the chains unchanged?  Surely the PQ root is a different trust anchor than the non-PQ root?
[17:28:50] <mcr> @Bob, I don't care if you can authenticate (or MITM) my IKE session ten years from now.  As long as you can't derive my session keys.
[17:29:26] <Bob Moskowitz> Kind of my point.  Collect those ESP packets and later break them.
[17:29:34] <mcr> While I do care if you can forge my mortage contract in twenty years.
[17:29:35] <Jonathan Hammell_web_502> @mcr: non-composite doesn't require a new composite public key structure up to the root
[17:29:47] <kaduk@jabber.org/barnowl> There are a lot of drafts in TLS ... hard to keep track of all of them
[17:30:14] <kaduk@jabber.org/barnowl> draft-ietf-tls-hybrid-design is I think the relevant one here
[17:30:19] <Mike Ounsworth_web_290> The reference to hybrid keyex in TLS 1.3 is https://datatracker.ietf.org/doc/draft-stebila-tls-hybrid-design/
[17:30:20] <Dan Harkins_web_909> @bob, PQ doesn't attack symmetric ciphers.
[17:30:31] <mcr> @jonathan, I agree, the lowest CA can sign two EEs. If that's a PQ-resistent CA, great.  But that would mean both ends already support PQ, which means why have the legacy.
[17:31:18] <Bob Moskowitz> @Dan.  Yes.  So this is about signing much more than the actual encrypted data.  Got that.
[17:31:20] <mcr> @Dan, my understanding is that PQ can't attack AES256, but I've been told AES128 is vulnerable.
[17:31:31] <Tadahiko Ito_web_351> you can run PQC key agreement with authentication of  non-composite certs. in that case, you may just need to care authentications.
[17:31:31] <Jonathan Hammell_web_502> In the non-composite case, you would have two certificate chains (one traditional, one PQ).
[17:31:41] <dkg> sorry, i guess i'm thinking about this in the context of certificates and anchoring -- obviously there are (PQ-unsafe) key agreement schemes in use
[17:32:06] <Deb Cooley_web_420> key agreement/key transport is only an issue in the 'not real time
[17:32:09] <Deb Cooley_web_420> case?
[17:32:13] <Deb Cooley_web_420> like S/MIME?
[17:32:27] <Deb Cooley_web_420> anything real time is ephemeral?
[17:32:39] <dkg> deb, i tihnk it's an issue for whatever would replace the ECDH handshake, including "realtime" TLS or IKE
[17:33:22] <Dan Harkins_web_909> @dkg, right. The KE should be PQ. But if that was the case the signature that authenticated the shared secret is less of a concern. RIght?
[17:33:22] <dkg> it's just not attached to the certificate itself, since certificates in TLS are just used for authentication
[17:33:23] <Deb Cooley_web_420> But isn't that 'negotiated'? by the inclusion of key shares?
[17:33:24] <mcr> Is there a draft that goes with this work?
[17:33:52] <Jessica Fitzgerald-McKay_web_178> @mcr, we were looking for wg interest. If you think a draft is valuable, we can submit one
[17:34:22] <mcr> It seems like a draft would be a good thing to walk around to the various WGs.
[17:34:26] <dkg> you could embed a signal in each non-composite signature that states the peers it expects to see
[17:34:38] <dkg> s/peers/peer signatures/
[17:35:14] <John Preuß Mattsson_web_121> @mcr AES-128 is one of the security levels in the NIST PQC standardization. Ask the person telling you that AES-128 is vulnerable to provide a calculation of how long a cluster of CRQC running Grover's algorithms would take in breaking AES-128, it will not be close to any practical times....
That said, the performance of AES-256 is not a problem and makes you compliant with government suites like CNSA....
[17:35:20] <Roman Danyliw_web_408> concur with @mcr.  Having a tangible draft would make it easier to discuss.
[17:35:55] <Jessica Fitzgerald-McKay_web_178> sounds good. Thanks, Roman
[17:36:30] <Russ Housley_web_155> I think adding S/MIME or CMS to the paper would be valuable
[17:36:40] <Ludovic Perret_web_656> Is the slides of Allison available somewhere?
[17:36:50] <Roman Danyliw_web_408> @jess -- easier to share the idea across + allow for extending the concepts
[17:36:52] <Russ Housley_web_155> I posted them yesterday
[17:36:59] <Deb Cooley_web_420> in the meeting materials....
[17:37:03] <Mike Ounsworth_web_290> @Jessica I think an informational draft formalizing the security model would be very helpful in driving composite vs non-composite design choices :)
[17:37:18] <Jessica Fitzgerald-McKay_web_178> thanks, Mike
[17:37:21] <dkg> i think the slides are here: https://datatracker.ietf.org/meeting/112/materials/slides-112-lamps-hybrid-non-composite-multi-certificate/
[17:37:22] <Stefan-Lukas Gazdag_web_536> Mostly authentication-wise there's lots of work going on. I think there's discussions at ETSI as well. There's also a rather large research project in Germany called FLOQI. (I think one of the latest outcomes is this: https://eprint.iacr.org/2021/813) Might be worthwhile to talk to those people.
[17:37:26] <Roman Danyliw_web_408> https://datatracker.ietf.org/meeting/112/materials/slides-112-lamps-hybrid-non-composite-multi-certificate-00
[17:38:52] <Ludovic Perret_web_656> thanks
[17:39:53] <John Gray_web_282> I can see composite and non-composite both being valid.  I think it will depend on the specific use-cases.
[17:42:03] John Preuß Mattsson_web_121 leaves the room
[17:45:16] <mcr> I strongly agree. Specific parameters (unrolled OIDs) are also easier for people putting stuff into hardware/verilog, or even just unrolling software.
[17:46:33] Tomofumi Okubo_web_156 leaves the room
[17:46:33] Wei Pan_web_819 leaves the room
[17:47:10] Benjamin Kaduk_web_431 leaves the room
[17:49:15] <afregly@verisign.com_web_631> Having unrolled OIDs would require clients wanting to filter by algorithm type to have to somehow ask for all OIDs applicable to the algorithm type i.e. I want HSS/LMS with N32 and Height 10 or I want HSS/LMS with N32 and height 20
[17:52:06] Michael Rosa_web_290 leaves the room
[17:52:11] <Russ Housley_web_155> @afregly: Yes, the hash alg is embedded in the public key and the other parameters are too, which is much cleaner than the parameter structure we are talking about
[17:52:23] <dkg> please don't specify PKAnyWithAny
[17:52:50] <Sean Turner_web_276> ONly if we rename it PKWithFootgun
[17:53:03] <dkg> if someone needs their own pairing, it's not hard to carve out their own OID
[17:53:24] <dkg> then we can critique that pairing specifically.
[17:54:48] <dkg> russ, can you point to that document?
[17:54:55] <dkg> is the attribute found in the cert or the sig?
[17:55:08] <Russ Housley_web_155> in the sig
[17:55:24] <dkg> thx
[17:55:25] <Russ Housley_web_155> Actially and attribute covered by teh sig
[17:57:00] Yoshiro Yoneya_web_381 leaves the room
[17:57:04] Yoshiro Yoneya_web_636 joins the room
[17:59:03] Mike Boyle_web_670 leaves the room
[17:59:28] <John Gray_web_282> I am more biased towards composite as having to re-write all the protocols to support multi certs seems daunting and then the question of how the security of the multiple certs is bound together.
[17:59:35] Alison Becker_web_256 leaves the room
[17:59:41] <Deb Cooley_web_420> NP
[17:59:49] Yuan Tian_web_542 leaves the room
[17:59:53] <dkg> see y'all on the list
[17:59:58] Roman Danyliw_web_408 leaves the room
[17:59:58] Jessica Fitzgerald-McKay_web_178 leaves the room
[17:59:59] Jonathan Hammell_web_502 leaves the room
[18:00:01] Daniel Van Geest_web_673 leaves the room
[18:00:02] Corey Bonnell_web_268 leaves the room
[18:00:03] Dan Harkins_web_909 leaves the room
[18:00:05] Florence D_web_165 leaves the room
[18:00:05] Joseph Salowey_web_887 leaves the room
[18:00:06] Scott Fluhrer_web_564 leaves the room
[18:00:06] <Quynh Dang_web_779> see you all later.
[18:00:08] Christopher Inacio_web_399 leaves the room
[18:00:09] Valery Smyslov_web_520 leaves the room
[18:00:11] <Bob Moskowitz> bye
[18:00:12] Deb Cooley_web_420 leaves the room
[18:00:13] Yoav Nir_web_504 leaves the room
[18:00:13] Hendrik Brockhaus_web_939 leaves the room
[18:00:13] Bob Moskowitz leaves the room
[18:00:13] <John Gray_web_282> Thanks everyone!   See you on mailing list.
[18:00:14] Ira McDonald_web_309 leaves the room
[18:00:18] Nicholas Gajcowski_web_686 leaves the room
[18:00:19] Peter Campbell_web_662 leaves the room
[18:00:20] Ken Takayama_web_959 leaves the room
[18:00:21] Michael Jenkins_web_659 leaves the room
[18:00:28] Tim Hollebeek_web_732 leaves the room
[18:00:29] Daphanie Nisbeth_web_335 leaves the room
[18:00:39] Michael StJohns_web_659 leaves the room
[18:00:41] Sean Turner_web_276 leaves the room
[18:00:46] Elena Bakos Lang_web_749 leaves the room
[18:00:48] Yoshiro Yoneya_web_636 leaves the room
[18:00:49] Sorin Faibish_web_184 leaves the room
[18:00:49] Justus Winter_web_995 leaves the room
[18:00:50] Quynh Dang_web_779 leaves the room
[18:00:54] Mike Ounsworth_web_290 leaves the room
[18:00:54] Greg Schumacher_web_191 leaves the room
[18:00:55] Ludovic Perret_web_656 leaves the room
[18:00:58] Steffen Fries_web_732 leaves the room
[18:00:58] afregly@verisign.com_web_631 leaves the room
[18:00:59] Jen Hufford_web_528 leaves the room
[18:01:00] Robert Moskowitz_web_494 leaves the room
[18:01:01] Alyssa Thompson_web_438 leaves the room
[18:01:02] dkg leaves the room: leaving
[18:01:02] Ali Noman_web_830 leaves the room
[18:01:04] John Gray_web_282 leaves the room
[18:01:04] Leonie Bruckert_web_721 leaves the room
[18:01:06] Tero Kivinen_web_992 leaves the room
[18:01:08] Russ Housley_web_155 leaves the room
[18:01:13] Tadahiko Ito_web_351 leaves the room
[18:01:19] Rebecca Guthrie_web_530 leaves the room
[18:01:19] Carl Mehner_web_972 leaves the room
[18:01:40] Yoshiro Yoneya leaves the room
[18:01:43] Daniel Gillmor_web_463 leaves the room
[18:01:44] PRAT Julien_web_323 leaves the room
[18:03:13] Meetecho leaves the room
[18:03:15] Jessica Fitzgerald-McKay_web_237 joins the room
[18:03:53] Stefan-Lukas Gazdag_web_536 leaves the room
[18:06:36] Alessandro Toppi_web_993 leaves the room
[18:07:27] cw-ietf leaves the room
[18:07:36] Michael Richardson_web_953 leaves the room
[18:08:36] Tobia Castaldi_web_214 leaves the room
[18:08:36] Paul Watrobski_web_461 leaves the room
[18:08:36] Satoru Kanno_web_258 leaves the room
[18:08:36] Bernie Hoeneisen_web_812 leaves the room
[18:08:36] Kohei Isobe_web_551 leaves the room
[18:08:36] Jessica Fitzgerald-McKay_web_237 leaves the room
[18:13:42] kaduk@jabber.org/barnowl leaves the room
[18:15:56] Chris Inacio leaves the room
[18:26:13] Rich Salz leaves the room
[18:39:41] Rich Salz joins the room
[18:40:23] Rich Salz leaves the room
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!