Session Date/Time: 07 Oct 2026 08:00
[00:00:04] Stephen Farrell: Job, between you and I, we can probably also take notes. Yeah.
[00:00:09] Damien Miller: Should be over... Is there anyone is there anyone who's in a... Other than perhaps myself who's in, like, a a reasonable time zone?
[00:00:18] Stephen Farrell: Depends what you call reasonable. I think it's reasonable for Job. For me, this is really early in the morning, but it's 9AM, so I can't complain.
[00:00:28] Damien Miller: Well, that's my own heart.
[00:00:31] Job Snijders: Okay. I have the notes that's open.
[00:00:34] Deb Cooley: Stephen's idea of early is different than mine.
[00:00:39] Stephen Farrell: Yes. It's it's incredibly early for Deb. We appreciate you you waking up to come on.
[00:00:45] Deb Cooley: This used to be the time that I woke up to go to work. So Oh. Before I was a lady of leisure and retired.
[00:00:52] Stephen Farrell: Right. I I won't comment.
[00:00:58] Job Snijders: So for some reason, it doesn't seem editable,
[00:01:01] Stephen Farrell: the notes. Kinda have to... You kinda have to do a second login thing. If you see there's a sign in button on the hedge-doc url. So I'm just kinda doing a little minor updating of the notes. Bear with me for one second.
[00:01:41] Job Snijders: You gotta start editing, and then it prompts you to
[00:01:44] Damien Miller: do a login.
[00:01:46] Stephen Farrell: Yeah. But there's a kind of... There's a slight weirdness with the login process for the note taking thing.
[00:01:52] Job Snijders: And then it jumps to some random.
[00:01:55] Stephen Farrell: It's a markdown editing. It's gonna split screen. Okay. I'll I'll I'll do the Note Well, Job, whilst you're playing with us. I'm in there I'm in there anyway, so we can take notes. Good morning, everybody, from this time zone. Good evening, good afternoon, whatever. Welcome to the secure shell maintenance interim meeting. I'm one of your chairs, Stephen. Job is another one who's on screen there at the moment. And we have, like, a one hour slot, so it's fairly brief. The... This is the note well. So because this is an IETF interim meeting, the note well applies. That means you should be familiar with all the various issues about behavior, IPR, other various PCPs that are mentioned on this slide. We will... This is being recorded, and we will be taking notes. Again, if anybody wants to volunteer to be a notetaker in the note taking tool, please let us know in the chat or by popping up a video to volunteer. That'll be handy to to have some help there. For everybody taking notes, all we need is the, you know, actions resulting not... We don't need blow by blow because we have the recording. Again, this is an interim meeting. So if you're not presenting or... Well, we don't have any presentations. But if you're not kind of the editor answering questions or the chair, then please do keep your audio and video turned off unless you're you're in the queue. To join the queue, there's a little button with a hand at the bottom center of the screen. Anybody can do that as you wish. We'll process that. Thank you, Lucas. It's great to have helpful notes. Lucas has volunteered in the chat. So I... I've... In the intro and the hedge talk, I've put in the template. And that's the... Also, obviously, the... Let's all be kinda happy and polite as we always are. Our agenda for today is very short. It's basically to process issues to do with the composites draft. Job has joined the queue just to test this. Or
[00:04:14] Job Snijders: No. The blue sheets, we need to upload them, but I They're automatically generated. Really?
[00:04:22] Stephen Farrell: Yes. And, yes, so so, yeah, perhaps I... It's worth saying that this this working group hasn't been an interim interim practicer previously. This is, I think, the first interim meeting for SSH. So, again, if if people need to get used to the tools and play with it, that's just fine. We can deal with that. And, okay, our agenda is to discuss issues. There's a bunch of them that I posted to list. Some are already resolved, actually, which is nice. And then the second agenda item was something we essentially postponed since the last IETF meeting was what to do with SLHDSA and then any other business that we happen to have, which will include confirming whether to to to keep or cancel the... As requested slot for the next IETf meeting. So do we have any agenda bashing before we go on to the first agenda item? It seems we do not have any agenda bashing. I guess I should also specifically thank people who are joining from a... In in a difficult for them time zone. And we did it for a reason because, you know, time zones have been very difficult for for one of our important editors, and so we thought we're trying to be relatively nice to to them. Okay. So issues. There's two slides here. Just give you a preview. I think we go... You know, unless somebody has a better plan, I think we go through them. Like I said, a couple of them, I think, are already resolved on the list, which is good. Some of them might need very little discussions. Some of them might need something... Some longer discussion. But they're in the order with the numbers that I post to the list in the mail in... At the end of August. Yeah. So just to just to keep some kind of track versus the mailing list. So with that, Damien, do you wanna kinda go through these? Do want me to kinda prompt... To go through them? Any way you prefer to do it?
[00:06:33] Damien Miller: I guess, if this is the ones that I... This looks like the ones I sent a while ago of the open questions. I... And I've got one to add, actually.
[00:06:43] Stephen Farrell: Great. I I added a couple as well in in the mail, so so I booked. Yeah.
[00:06:48] Damien Miller: Alright. I missed I missed the mail. So
[00:06:50] Stephen Farrell: Okay. So let me let me let me just give you a Yeah. You got it. Let me just give you a second. You can you can download the slide yourself, but I'll give you a second to look at the second one, which I think there was a couple of them I had at the end there. And
[00:07:06] Damien Miller: Yeah. I mean, I guess I guess it just... If you back up one. Yeah. I think I guess, the the... Is this is this the right composite algorithms? I think the minimum viable the minimum viable algorithm is the MLDSA44 ED25519. I added... When I wrote the... When I revised the draft, I think, for the third time and changed its name for the third time, I added on request from a few people, MLDSA87-P384, ECDSA-p384 as... At at the request of a few people. I think that... I I strongly feel that we should not embrace the the combinatorial explosion of of hybrid possibilities and should just pick one or two. I'm not aware of any objections to the the the MLDSA87-P384 variant, but I haven't heard a lot of support for it either. It does have it does have one one issue that needs to be addressed, which is that the... There's there's... With regards to the next question, the sundraft, the... I used a different encoding to the sundraft. The sundraft uses the same encoding as the the lamps composite six draft, which is arguably arguably has some advantages just in terms of consistency. I I don't have a strong opinion. I'm happy to replace that. I think that's probably one of the bits that might be better off merge from the sundraft than than overriding bits of mine. But I guess, you know, I'd I'd I'd I'd wanna hear if people actually want MLDSA87-P384 as a... As an option alongside the MLDSA44-ED25519.
[00:09:16] Stephen Farrell: Yeah. Okay. I I think that that's that's a good thing. Again, everything will need to be confirmed on the list, of course. But on the top... On this topic then, we have two composite signature f's, 44 with ED25509 and 87 with P384. So, yeah, if people could join the queue, if they have opinions, should we keep doing these, add 17 more, remove one of them? Those seem to be the options. Lucas?
[00:09:45] Lucas Prabel: Yes. I think we all agree that it's better to avoid an explosion of combinations, but maybe I would just like us to consider adding MLDSA... MLDSA65, for example, with ED25519, because it would be consistent with what we already have for hybrid key exchange where we have a combination of ML-KEM-768 with X25519. So people who deploy that will maybe naturally expect the same middle level on the signature side. So maybe it would be something to consider.
[00:10:24] Stephen Farrell: So... Okay. Sorry, Lucas. Can you just say... I didn't quite catch that. Can you just say the exact one you you wanna consider including is M 87 plus ED25509. Is that it?
[00:10:35] Lucas Prabel: I wanted the middle level, so MLDSA65.
[00:10:38] Stephen Farrell: Oh, sorry. 65.
[00:10:40] Lucas Prabel: Yes. Because we have the same middle level for hybrid kitchen, so I think it would make sense.
[00:10:47] Stephen Farrell: Okay.
[00:10:51] Job Snijders: Scott? So it sounds like multiple people... Oh, sorry. I'm jumping the queue.
[00:10:58] Stephen Farrell: Yeah. Scott, go ahead.
[00:11:00] Scott Fluhrer: Yes. I would actually... Would tend to dis... I would like to push back against the idea of we want to do MLDSA65 just because. Is there a real use case which says MLDSA87 is too expensive, but MLDSA65 is good enough? If we can't identify such a use case, I would say, let's pass on it because all MLDSA87 is is... It's a bit bigger, and size, as far as I understand it, is not that important to to
[00:11:44] Stephen Farrell: Damien, as editor, if you... I think you should feel free to jump in and respond if you have responses.
[00:11:49] Damien Miller: Oh, okay. Yeah. Look, I guess, I... The advice I have is that the security margin for an MLDSA is... The the cryptographers who are still speaking to me seem to indicate that the the security margin for an MLDSA 44 is is better than the the ML-KEM-512 security margin. I think it's also a little bit comparing apples and oranges because if your chem is broken, then all of your traffic retrospectively and prospectively is broken. If your signature key is broken, then you rotate your signature key. I think they... I I would not not... I don't I don't feel a strong urge to align on the two.
[00:12:39] Job Snijders: Okay. And
[00:12:45] Damien Miller: and and and... Sorry. And and one more thing is is my understanding is that the browser folk are aligning a lot more on MLDSA44, and I think, you know, any... Anything we... Any... Anything that they land on is likely to, you know, enjoy wide hardware and software support in the ecosystem and probably more optimization attention than things that they are gonna be a little bit further out of their their kind of field.
[00:13:15] Stephen Farrell: Okay. And, you you you don't need to keep sharing your audio if you are... Unless you wanna get back in the queue. Thanks. Job?
[00:13:28] Job Snijders: I note something interesting in that multiple people express, like, a near unanimous consensus. We would not like too many choices. And five seconds later, multiple people start proposing additional choices. And so I I think this needs to be resolved because in my mind, supporting 44, 56, and 87 is multiple choices and is is exactly what it seems part of the crowd wants to, does not want to happen. So it would be good if if if we can continue a conversation so that the set of choices, at least then maybe the initial documents is reduced... Is actually reduced and not just, in spirit.
[00:14:20] Stephen Farrell: Okay. Guilin? Gurin, yeah, you're you're in the queue. You can send audio and video if you... As you choose.
[00:14:46] Guilin WANG: Can you hear me now?
[00:14:47] Stephen Farrell: Yes. That's great. Thanks.
[00:14:49] Guilin WANG: Oh, sorry for that. Okay. Okay. So here's Guilin. Yeah. So I would like to say the same idea to echo... Add the algorithm m l 65... M l d s a 65. Yeah. Quite a number of reasons. Actually, I have some messaging in mailing list already. So, basically, I think it's a middle security level. It is gonna be couple of most of the popular one. Yeah. This is the first reason. Second one is I think standardization should not be that short of sighting. Yeah. We gave a complete list. Yeah. But but, of course, maybe just the one compensation, yeah, for the MLDSA65. So I think it is better. Yeah. Actually, even our... Some of our customer already consult consult us. Yeah. Which one we recommended there to use? Because actually for composite one, we recommended to use MLDSA 65 as the first choice because it is a good balance for security and the performance. Yeah. Due to the a a... AI security analysis, yeah, the the capability is becoming power power... More and more power. So in that case, MLDSA44. Not sure where's the deal very safe, yeah, for a few years later. Yeah. So in that case, I think, yeah, MLDSA65 is definitely necessary. Yeah. But of our cost for which you can't put the combination combination, yeah, we can select it later. Yeah. That's my point.
[00:16:26] Stephen Farrell: So so just to... Can I ask a clarifying question again?
[00:16:28] Scott Fluhrer: Yes. Is
[00:16:30] Stephen Farrell: this point specific to SSH? And with what classic signature scheme would you like... Are you arguing for 65 to be combined with?
[00:16:44] Guilin WANG: Classic one can be either. Yeah. Either... Yeah. So either the ECDSA_P256 or maybe Ed25519. I don't mind. Yeah. Maybe select the one later. Yeah. But I do believe MLDSA65 companies is necessary. That's my point. Yeah.
[00:17:02] Stephen Farrell: Okay. And and and, again, just to clarify, is that argument about 65 a generic one or specific to SSH?
[00:17:12] Guilin WANG: Generical one, also for SSH. Yes.
[00:17:15] Stephen Farrell: Okay. Good. Thanks. I I got it now. Thanks.
[00:17:17] Guilin WANG: Thank you. Yeah, Steve.
[00:17:22] Stephen Farrell: Okay. And and I think Damien also was looking for input on whether to even keep the MLDSA87 plus P-384. Alicja in the chat is positive for that. And if anybody has opinions on keeping drop... Or dropping the MLDSA87 with P-384, Then, you know, if you have an if you have an opinion on on keeping it or dropping that, then joining the queue now would be good. Okay. Dmitry? I
[00:18:08] Dmitry Belyavskiy: I am in favor of adding MLDSA87 option with combined with three, four, five. I'm not sure about MLDSA65 option.
[00:18:24] Deb Cooley: Okay.
[00:18:25] Dmitry Belyavskiy: But MLDSA87 is definitely what we will need.
[00:18:28] Stephen Farrell: Okay. So so that's another positive for MLDSA87 plus P-384. How many people? We we... John, go ahead.
[00:18:45] John Preuß Mattsson: Yeah. Yeah. As you started asking about, like, general, if WebPKI seems to use MLDSA44, that seems to be be the future default there. For us in in telecom, I I would say we will probably use a lot of MLDSA87 just because we can. It gives a good security margin. That said, I... I'm not really interested in these composites for security and compliance reasons. But if we if we talk in general, this would be my points.
[00:19:20] Guilin WANG: Okay.
[00:19:26] Stephen Farrell: So would it be correct to summarize then that we... That that the situation seems to be everybody is fine with MLDSA44 plus Ed25519? A bunch of people also want MLDSA87 plus P-384, and there is some some interest to be figured out on MLDSA65 plus Ed25519. Is that... That's where we are so far. Is that about right? I'm not sure it's worth using the... There there is a polling tool. We could poll the people who are present in this meeting and then ask them about the 65 question. Do people think that's worthwhile? There's only... There's, like, 11 people in the meeting.
[00:20:12] Damien Miller: Wouldn't wouldn't we have to do it again on the list anyway?
[00:20:15] Stephen Farrell: Exactly. Yeah. Yeah. Yeah. And if if we had more people in the meeting, it might... The poll might be worthwhile, but I think we can do that on the list. So so I think the action on this one is we seem to be okay with keeping the two that are in the draft as is. And the question then is to ask, do do people really want MLDSA65 plus Ed25519? And then the the... We'll we'll we'll send a mail to the list and ask that question, see what happens. And and I think we'll also kind of say that the the... At least in this meeting and probably in general, we don't want more in this draft. Right? Okay. Great. So I think that gets us point one as resolved as we can do right now. So point two. Damien, do you wanna talk to this?
[00:21:10] Damien Miller: Yeah. I guess... I mean, there's... I guess, point two is related to point three. So perhaps perhaps we deal with them together. There's there's kind of a technical there's a technical... Like, there's technical quality and aesthetic issues kind of all joined up here. The technical issue is for the ECDSA values in the P-384 version. The sundraft made a different encoding choice to what I did. I I... The sundraft leans more towards how the lamps drafted it, and there's there's definitely advantages to that, certainly consistency. For the the way I did it, I did a more kind of SSH style wiring coding, which makes it less compatible with the lamp draft, but perhaps a little bit easier for implementers to do. There's no right answer here. So that's the that's the sort of technical part where, you know, potentially, we might wanna import words from this... The the Sundraft. I guess, quality and aesthetic quality and aesthetics are the other two reasons we might wanna bring in text from the sundraft. You know, they they they they probably will be sections that are better worded than than what I've written. And I guess, you know, I we'll accept accept the the working group's judgment on those. You know? But I I I think I think this is probably something that kinda needs to be done on a a section by section or paragraph by paragraph basis. Okay. So I I guess there's a couple of things.
[00:22:51] Stephen Farrell: There's there's editorial things where we can trust you to kind of take a good stab, and and people will scream at you if if you get that wrong. And then there's a prob... Are there any kind of library issues here with... To do with the encoding that that is... The question arises as to whether, like, a LAMP's library might be reusable in an SSH implementation?
[00:23:10] Damien Miller: Yeah. And that... That's what I... I guess that's that's that's that's where the other, you know, what, you know, on one hand, slightly easier for SSH implementations. On the other, slightly easier to interrupt with with other lamp... With, you know, with lamp... Like, there there would be an encoding step if you wanted to code to directly serialize, you know, the... Turn the SSH wiring encoding into the lamps encoding. Right. It's not it's not incompatible, but it is... It would be extra work. So, you know, less less effort here, more over here sort of arrangement.
[00:23:39] Stephen Farrell: Right. So I I think on the editorial one, I I I would propose that we all decide that you're the editor, so we... We're happy for you to kinda make... Take the first stab at any of these things and do the editorial changes as you see fit, and people will feedback. So I think we could... Probably all we need to discuss then is the encoding issue. Lucas, you're in the queue.
[00:23:59] Lucas Prabel: Yes. We had the same kind of issue with the Jose composite signature draft, and we had some people on the mailing list, some researchers saying that they already shipped some library, OS level cryptographic library, implementing the LEMS composite encoding, and that for them, it would be immediately incompatible with existing implementation if there were different encodings between the and the and the. So, yes, I think it can be a real issue right now, and I would prefer avoiding having two different incompatible encoding for the same composite algorithm. So, yes, that would be my my choice.
[00:24:45] Damien Miller: Okay. I I I think... I I I don't wanna... I I think that's a consideration. I don't think it's I don't think it's an insurmountable one. Right? I think we will specify through the draft that's eventually, you know, hopefully hopefully becomes an RFC, a set of wiring coatings for keys, and they do not have to be the same wiring coding for... That that labs chooses because the the conversion between the two is is relatively trivial. I I don't think there's any hard interrupt blockers here, like such as signature formats. Just just kind of more work in one place versus more work in another place.
[00:25:37] Stephen Farrell: Alicia? Yes.
[00:25:41] Alicja Kario: So I think, like, the envelope in which the values are stored are... Is very much secondary. So I don't think we need to have byte for byte compatibility with lamps or any other encodings. I think, keeping... Like, having having something that is more natural for the SSH ecosystem will be more beneficial in general for the adoption of the draft of the of the standard. It's more important, I would say, to make sure that, like, we do use, like, seeds for the MLDSA part because that seems to be the... What what most people are, like, focusing on and, like... Yeah. So, yeah, I I don't think it's it's necessary to to have the same same kind of encodings as any other draft as long as the as the actual values that are stored are compatible.
[00:26:48] Stephen Farrell: Thanks. Okay. Are there any other inputs, comments?
[00:26:52] Damien Miller: I guess I'd just just say to Alicja, I think that's potentially one area where there's a substantive difference is I'm... And I I could be misremembering, but the the sundraft may may store the the the ACDS a p three eight four key as a seed, and I I don't think I do that in my draft. I think that's worth... That's absolutely something we should we should go back and look at because that could be a... That could actually be a hard that could be actually be a hard one to look at.
[00:27:26] Alicja Kario: Yeah. It would be. Because, like, we don't have widely deployed seed for... Or seed seeds for ECDSA.
[00:27:45] Stephen Farrell: Okay. So I think the... I think... Scott, go ahead.
[00:27:49] Scott Fluhrer: Question about what does... Sorry. What does seed format for ECDSA? The private key for ECDSA is the multiplier for the for the point, and that is essentially a seed format. So I don't quite understand what's the distinction there.
[00:28:21] Damien Miller: I I think... I I... My understanding is that the libraries don't accept that as a raw seed typically.
[00:28:31] Scott Fluhrer: So they want something... They expect something that was compared with the precomputed public key or something like that?
[00:28:38] Damien Miller: I've I've... It's been it's been it's been some years since I've written the ECDSA code. I I I think they expect, like, an arbitrary precision integer, which may be may be roughly equivalent to a c, but I I I... Yeah. My memory is fallible.
[00:28:56] Scott Fluhrer: Yeah. Yeah. To me, I I... Well, to be honest, I have not worked with a... Also, I haven't worked for the ECDSA implementation for a long time. But from a grip to capital standpoint, it sounds like it's just an integer. Okay. Well well, yeah, we can talk about this later.
[00:29:13] Stephen Farrell: Okay. So I... So what I think I heard was that Damien, as editor, got the input saying there's two choices, and one input was was towards choice one, and the other was towards choice two. So he's... As editor, he's probably left where he started. Do we have other thoughts on this? I mean, I guess if there's any hard interrupt issues, those will fall out in the process of finishing things anyway. Right? So if it... If if... It's really matters of kind of direction style. So I'm gonna propose that we we leave it to the editor for now to make this choice, these choices around points two and three, and then people can come back when when when the next wave of the draft draft has those choices and and provide feedback if there's... You know, if those choices seem wrong.
[00:30:09] Damien Miller: And I I I think
[00:30:10] Stephen Farrell: seeds comes up when we talk about private key formats as well. Right? So so so, yeah, so my proposal is that we leave points two and three to the editor to handle in the knowledge that if if a if a choice is made that really conflicts with some library that's deployed, that will turn up in in in the process of finishing things off. And we'll inevitably come back and fix it. If if that's okay with people, we'll move on. If that's okay, give a second. Okay. So the point two and three, the the the summary for now is leave the editor, and we'll inevitably trip over any any landmines if they're there. Relation with the certificates draft, I... Again, this is a point that you
[00:31:04] Damien Miller: raised. Yeah. I guess this is this this... There's a there's a chicken and egg problem here. Guess we have we have a certificate certificates draft, which is, I think, as I read it, a fair way further through the process than than this draft. And I I I... And presumably other people would like to have a certificate format for post quantum hybrid keys. So the question is, do we do we add this to the certificates draft and and wait for this draft to advance enough to to be published together with the certificates draft? Or do we add certificates to this draft and and leave leave the certificate... Existing certificates draft as classical only and unblocked and unblock its path, you know, further through the process? My preference is to leave the certificates draft as it is. In in my... I I don't know if everyone saw the the message I posted the other day to the the list, but I added some text to my GitHub version of this draft to add a a section on certificates. Also, as a section on SSHFP DNS resource records, which I've... Is another thing which I've forgotten. That... That's not published yet, but if... I I I think that would be... I think that would give both drafts the easiest... We'd decouple them to the the the greatest extent and give both of them the easy... Easiest path path ahead.
[00:32:38] Stephen Farrell: Okay. So so I think the proposal then is to to basically make the composites draft kind of contain everything needed and not spread composite information onto other things. Any feedback on that or comments? Or if everybody's okay, we can we can just say that that's a good plan, and we will. So we can... Let's give it a second, see if we can have comments on that. Not seeing anything. So let's say that's a good... Let's say that Damien's plan is good for that one, and we progress a slide. Great. Okay. So we we we touched on this a bit earlier, but private key formats... It would help me, Damien, if you could summarize where we are at right now. I forget.
[00:33:26] Damien Miller: I don't know if I don't know if any of the SSH RFCs define a private key format. I I... If if if if they do, it's not one that... I I think there there may be one. There was a a nssh.com private key format. But for for open SSH, the basis of the private key format is a is a... Like a a a KDF, an encryption wrapping of the of the the same serialization format that we use to send keys to SSH agent. The draft does define that that SSH agent encoding, but there's no there's no actual there's no actual wrapping private key format. If if... And this is probably another this is problem... This is potentially another another reason to kinda hew more closely to the LAMP's draft. The LAMP's draft does define kind of a private key format because it defines an x five zero nine format. So we we kinda get... If we if we stick to the LAMP's draft, at least for private key encoding, we get that for free. Otherwise, it's it's kind of left, I think, in the sort of same limbo that that most other SSH things are related... That relate to private keys as implemented defined.
[00:35:11] Stephen Farrell: Okay. So I'm just looking at... Just... If people have feedback, just jump in the queue then, please. So I'm just looking at the the draft itself. So to find... So you... So the the the the private key format text in the draft is then referring to referring to what you do when you're sending to an agent. I think I think it's what you said. And it has it has MLDSA seed and Ed25519 seed, and it is slightly different in the case of the ECDSA one. Right?
[00:35:52] Damien Miller: Yeah. Yeah. So I'm actually getting it up. I should... Which I should have done beforehand. So this is yeah. So there's the there's the SSH private key format, which is just a kind of wrapping of the composite private key format. I think if if there's an area of incompatibility here, it would be the the need to double check section four point one point two point two, the composite raw private key for the MLDSA87-P384 variant. Because I I I don't I don't recall the... I I I think any... Anything... I... Again, anything anything... This isn't this isn't bound to a signature or anything like that. So any any format that... I think the problem would be if we... The the ability for us to go back and forth between a seed and expanded ECDSA key if we needed to. I think Scott suggested that might be a identity. I I don't remember, and I I think it's worth verifying, and I can I can take that offline?
[00:37:18] Stephen Farrell: Okay. So I don't see people joining the queue, which I I assume indicates they're relatively happy with the draft text and our discussion. And if the action then is for Damien to go and check offline, if the section four one two two is... Has any issues, then that's the action. Okay. Nobody joining the queue. Again, if you... If if if you... If it occurs to you in a minute or something you wanted to say, then just join the queue in a minute. Because I think our next point is kind of easy because I guess it's done. Right?
[00:37:57] Damien Miller: It... It's done for the ones what we've agreed. It's done
[00:38:00] Stephen Farrell: for the done for the ones
[00:38:01] Damien Miller: in the draft. If it were to adopt an MLDSA65 as a result of what conversations on the list, then we'd need to request that as well.
[00:38:12] Stephen Farrell: Okay. So the... Yeah. So the IANA algorithm registration, there was some mailing list traffic, and they're they're done for the two in the draft. And if we add a MLDSA65 one, that'll have to be done then. So no. Nothing to talk about there. Point seven. Is John still with us? So I think point seven essentially was John was in... At the IETF meeting was expressing some distaste for current proposals and desire for soft CMA. So, John, do you wanna talk to that for a second?
[00:38:51] John Preuß Mattsson: Yeah. But I guess that is that would be another draft than this. I I I would say I have a distaste for all composites that degrade the security of MLDSA, both for security reasons and for compliance reasons. These are not hybrids according to several government definitions. So Ericsson has forbid... Current Ericsson guidelines is to forbid all support and use of these types of comp... Such composites. So... But I don't know. That's a different draft and would probably take a lot longer time. I hope CFRG will will work on, like, composites with acceptable security properties.
[00:39:42] Stephen Farrell: Sure. But but, I mean, I think it's worth, you know, it's worth airing the discussion here anyway, I think, because it's Yeah.
[00:39:47] John Preuß Mattsson: Yeah. Sure.
[00:39:48] Stephen Farrell: Yeah. Something that comes up. So I think we should have discussed it and figured, you know, is there... Is it something that lots of people feel strongly about and want to wait for or not? And, yeah, I'm guessing... Think I know the answer. So so any other comments on that, Damien? Yeah.
[00:40:05] Damien Miller: Yeah. Look, I I I think there is is nothing in the SSH protocol per se that depends on the the the the buff properties or soft CMA. The SSH signatures draft, which has not been adopted by the working group yet, as I as I recall, could potentially benefit from some of these properties, but most of the algorithms that it defines for signatures as they stand do not have these properties, so it's a more kind of pervasive problem than just this composite. But as as far as the SSH protocol, nothing depends on on strong unforgeability. Nothing benefits from strong unforgeability, and I don't I don't feel we should block on it.
[00:41:04] Stephen Farrell: John?
[00:41:06] John Preuß Mattsson: Yeah. Yeah. Yes. Go ahead. I I I agree with that this SSH protocol does not need this protocol. But as we have seen, signatures in SSH libraries are used for a lot of other stuff. If that is allowed, there should be general purpose. And, yeah, and also the the... Any security arguments for the SSH protocol doesn't... Does not apply to compliance with government require... Some might not care about government compliance with government requirements, but for some industries that is essential. But that can be solved with with other drafts. For this, I... For this draft, I I just think that the security considerations and statements should be correct. I I reviewed the draft, I think, some things that should be addressed.
[00:42:08] Stephen Farrell: Okay. And so so I... Does that suggest we should put an action on on John to send some security considerations suggested text? And and would you accept an action, John?
[00:42:22] Damien Miller: I think he's already done that, and I have an action to actually merge his words.
[00:42:26] Stephen Farrell: Oh, exactly.
[00:42:27] Damien Miller: Or or maybe or maybe... Actually, I... Actually, I... Actually, I... I'm I'm recalling the timeline here. I actually got a review from one of my colleagues at work who provided some feedback after John sent his his concerns about the security property section, and I think at least the version that's published... At least the version that's in my GitHub and and and as in unpublished might might address that. So I think we we can take that to the list and and and once once the version that I have is is published, maybe if I could ask John to have another look at it, and then if there's if there's still things outstanding, then I'm happy to address them.
[00:43:10] Stephen Farrell: Great. Okay. That sounds like it's in hand then. Great. Guilin?
[00:43:15] Guilin WANG: Oh, yeah. I just would like to mention that actually for combinations with Ed25519. So, actually, result is also, yeah, strong, unforgeable composite signatures Because MLDSA and also Ed25519, both are strong, unforgeable. So so this may be a more conservative way to use composite signature. Yeah. So maybe you can address John's concern.
[00:43:48] Stephen Farrell: Okay. Thank you. I'm not sure if John is in the queue next, or is that Yeah.
[00:43:52] John Preuß Mattsson: I jumped back in the queue because it's not correct that the LAMP's draft... It increase... It it actually has two malleability vulnerabilities. One, it inherits from the from the components, but it introduces a new. So it... It's not sure that you get... So SUF-CMA just because both the components are soft SUF-CMA. If both are soft SUF-CMA and deterministic, you get soft SUF-CMA. Otherwise, not.
[00:44:28] Stephen Farrell: Okay. Scott, I think.
[00:44:32] Scott Fluhrer: Actually, I don't believe that Ed25519 is actually unforgeable because of the of the subgroup... The small subgroup property of the Curve25519. Yeah. I was go... Also gonna mention, as John did, that there are variants in the composite draft, which does have SUF forgeability, namely the ones which involve RSA to... PKCS version 1.5. If you don't want to use that, that's fine.
[00:45:13] Stephen Farrell: Okay. Damien?
[00:45:17] Damien Miller: I I believe that the... I believe that a d two five five... A d d s a generally can be made strongly unforgeable with particular... Additional checks. I don't believe those additional checks are strongly... Are widely deployed or at least universally deployed. There's there's a good paper on on this which which enumerates the various the various versions of the reference version, the the one that was standardized by ATF, and there's another variant as well, which is perhaps a little bit stronger. I I think in practice in practice, no. You're not gonna get strong strong and forgeability from Ed25519, but it is achievable. It's my understanding.
[00:46:06] Stephen Farrell: Okay. John?
[00:46:07] John Preuß Mattsson: Yeah. Like, there are definitely versions of Ed25519, which was which are malleable, but my understanding is that the RFC requires that it is not malleable. So I'm a bit... My understanding is that SSH referred to the IETF standards. My understanding is that any implementation that is malleable is not conformant to the RFCs. But I... Otherwise, I think the CFRG draft will need to be updated. I think it says that it's... It provides soft SUF-CMA.
[00:46:53] Damien Miller: Well, I I I believe that the the SSH Ed25519 draft includes in in the draft text itself... Oh, so Ed25519 RFC includes in the RFC itself a description of the algorithm. It doesn't refer to the IETF Ed25519 RFC, which was subsequent to the publication of the SSH one.
[00:47:26] Stephen Farrell: Okay. So the the the... So I think the summary there is that the issue is... You know, it's as understood as ever, which is relatively well understood, to essentially proceed with the current scheme with some security considerations text addressing this particular issue. And if and when some stronger composite is produced by c four g, then that can bubble up into the ecosystem later. I did have one other question, though, the relation between this and the SSH signatures. If we add this as is, does that automatically mean it's usable with SSH signatures if that draft was adopted later or with implementations of SSH signatures for SSH... For for Git or whatever?
[00:48:23] Damien Miller: Yes to both. I think I I mentioned earlier that most of the algorithms that are usable with SSH SSH SIG at the moment are also malleable. I think that's a more pervasive problem than this this draft doesn't... Like, I mean, you could argue it makes it worse in in in a a kind of limited way. It... But that the problem already exists. So I think SSH signatures are malleable for the most part. I think if you if you strictly specified Ed25519 or you strictly specified a pure MLDSA, then you could have strong unforgeability in s s h sig. But I think that that's probably something that should be addressed in the... In that draft even when we adopt it and and advance it.
[00:49:16] Stephen Farrell: Okay. That that... That's the answer to my question, essentially. Okay. So I think the action here is, again, it's it's merging that text that that John provided in the new security considerations in the upcoming draft, and then we'll review it, and we have considered the issue. So assuming there's nothing else on SUF-CMA, I I was wondering, would some test factors help? Is there an intent to put them there, or are they not needed? That was a question essentially for me, I think.
[00:49:43] Damien Miller: Yeah. I should answer this. Test vectors always help. I guess, you know, as as as, like, patient zero for implementing this, that I use the test vectors from the LAMPS composite sync draft, which are very helpful in validating that I hadn't messed up. I think the the... There the is one... There's a a kind of, like, half a test vector in the in the... At least the draft in the GitHub. I can't remember what's what's in the public one at the moment. It's it's enough to to generate a a key. I think I think the the gap between that and a usable test vector would be not a a signature to correspond to that. At least a signature would correspond to that that that key. But, you know, as as far as validating validating that... What was I gonna say? Yeah. I I I think if you... If you're implementing this, then you probably wanna look first to the Lamp composite-sigs draft as as... Yeah. Because that that that that has test vectors. Well, at least the the Git repository that the draft came in has test test vectors because that's where I took mine from.
[00:51:09] Stephen Farrell: Okay. So so I... Yeah. We could we could... You know, this can be decided later as to whether they go in the draft or not in the draft. And assuming nobody else feels strongly on test vectors at this point in time, I think the question then is any other issues with the composite draft that we wanna bring up right now? Okay. That's a very great. So that brings us back to our agenda, and that gives us a few minutes to talk about SLH-DSA. Simon's not in the meeting. I presume he would be chatting about it if he was. But what do we wanna do about SLH-DSA? Again, please just jump in the queue and give us your thoughts. I I I... Deb asked that I mean, I'm a... I don't... I thought there was no other ongoing issues with the conference draft. But, again, you can... If if you have another issue on the conference draft that that occurs to you, just please... You can just join the queue for that either. But also... So we're... The queue is open for SLH-DSA or stuff we forgot about to talk on the conference. So, John?
[00:52:23] John Preuß Mattsson: Yeah. I I think the the group should adopt and publish SLH-DSA. It's by far the most conservative constructions, trusted basically by everyone. And it's... I I think recent... If you have followed the, like, academic era of crypto, you have seen that there was a quantum attack basically breaking all lattice based crypto, PQT traditional. This was refuted, so it was not true. But I think for for a week, everybody was afraid that it was true. And we have recently seen attacks, which I think there's a conclusion that it is an attack on classic Mike Ellis. So these things can happen. I think there's a lot of reason to be conservative. And I think SLH-DSA is is the answer. It's... It has a little bit slower performance, but I think it's a price well worth to pay.
[00:53:36] Stephen Farrell: K. Are there thoughts? K.
[00:53:46] Damien Miller: I think it's a good idea. I don't have time to use a bit of myself. Otherwise, I would have done it. But I think I think having a a a conservative signature choice is is a good idea, and I I I don't see any strong reason to hybridize SLH-DSA except perhaps implementation... Concerns about implementation bugs. And and I as someone who hasn't, like, implemented s s s... SLH-DSA, I don't know how likely they are. So I don't have a good I don't have a good prior on on how how heavily I should like that.
[00:54:28] Stephen Farrell: Scott?
[00:54:30] Scott Fluhrer: Oh, since you've asked, I've implemented SLH-DSA a embarrassingly number of times. It's actually pretty easy. It's very hard to actually come up with a SLH-DSA implementation, which is almost right. Any test factors at all will find it very, very quickly, at least in my experience.
[00:54:57] Stephen Farrell: And it it... Was it... Again, it's just exposing my ignorance. Does SLH-DSA have the same issues with kind of private key states and forking? I don't think it does. That's right. Comp... Compared to XMSS, I mean.
[00:55:13] Scott Fluhrer: No. It's a very nice format. Semi. Yeah. It's... Do I have audio on?
[00:55:21] Stephen Farrell: Yes. Yeah. Yeah. You you got it.
[00:55:22] Scott Fluhrer: Okay. Okay. Yeah. Yeah. It's it's very nice private key format, public key format. It's very straightforward.
[00:55:30] Damien Miller: Yeah. I think there's there's there's one bit of state that that which maybe, like, too high a bound for people to actually care about, and that's the two to the 64 limit for the number of signatures a private key can make before you're supposed to retire it. Alright. That's a pretty big number.
[00:55:55] Stephen Farrell: Okay. John?
[00:55:57] John Preuß Mattsson: Yeah. I think these kind of numbers apply to ML-DSA and so on. Also, the security properties start to break down at some point around that. So I think you can and for practical reasons, it would take way too long to do this. So I think practically, can just ignore this counter. As we like to compare to TLS, TLS has implemented and supported SLH-DSA. It's supported in six different libraries for certificates and four different libraries for the actual certificate verify signature. And we have tested them. They they all interoperate.
[00:56:42] Stephen Farrell: Yeah. Thanks. Guilin?
[00:56:44] Guilin WANG: Yeah. I just have some concerns about the performance of SLH-DSA. Yeah. Because SH is also quite popular for IoT devices, like Linux based IoT device and a single board computer, etcetera, like a Raspberry Pi. So I'm not very sure whether there's really practical requirements to use such as strong and a very conservative, yeah, signature scheme like a SLH-DSA. But, of course, if they do have some requirements, so I think I I I can also agree that John's proposal. But, otherwise, maybe I I suggest that we'll wait some time later. Yeah. First, to complete the composite one, and then later, if there's requirements, yeah, to SLH-DSA. Okay. That's my thought.
[00:57:39] Stephen Farrell: Okay. Thank you. Okay. So it sounds like... I mean, the sense I'm getting is that there... People do feel warm and fuzzy feelings towards SLH-DSA. It's not immediate... It's not something that anybody is immediately screaming that they want to implement right now first. And that's... So it sounds like at some point, the working group might want to adopt a draft for SLH-DSA. At that point, we can decide if it... Does it really need to be hybrid or not or... And deal with it then. And we think we're kind... The sense I get is we think we're not quite at that point yet. We'd rather get the current composites finished and then do SLH-DSA. Is that is that roughly correct? I'm I'm gonna take silence as a yes. I think Simon has an SLH-DSA draft, if I if I recall correctly. Yes. The question adoption of that would would face is is anybody gonna implement this? And and... Yeah. So
[00:58:49] Damien Miller: Yeah. I'd... I'm I'm not I'm not gonna have time until next year, personally, so I don't know about anyone else.
[00:58:56] Stephen Farrell: Okay. So... Yeah. So I think I think this... You know, because there's a there's a there's a warm and fuzziness towards SLHCSA, but we wanna get this one done first. I think that's the the high level summary. And with a minute to go, that brings us to any other business. The only any other business, which I'm aware, is whether to to to cancel or keep the session in San Francisco. Dmitry, you're in the queue, though?
[00:59:24] Dmitry Belyavskiy: Yes. I have two a b items.
[00:59:28] Stephen Farrell: Okay. Let me just... Let's just first do the San Francisco one. I propose we keep and... Keep that session and meet there. I'll be remote. I think Job will be in person. Damien, think you said you would too. So proposal is to go ahead with that session. Yes. It's Damien, and nobody said no. Okay. In that case, Dmitry, you have AOBs and some seconds.
[00:59:51] Dmitry Belyavskiy: Yes. First, I... As we now have plenty of... I understand that minor and not as important as OpenSSH implementation of pure ML-DSA keys. I, again, call the chairs to reconsider the decision about adoption of this startup. The work will be done anyway, and it would be better if it would be done as a part of our group, not of independent stream for the... Last but not least, for the for the sake of quality of the document. It's the first item.
[01:00:30] Stephen Farrell: Okay. And and so that's that's asking us to to rethink the the the conclusion we drew on the pure Yes. And Yes. Okay. We... Job and I will talk about it. Sure.
[01:00:40] Dmitry Belyavskiy: Yes. The second one. At the... At the end, we... And then there is a present at the the... This is a post quantum draft, which has no other place to land than SSH working group. Damien then mentioned that he is not against the specification despite its... Has a very narrow scope of usage. So can we please move for this document... Move process with this document
[01:01:15] Stephen Farrell: forward? Okay. Again, John and I will... We'll talk about talk about that and get back to the list with an option call or why we don't wanna do it now kind of, you know, logic. So, yeah, we'll we'll have a look at that and and get back on the list.
[01:01:32] Dmitry Belyavskiy: Yeah. Yeah. Yeah. Again, I understand that it's problematic case because of very narrow interest as a max... As as a maximum. But, again, it's better having it in SSH for group than anywhere else.
[01:01:51] Stephen Farrell: Sure. Okay. I I guess we're we're kinda timing up. So then for the notes, then Dmitry has asked was that the chairs get back to the... You know, re... Relook at the pure LDA issue and get back to this. We'll do that. And that we also get back to the list on the GSS API draft. Oh, this is a ninety minute session, is I thought it was an hour. It's only an hour on my calendar. Are we Oh, okay. Deb says, like, thirty minutes left. Well, maybe we can
[01:02:20] Scott Fluhrer: finish early,
[01:02:21] Stephen Farrell: but maybe we're we're not in that time. It's definitely an hour on my calendar, but not in the invite. Yes. Correct. Thank you, Deb. Everybody can sit back and talk for another thirty minutes. I don't know about anything else. Any other business other business? Or or, Dmitry, if... Sorry. I rushed you. If you if you wanted to take more time, then please... We have it, apparently.
[01:02:57] Dmitry Belyavskiy: Yes. I I can provide the extra arguments, yeah, for pure ML-DSA. Yeah. I'm aware of something like them implementations. So, again, they are minor. They are... The, the most influence will be from Go, I think. But, again, I'm ready to land it in Fedora as soon as Go does, and they promise to do it quite soon.
[01:03:40] Stephen Farrell: Sure. Yeah. Like like I said, we... I'll I'll... John and I will talk about it, and you asked us to think about it again, but think about it again.
[01:03:49] Dmitry Belyavskiy: Yeah. Yeah. Yeah. Yeah. Yes. Yes. And, yes, Alicja has provided the link to the draft to the chat, so I think she can cover it better than I. But, again, it's... Has... Again, it has problems be... Because of overall low interest, and I don't know what's the best way forward anyway. So if you can get get any clue what we can do if it does not lend an SSH, It's also an option, but, again, SSH looks preferable for us. Thanks.
[01:04:28] Stephen Farrell: Sure. Yeah. I I mean, I guess we could... You know, it would occur to me to talk to the kitchen chairs as well just to make sure that's... They they also think it's a good plan.
[01:04:38] Dmitry Belyavskiy: But they... The... We we have talked with Alexei. Melenicja, yes, he thinks that it belongs to SSH.
[01:04:45] Stephen Farrell: Sure. Not not a surprise. But... Yeah. Yeah. We'll we'll we'll... The chairs have taken those actions to to to think again on solo and to come back to the list with a with a... An issue... A plan for GSS API.
[01:05:01] Dmitry Belyavskiy: Yeah. Thanks.
[01:05:04] Stephen Farrell: Great. And, Damien?
[01:05:10] Damien Miller: Since we're since we're in overtime, I guess, just as a general observation, we have a a a number of drafts which have been adopted, that have been sitting there for a while without kind of I... I'm not sure what the next step for a number of them is. So... Well, the the certificates draft, for ex... For example, I think I I think we have consensus, but I'm not sure. It would be good to kinda figure out, like, if if there's stuff we can do between now and and the November meeting and and and move forward with with some of those if if possible or or make an or make an explicit decision to to deal with them in in November, and then I can kinda clear them from my my anxiety list.
[01:05:55] Stephen Farrell: Sure. Okay. So it sounds like you had another reason for Job and I to do a call where we do talk about chair stuff. So I'll... Job and I will talk about doing a call in the next the next week or so and get back on those topics. Yeah. And and, you know, apologies from the chairs for not having done it already, obviously. Cool. Any any other...
[01:06:21] Damien Miller: I just I just assumed you're all busy arguing on the TLS list.
[01:06:26] Stephen Farrell: I never argue. But one can be busy reading the arguments on the TMS list. So... Okay. We don't seem to have any other topics. Then there's a few actions. Thank you to the notetakers. Apologies for my cutting off the meeting 66% through the time allocated. But we... You know, I think we have got to the topics, and, hopefully, we... We'll have a smooth progress on the the composites issue. And with that, if there is really no other business... Job, any other things we forgot?
[01:07:19] Job Snijders: No. We didn't forget anything. I just have a... An... Any other business, item since, we we have some extra time and since there's a bunch of people in the room. Fabian et al recently shared a paper about a side channel attack using compression, the compression context that is shared across multiple channels in SSH. Super interesting paper. And as the results in the current, OpenSSH release, LZ77, which is the dictionary component, and that's the component that is attacked because you can have back references from the multiple channels into the same, like, snippet that's being deduplicated. Therein lays the issue. So that's one implementation that has taken some steps to mitigate that particular side channel. I think John, from Ericsson went even a step further. He's like, I think compression should just not, we we don't support it because we think there's a risk. So I was wondering what what is the general... If if people have opinions they could share about compression in SSH, like, is that something that maybe should be considered for for, revising where, for instance, it could be made explicit that LZ77... The LZ77 components of the c lip compression should not be used, or should it be deprecated, or should some other path be taken? So, yeah, I... That's that's the topic I I just wanted to chat about. I I have no slides or draft or or plan, really, but... Yeah. Are you to to John?
[01:09:14] John Preuß Mattsson: Yeah. Yes, Claire. I don't think I said we have... We don't support it. I haven't checked our implementations. But I think it... I think SSH should forbid it, and we're having discussions internally to add that to our internal guidelines that it shall be forbidden. That's likely to happen, but hasn't... Has not happened yet. So I assume we still support it in our products.
[01:09:44] Job Snijders: Okay. Yeah. I I should not have spoken about the state of the implementation. I I did wanna reference your comment like, hey. I I think there is... I agree there is some issue with compression. Yeah. As to the specifics of implementation, it is in zlib possible to disable LZ77, and then you remain with purely Hoffman coding. And then if you only feed it frames that were... That don't contain data from multiple channels, then that probably is okay. But the downside of that type of mitigation is that the... You don't know if the remote side also disabled LZ77. So it's... Yeah. It's it's... There there... I I feel like there is something to to resolve in in in this group related to compression. Damien, please.
[01:10:50] Damien Miller: Yeah. I think there's I think there's a a sort of family of similar kind of heuristic mitigations we can do, like like, flush the dictionary whenever we observe data being encoded from a different channel. I kind I kind of think they're all, like, super brittle, and I I don't really feel, like, I don't really feel, like, strongly safe just turning off the LZ77, But that that some some... Someone's gonna... Someone's really smart is gonna come along and find a way to a tough attack, Huffman coding as well. You know, the the initial kind of bites in the in... You know, maybe carrying over between two packets or something like that. So I I I sent a I sent a message on the chat. I think, you know, our options are fully deprecate fully deprecate the the transport level compression, which I think is really kind of an artifact. It's like a bit of cryptography that... Another bit of cryptography that shambled out of the 1990s. And, you know, perhaps as a separate exercise, decide whether we want to work on doing a per channel compression scan, which would completely avoid this problem, but there'd be no sharing of compression state across contexts. Also, also no kind of risk... I guess the other the other thing is that most compression that that is used in SSH at the moment is probably the open SSH variant, which is post authentication, which is not not a standard anyway. There's no... There was a draft to standardize that, but there are... There's some... I'd I'd characterize mostly theoretical sequencing problems in in when you enable that. There's no clear sequence point in the protocol if you follow it strictly that that says this is the moment to turn on encryption. I think one of the the the party people pointed that out at some point. So I I think I think I think we should just get rid of transport level encryption entirely. There is a user community who depends on it. So, you know, from a from an implemented perspective, like, that's gotta be done without, you know, gently somehow. I guess the question is, you know, do... Is this is this something that we would want to kind of take on and and find a good replacement for? Or is or is the message to the user community, you know, build build compression into your application protocols and and don't expect it from the SSH transport?
[01:13:50] Job Snijders: Scott?
[01:13:51] Scott Fluhrer: Okay. Earlier was suggested that we just use... Go switch over to Hoffman encoding. It still has shared state between channels. I would strongly disagree. Any shared state between channels means that if if, one channel can affect what the other one does, which may... Will lead to a potential attack. I would avoid that entirely. Thank you.
[01:14:20] Job Snijders: Yes. To clarify, in the open SSH implementation, it is my understanding that the, Hoffman encoding is, does does not use multiple contexts. Does not cover multiple contexts. So by disabling LZ77, it becomes a, a compression mechanism that... Where context do not lead over into each other is the theory. So I think we're in agreement. But, yeah, as as Damien says, I think this is brittle. And and, yeah, that's that's... Yeah. So is... Does that mean that we should maybe make a draft to revise the SSN architecture documents and and just deprecate transport level compression? Any volunteer? We'll take zealot back to the garden sheds.
[01:15:44] Stephen Farrell: So is there... Is anybody jumping up and down to volunteer to do this? Not so far. We can... Okay. We can... Let's see on the... Maybe on the list, somebody will.
[01:16:06] Job Snijders: We could ask, the original offers of the paper that brought this to light if they would be, interested in, the rodeo. The the chairs will send them a note like, hey. Do you want to capture this in the draft? That
[01:16:30] Stephen Farrell: sounds cruel, but okay.
[01:16:38] Damien Miller: Mean, like, everyone's everyone's first draft sounds like an opportunity rather than a threat. So...
[01:16:45] Stephen Farrell: But, yeah, I mean, it's... Can be a good thing. There there are even some some academic funding schemes that attach some value stuff, so impact factors and all that.
[01:16:59] Job Snijders: I would like to subscribe to your newsletter.
[01:17:05] Stephen Farrell: Okay. So thirteen minutes early, seventeen minutes late in my head. Any other other business? Okay. I think there's a bunch of actions. Again, thanks to the notetakers. Thanks to everybody for coming along, especially if it was at an an awkward time of the day. Much appreciated. Good to see we're making progress. Chairs have a bunch of actions, and so we'll... Well, Joe and I will meet in the next week or so and try and progress those more properly. So I think with that, we're all done. Thank you, and goodbye. And I will see you remotely in San Francisco. Bye bye.
[01:17:56] Job Snijders: Take care.
[01:17:57] Damien Miller: Bye bye. Bye.
[01:17:59] Guilin WANG: Bye bye. Peace all.
[01:18:09] Stephen Farrell: Nice. Okay, Joe. I'll ping you later, and we can try and figure out time to do a
[01:18:17] Job Snijders: I have some time now. Let me see. What you're up to.
[01:18:23] Stephen Farrell: Otherwise... I think tomorrow or Friday would kinda be better for me.
[01:18:27] Job Snijders: Alright. Tomorrow is good.
[01:18:30] Stephen Farrell: So tomorrow about... Yeah. I'll I'll figure it out with with some time suggestions.
[01:18:35] Job Snijders: Alright. Catch you later.
[01:18:36] Stephen Farrell: Cheers. Bye bye.