Session Date/Time: 20 Mar 2026 03:30
Certainly! Here is the complete transcript of the meeting:
Deb Cooley: Okidoki. It is 11:30 or something. Something 30. We’re going to go ahead and get started. So, welcome to SAAG. And thank you very much to Valerie for sitting up front so that we don’t have empty chairs.
Um, so this is the Note Well. It’s a reminder about the processes and policies, including about conduct, privacy, and intellectual property rights, that you’ve agreed to follow when you participate in the IETF. Please read it carefully. You’re encouraged to read the source documents to which the Note Well refers. If you have questions, please talk to the working group chairs or area directors.
Meeting tips. So, in-person meeting tips. You’ve seen this before. It’s Friday afternoon. Um, if you’re in person, make sure your audio’s off. Um, remote participants, make sure your audio and video are off unless you’re presenting or chairing or talking or whatnot.
Um, so the agenda can be found here. These are just resources for 125. People are still coming in. They’re late people.
Um, this is our agenda. So we have three talks. We have Bob Beck and Jeff Haas talking about TLS for BGP. We have a talk about China’s next-generation commercial cryptographic algorithms program. And then we have a talk by Ben Dowling about securing QUIC with MLS. Open mic. Probably not a lot, but we’ll see. Any agenda bashing or agenda gardening, as I have heard as the AD for a particular working group that likes plants. Okidoki.
So, we are saying farewell to Paul Wouters as AD. You can see his accomplishments in the IETF here. We are sad to see him go. We’re happy to have him still involved. Um, and thank you very much.
Paul Wouters: Thank you. Um, it’s been an interesting road for four years. I’ve had lots of fun, lots of problems to solve. It’s very interesting, and don’t worry, I will stick around doing other things. So, and thanks for Chris for stepping up and taking all my hot potatoes.
Deb Cooley: There you go. So, instead, we have Chris, who the NomCom elected to replace Paul. This is a picture of Chris. You can see Chris here. Um, and we thank Chris for volunteering. It’ll be fun.
Chris Wood: We’ll see how it goes.
Deb Cooley: It’ll be great.
So, changes since IETF 124. We didn’t have any BOFs this time. Um, and we’re not currently chartering anything. We chartered PLANTS in between 124 and 125. We’ve closed two working groups: OHAI, thanks to Mike Bishop, and TEEP, thanks to Paul. And rechartered Working Group LAKE, and we’re in the process of rechartering probably a couple of working groups: SPICE and maybe OAuth and a couple of other things. Radex. Radex. Yes, there you go.
Um, so we’ve had some chair changes. Obviously, we have chairs for PLANTS. Thanks to Tom Wiggers and Russ Housley for volunteering. Um, SKITT, we have Nicole Bates taking Chris’s place. Thank you very much, Nicole. And PQUIP, we wish a farewell, a fond farewell, to Sophie for PQUIP. We would issue a fond farewell to Chris, but we get him doing other things, so.
Okay, so helping out. If you’re interested in becoming a working group chair, let your ADs know. If you want to become a document shepherd to learn about IETF processes, it’s a good exercise, a learning experience. Um, Errata processing. When you see an errata come through, if you know the answer for whether it should be rejected or validated or held for document update, please reply to that message so that we can make those reports.
All right, so these are the working groups that we have in play today. Um, and if you have sent your summary to the SAAG list, then congratulations. If you have not and you want to step to the mic and give us a quick update, that would be lovely. Go ahead, Paul.
Paul Hoffman: Paul Hoffman. PQUIP is going to be shutting down soon. We tried to get it done while Paul was still our AD. We failed. Um, we have just one document left post-working group last call. Um, I’m assuming I’ll be handing it off to Chris within a few weeks, and then it’ll go to IETF and such like that. It’s up to the chairs to decide when you shut down PQUIP. You might want to keep us around for the IETF last call. You might not. But we’re shutting down, and just to report to people here who were like, “Oh, PQUIP’s shutting down, that’s a bummer.” Um, what Deb has said to me was if there are presentations that would have been appropriate at a PQUIP meeting that are really appropriate to the whole, you know, security area of the IETF, bring them to SAAG, that that is a perfectly reasonable thing to do. So, instead of asking me, “Can you do a presentation?” you’d be asking the ADs if you could do a presentation here in SAAG. Thank you.
Deb Cooley: For RATS, we had a productive meeting, or since the last session, and a number of documents have gone to the Area Director. And so we’ve been working to clear out the queue, and that was fairly successful. We still have a few more that need to get moved on. Um, and I will send something to the list. I just haven’t been able to yet.
Mike Bishop: I just wanted to note the successful conclusion of the OHAI working group, and thank everyone for their contributions there.
Nancy Cam-Winget: Hey, this is Nancy. SKIM’s picking up momentum. Um, we are trying to close down on the use cases. Um, we’ve got some work moving forward on revising the current SKIM, so that work is moving forward. There was a very good presentation on how we might progress on how to deal with provisioning whatever SKIM could do for the agentic identities, um, but that would require rechartering. So we encourage those who are interested in the topic to join the mail list, look at the couple of drafts that are there, and join in the conversation so that we can determine how to recharter.
Mike Jones: Mike Jones. Speaking as COSE chair, we had a productive meeting this morning. Um, the SPHINCS+, aka SLH-DSA, draft looks like it’s going to go to working group last call. Work continues on the Falcon draft. Um, probably most significantly, the COSE-HPKE draft looks like it will exit working group last call successfully and proceed to publication. There were presentations of a few individual drafts that it looks like we’ll be sending out calls for adoption. Um, but work is progressing well and within consensus.
Yaroslav Rosomakho: Yaroslav, speaking as SCITT chair. We had a productive meeting this week and very productive interim a few months back. Um, we are on track to issue adoption calls for our first document, Use Cases, um, and we currently have three competing proposals for the actual protocol. Um, so we have a good amount of energy in the working group, and I think we’re progressing nicely within our charter.
Deb Cooley: Mike, you’re up.
Mike Elmsworth: Sorry, had to find the window. Um, Mike Elmsworth for ACME. Um, ACME continues to process documents in two sort of modes. One is continuing for web PKI, web TLS stuff that’s lock-stepped with CAB Forum, so we have a number of CAB Forum-related stuff coming through. And then ACME also is processing, can we stretch the ACME protocol to serve new use cases? So we’re stretching more into private enterprise PKI, we’re stretching into supporting OpenID Federation as a verification model, and we’re stretching to support, we have a new submission looking, can we support um, on-premise video conferencing applications over ACME or can ACME support them? And we have an interesting submission, can we support using your passport or other government ID as a way to validate your identity for a certificate? So ACME, ACME continues its traditional role of serving CAB Forum, but also is stretching into new applications. Thank you.
Deb Cooley: Okay, so we also have a lot of related non-security area activities. It’s a long list. I’m not reading it. Um, up in the upper right-hand corner is a thing that I added for IED programs, IAB programs. Um, I gave you a link to show you where these things are listed. Um, there’s nothing upcoming that I know of, but there have been some things in the recent past that are sort of interesting in terms of reviewing reports and things. So does anybody have anything for the related areas?
Cullen Jennings: Yeah, really quickly, the SATP group, which almost ended up in the security area at one point but is an Apps area, has finally finished the three documents that they are producing. It is going through the new ADs. It's going to be the new AD, it’ll be reviewed again by an AD. Um, this is a fairly new set of people to the IETF. Um, so be nice, but uh, it could really use a good security review. Um, I’m sure the security directorate will give it a review too, but when it gets to last call, um, just know that that’s sort of the context. They’re defining an entirely new mechanism for how to exchange digital assets between different types of networks. Um, whether don’t think just blockchain and discard it, think any sort of asset network that includes financial systems and banks and everything. They’re trying to make it generic with an exchange mechanism that’s currently unidirectional in their first charter. So uh, could use some good security eyes on it. Thanks. And Paul was the original AD. Thank you, Paul.
Deb Cooley: If you see things that you think we should be keeping track of, you can drop us a note so that we add it to the list. Um, we have also, it’s occasionally difficult to kind of keep track of whether these things are open or closed still too.
Okay, so last time there was a flurry of new mailing lists. So we have ZKP in practice called ZIP. Um, we have a mailing list called Practical Security, which is a discussion of cybersecurity strategies. Um, the RFC 4082 update, which is actually a Tesla update, not that Tesla, but the other Tesla. Um, and then one called CFR, which is customer-facing relay. If you’re interested in these topics, please check out these mailing lists.
Um, we have two drafts that are currently AD-sponsored. Um, we like the switchover for the S-frame draft has not quite happened yet, but it will.
All right, so this is Dispatch. So Dispatch was a fun time, I guess is one way we could say that. So we had a lot of issues with Meetecho for both in-person and remote participants. So the chairs for Art and Sec and WIT are going to go back and review the what what actually happened. Um, and then we will either um, make a determination of what the Dispatch outcome should be or we will take it to a list to talk about what to discuss what the Dispatch option should be. That may be to Sec-Dispatch or Dispatch or just a general WIT list. Um, or we could use SAAG for that too to get broader view, I guess. Wes, was that an old Wes in the queue?
So so this is unfortunate, but it is what it is, and so we’re going to do we’re going to address this promptly after after the meeting.
All right. Paul, you don’t want to do this one last time, do you? This is all the Data Tracker stuff. Paul’s like, “No, there is not much we need to go through here.”
We have a lot of documents, a lot of pages, a lot of working groups. Actually, that working group number’s a little bit wrong because I pulled this before we closed TEEP and OHAI. And Mike St. Johns, there was no Sec-related BOFs this meeting. For the first time in a long time, actually.
Um, this is the current state of play with regard to Errata. There’s a lot of Errata open. Some of it’s in long-closed working groups. Um, if you want to pick a pick a working group and have a go, let us know what you think the outcome should be and we’ll happily resolve it. Just pointers for things. I added Chris. This is sort of fun right now, but it’ll get better. Sorry, Chris.
Um, thanks for sector reviews. Um, we’ve had a lot of really good reviews over the last um over the last cycle. Um, if you um want to be a sector reviewer, let us know. The chairs, working group chairs in the Sec area, get in for free. Um, and we meet on Tuesdays during IETF meetings during lunchtime. And we get lunch. Yay.
Okay, so first up, we have Bob Beck and Jeff Haas. I’m not quite sure who’s doing the talking.
Jeff Haas: So we’re actually going to be taking turns. So you want me to keep slide control then? That’s perfectly fine. I’ll be basically taking the first set of slides, handing it over to Bob to talk about, you know, the actual guts of things, since I am not a security person, I just play one on TV, and then I’ll hit the conclusion. So um, opening up here, so we’re here to talk about TLS authentication for BGP, and you know, that set of words, you know, scares people in multiple realms, both in routing and probably here in security land. Uh, hopefully this presentation will make you feel a bit better and, you know, hopefully help us figure out how we want to move this forward.
Uh, so broad motivation, uh, don’t expect you to understand anything about BGP aside from the fact that it has those three letters and that it’s an IETF control plane protocol. It runs over TCP, like a lot of the routing protocols do. Um, most of our security considerations for transport usually hand-wave around, how do we secure this thing? And you know, for the longest time, we’d say, “Well, IPsec.” Well, IPsec is mostly not used for complicated reasons for most of the protocols. It’s operationally cumbersome, and you know, we’re not trying to solve that problem.
Um, we do actually have in BGP land TCP-AO these days, and previously we had TCP-MD5. That provided integrity, which is the single biggest thing that we require to BGP land. Uh, authentication’s sort of incidental here, uh, by pre-shared keys. Next slide, please.
So, there’s a lot of proposals running around to run BGP and other control plane thingies on QUIC, and you know, myself and you know, the authors for BGP-over-QUIC are partially responsible for that land rush. We’re not going to talk about those. Uh, please feel free to see some prior routing area presentations at IETF 123 and 4. Uh, QUIC, as we know, is basically just a funny wrapper for TLS, and we get the TLS handshake as part of this deal. TLS uses certificates, and most people are familiar with certificates when we talk about WebPKI. WebPKI is not something we want to use for IETF control plane protocols. So what we are here is to talk about a you know, proposed BGP PKI to deal with the TLS handshake and that’s it. Next slide.
So, why are we here? Uh, well, we’ve actually, this is our second presentation. We were visiting SIDROPS giving a very similar one earlier the week. Our goal here is to socialize the idea and you know, get people that are security smart to think about this. Uh, where would this work get dispatched? Uh, probably not TLS; this is just a user of TLS. IDR, well, BGP you know doesn’t really change itself; this is a transport consideration. SIDROPS, well, that was a good conversation because there’s a lot of people that think about certificates for the RPKI already, so you know, we get some good thinking there, and we’ve had some nice suggestions. Uh, the work is hybrid; it lands in the middle of a lot of things: security, routing. We have chatted with the security ADs, we talk to the routing ADs, and they said, “You know, let’s get some concrete proposals.” So here we are. Next slide.
So, operations. You know, the thingies that we care about for a PKI is that BGP has this magic autonomous system number that represents a network in the protocol. And the second property we care about is that BGP sessions are typically manually provisioned between you know pairs of routers by IP address. Uh, other things like auto-configuration does exist, but that’s mostly not what we’re talking about here. Next slide, please.
And so, you know, what we’re talking about here is that, and I think this is where we want to have Bob take over.
Bob Beck: Yeah, that’s okay. No worries, I was sort of waiting for you to hand it off. Um, what we’ve sort of specked out in the draft to start with here is that every BGP session, which is between two BGP peers wishing to authenticate each other, has a certificate for both ends of the both ends of the connection with the AS and optionally the IP as SAN names. This binds the AS, the particular AS, and the IP used for the session together. The goal here is to ensure that we have here short-lived certificates that are generated on demand by the controller of the AS and can be used on their routers at will. Um, the AS, this is done by using an AS intermediate, also with the AS as a SAN name. The AS intermediate can be distributed to your neighbor AS and just used directly as a trust anchor or trusted via its issuer. Next slide.
Certificate lifetimes for the AS intermediate should be reasonably long, year, something like that, whatever we land on. BGP session certificates themselves should be short-lived, perhaps a week or two. Uh, such certificates should be automatically provisioned, and the goal here is to again just avoid any issues with CRLs for session certs. Um, but AS, the the size of the AS space is not such that we cannot use CRLs for the actual intermediates. That shouldn’t be a problem in this case. Next one. Next slide.
With BGP, typically, as BGP users tend to tend to introduce each other and share pre-shared keys or symmetric key material in the past, this looks like a similar model where the introducers are just a mutually trusted third-party CA. Uh, a third party we are hinting here very strongly that a third party should must validate control of the AS before signing such a thing. Um, and one of the ways of doing this is using the proof of possession of a key that’s already present, already present and validated in the RPKI as proof of AS control. We are not, let me be completely clear here, we are not trying to put the certificates into RPKI itself, and we are not trying to reuse RPKI keys as a trust anchor or a part of the scheme. Uh, RPKI is for a different thing than a BGP peering session is. We don’t need to get into the details, but there is we do not want to cross the streams here. The introducer can, of course, get used as a trust anchor itself, or once it’s validated, the AS intermediates could be trusted directly via intermediate elision of like we do elsewhere. Um, next slide.
Main things we are defining here, the new thing is really just to go define a subject alternative name for the AS identifier. Um, we continue to use the existing SAN IP address, and this is the details of what would would need to be in the certificate. Next slide.
The validation procedure just looks like Router A and Router B each have AS X and AS Y. They know which IP they’re supposed to be peering on. Um, Router A trusts AS Y as intermediate, Router B trusts AS X as intermediate, one way or another, and during the TLS handshake, the session certificates checked and verified along with the remote IP, and that’s it. That is as far as we’re going in this draft. Next slide.
Back to Jeff.
Jeff Haas: We need to find a home for this. And what I’m seeing in the chat is actually the conversation we want to have, and I hear the, you know, “This is insane, this is too complicated,” and you know, that’s actually the kind of feedback we’re looking for. You know, and again, in part of the headache we have here is that RPKI is about securing you know things that are related to like IP addresses, AS numbers, that sort of thing. This is more like your traditional you know things you use for securing HTTPS. You know, we’re trying to actually provide point-to-point stuff, but we’re not trying to make these things global. This is not a global PKI; this is just a certificate profile to let us actually connect things together. Uh, if you can actually bounce back to the slide, just the finish the home piece. So we do want to hear everybody’s opinion. We probably don’t want to start a working group because, you know, what we think we can do here is actually really darn simple. The gotcha, as we’ve been pointed out in the chat, is the minute you start doing these simple PKI things, people go for land grabs about ecosystems. And maybe that makes sense. Ideally, it doesn’t. Uh, what we absolutely have no room for, you know, sort of building on the ACME comment earlier in the working group reports, we are probably going to want something ACME-like to make these provisioning these things easy. And maybe that’s part of the insane conversation. Let’s talk about that a little bit. Uh, very similarly, we are aware that solving this problem for BGP sets up a precedent for what do we do about control plane mechanisms for non-BGP use cases. We’re not trying to boil that specific ocean, but we are absolutely aware that if we get a nice technique for this, that we’re likely to see this happen to the rest of IETF. We have a moment for questions, I think. Eric.
Eric Rescorla: Yes, so I actually have um I think two questions um perhaps. Um, so I want to make sure I understand the situation with the intermediate AS certificates. It sounds like it’s like almost web of trust, like a trusted introducer is like someone you trust and then they sign a thing and then they sign a thing. Am I reading this correctly? There’s no not like it’s not like an org PKI.
Bob Beck: I think you could view that as it is almost either way. Either yeah.
Eric Rescorla: Okay, um, and the second question is um uh, did I hear you say that like basically if that is misissued, it’s like there’s no way to fix it, you just wait it out? Is that what I understood?
Bob Beck: No, there we no, there would be CRLs for that.
Eric Rescorla: Oh, okay, good. Okay, thank you for the explanation. Yeah.
Speaker 1: So this is for protecting connections to your immediate peers, right?
Jeff Haas: This is absolutely point-to-point. The easiest way to think about this is if we actually had an AS-level certificate and AS is basically the thing that BGP uses to peer back and forth, that’s sort of the long-lived thing as the intermediate that gets installed on the various routers, and we can have short-lived certificates.
Speaker 1: Well, pause for a second. You said certificates, which I’m trying to avoid. Like let’s focus on the requirements here. This is a point-to-point link to a direct peer that is highly manually configured. You’re setting up route filters and all sorts of things that control your relationship with this peer. So like there’s no need to have a fully general fully automatic PKI sitting next to this. Like just put a PSK or put a certificate fingerprint in the highly manual configuration you’re already doing and off you go. Like I don’t see much need to have a whole bunch of fancy automation here when this is specifically a one-to-one highly manual thing.
Jeff Haas: Yeah, so let’s hit the use case that we didn’t think we had time to talk about and I promised the ADs will keep that brief. Uh, why should I trust that you at the other end of this IP address are who you say you are? And there’s an awful lot of.
Speaker 1: But why did you set up the route?
Jeff Haas: And oh oh, that’s certainly part of this conversation, and part of the motivation to put a authentication layer in here is that BGP, once you accept the routes, do happen. So we’re trying to add a little bit of an authentication layer to say, you know, we think that we can trust you because, and the because in this case is that that AS, you know, certificate can be, by introducers, correlated back to something else that says that you are who you say you are rather than just some random mobster that’s trying to peer with me to inject spam into the network.
Speaker 1: Okay, so that tells me that you’re trying to use TLS not just for the transport security. You’re trying to take advantage of the fact that you’re doing a key exchange here to also do some higher-layer authorization.
Jeff Haas: Yeah, and basic basically the way to really treat this is the property we care about is we care about defining that authentication and the fact that this stuff is tied into mechanisms like TLS, QUIC, that we want to make use of, and BGP has a good use case for the authentication. Uh, from BGP’s perspective, a lot of the plumbing for TLS is actually in the way, and there are other proposals that I’ll paste into the chat about basically doing a handshake, getting authenticated, and then making TLS get out of the way. Anyways, let’s give Martin a second or two. Martin dropped. We’re good, Martin? Okay, thank you very much. We’re going to take this to the list, um, which would be SAAG at this point, um, to carry out more conversation.
So up next is this talk. I’m not sure who’s doing that.
Ah, they’re here. Thank you, Valerie. This is why we have Valerie. Perfect. Um, so we can give we may be able to give you clicker control. Should we do that? Do you want to turn your slides on? Let’s see what happens. Should work. Click it.
Laying Hua: Okay. Good morning, everyone. And thank the IETF meeting and the chairman for giving me this opportunity to speak here. My name is Laying Hua from the Institute of Commercial Cryptography Standards. Today I’m going to introduce China’s next-generation commercial cryptographic algorithm program, that is NGCC for short.
So, first of all, what is commercial cryptography? According to China’s laws, like the Cryptography Law of the People’s Republic of China and the Regulation on the Administration of Commercial Cryptography, commercial cryptography refers to technologies, products, and services utilized for encryption protection and security authentication on information that does not involve anything of state secrets and the like by using specific transformation methods.
So, China’s current commercial cryptographic algorithm system has basically established, which is composed of ZUC, the ZUC stream cipher algorithm, and SM4, block cipher algorithm, SM2, public key cryptographic algorithm that is based on elliptic curves, and SM3 hash algorithm, and SM9 identity-based algorithm. These algorithms have become the industry cryptography standards and also the information security national standards of China, and some of them have become the ISO and IEC international standards.
Next, I will introduce ICCS. ICCS, which is mainly responsible for conducting research on commercial cryptography standardization strategies, implementing the system of commercial cryptography standards, developing the system of commercial cryptography standards, developing and revising commercial cryptography standards, conducting validation, verification, testing, evaluation, publicity, and training of commercial cryptography standards, promoting and applying related scientific achievements, establishing the commercial cryptography standard resource library, and also offering information services of commercial cryptography standards as well as acting as the secretariat of national and industry commercial cryptography standards. So that is ICCS.
And so, in response to the threat of quantum computing and to accommodate the evolving demands of emerging technologies such as big data, internet of things, cloud computing, and artificial intelligence, ICCS plans to call for proposals for public key cryptographic algorithms, cryptographic hash algorithms, and block cipher algorithms. This represents a new exploration building upon acquired research achievements of the international cryptography community, seeking to further stimulate innovation in cryptographic algorithm design and analysis techniques to enhance the novelty and diversity of cryptographic algorithms, particularly the post-quantum public key cryptographic algorithms, to drive more international academic communication and promote the advancement of cryptography. NGCC expects to establish an interoperable cryptographic algorithm suite and facilitate the standardization of the next-generation commercial cryptographic algorithm.
So, for each type of algorithm, there will be four phases before the finalist. And first is to release the announcement. And second is to call for comments or technical documents. And third is to collect the algorithm proposals. The submission window is nine months. And then there will be multiple rounds of evaluation on proposals. Each type of each type of algorithms will undergo at least two rounds of evaluation, and each round of evaluation will last about 9 to 12 months. And the duration for each round may be adjusted in accordance with the actual process. And then the algorithm status reports after each round of evaluation and the list of the finalist will be announced. The specific number of finalist will be determined upon comprehensive consideration of the solicitation and evaluation.
So, on February the 5th, 2025, ICCS released the announcement of launching NGCC on our official website, marking the beginning of the program. At the same time, ICCS issued a global call for comments on submission requirements and evaluation criteria, that’s the draft for public key cryptographic algorithm and cryptographic hash algorithm. On October the 9th, 2025, ICCS issued a notice soliciting proposals for public key cryptographic algorithms and cryptographic hash algorithms. We also released the official version of the requirements and evaluation criteria for these two algorithms, along with feedback on related issues. So as the time is is limited, we don’t we don’t go the details about the these requirements and evaluation criteria for so you can for details, you can go to our website.
So here I’m I’m going here to call for proposals, and there’s also something important that we have to know. The submission period for these two algorithm is from October 9th, 2025 to June the 30th, 2026. From May the 1st to June the 30th, 2026, submitters could update the previously submitted proposal but could not submit a new proposals. That is to say, if you want to submit a proposals, you you should pre-submit a version of the proposals before May the 1st. And for electronic packages, please send to these two email address. And for printed packages, please mail to this physical address. And packages should be sent to ICCS in both electronic and printed forms prior to the deadline.
And ICCS will conduct initial examination and then announce the candidates algorithms for the first round of evaluation. And we also established expert expert teams, expert groups responsible for the technical work of NGCC. The candidate algorithm will be comprehensively established in terms of security, performance, features, and something some other features. Innovation in series and structures is expected. ICCS promotes active participation of social forces in public review of algorithms. We also will release the mailing list of public review. And last, ICCS encourages international cooperations in algorithm design.
So for further inquiries, please contact us via emails. And as the time is it is limited, I’m not I’m not going to give the Q&A section at this meeting. So if you have any questions, please come to me after this section and you can also send us emails. Thank you for your attention. Thank you very much.
Deb Cooley: Wait, we do have a little bit of time for questions if there’s a couple of questions. Paul.
Paul Hoffman: Paul Hoffman. Quick question. Are you will people be allowed to essentially submit algorithms that are already existing other places so that there would be interoperability beyond China or only new algorithms? So like if I want to submit ML-KEM or whatever, would I be able to do that? Would that be considered or are you only looking for novel algorithms? Maybe this is a question for email. Sorry about that.
Laying Hua: Okay. Thank you. I I can talk to you later, okay? Any other questions?
Deb Cooley: Yeah, I think it might actually be better to talk afterwards or email.
Laying Hua: Okay. So thank you very much. For presenters, please follow oh send your question to email and she will answer over mailing list.
Deb Cooley: Right. Thank you very much for your talk. And we will advertise an email address to um on SAAG to send questions to.
Okay, so.
Ben Dowling: Hi, um. I hope everyone can hear me. Okay, cool. Um, well, I’ll get started. Um, thank you very much for the opportunity to chat today. Um, so I’m here to talk about security considerations for space settings, but before I wanted to do that, I really wanted to explore the setting that we’re kind of interested in and kind of the motivation for this draft in particular. So I’m going to be talking about security considerations for space setting.
So, um, this comes from a series of interactions with the DTN group and the TIP-TOP group in particular, who are interested in driving network communication in space settings. And so, because they’re interested in establishing communications within space, the space setting confers a lot of functional requirements or a lot of functional limitations on what these communications look like. And this is specifically because of the nature of the network topology within space, which is to say that um, a lot of these are orbiting planetary bodies, and as a result of that, as you go around the planetary body, um, this might um, prevent you from being able to communicate with the wider network. So the nodes themselves have intermittent communications. And so there are a number of mechanisms for trying to address this, including store and forward mechanisms, which is what is proposed within the DTN group as well as other types of solutions. So we can see this example here, we’ve got a source who is communicating with a destination remotely, but unfortunately due to the positions around this planetary body, they’re unable to communicate directly. And so as a result of this, the source has to communicate with an intermediate node who then pushes this communication on to the final destination once they are able to communicate.
Now, in addition to functional requirements, we also have security requirements for a lot of these solutions. And on a high level, we kind of want to achieve confidentiality and authenticity of these communications. Um, now, this is very broad. We probably want to get into more fine-grained security notions related to confidentiality in particular, but I will address that in a minute.
So, an obvious question becomes, well, satellites are kind of up in space, it might be difficult to actually snatch communications between two points, and so is it actually realistic for us to want or expect confidentiality and other security properties for these communications? And so, um, this is from one of the TIP-TOP drafts, IP in Deep Space, which talks about the fact that it’s possible that connectivity to the internet might become available, that these nodes might be controlled by multiple nations, and so this kind of store and forward functionality that we were talking about before might mean that we want specifically end-to-end security guarantees in addition to point-to-point guarantees. And so the question about whether or not it’s realistic to expect confidentiality and authenticity is hopefully answered by this.
Okay. Um, and so, what kind of attackers are we interested in protecting within the space setting? Because the threat model that we define defines the security properties that we’re interested in, and then the security properties that we’re interested in kind of influence the design of the protocols that we use. So what’s an appropriate threat model for this setting? Um, and so typically, when it comes to real-world cryptographic protocols such as TLS, SSH, or Signal, we’re interested in security against an adversary that can fully control the network, and this is kind of just the norm for cryptographic modeling within this space. Um, that it is possible to compromise derived secrets. So this tries to capture the notion that if an adversary sets up a communication channel with Alice, they don’t necessarily learn any information about the keys that are derived between Alice and Bob in a completely different session. They should be allowed to corrupt long-term secrets or exploit bad randomness. And this is kind of capturing the possible bad use of cryptographic primitives within these protocols. Um, so we’re kind of interested in a network adversary that’s capable of compromising one or more of the endpoints.
So, I mentioned kind of fine-grained security properties, so what did I mean by this? Um, so what is quickly becoming the norm within network communication protocols and security protocols in particular is an expectation of perfect forward secrecy and post-compromise security. I expect that the majority of participants kind of know what I’m talking about, um, but just to quickly go over this, perfect forward secrecy is kind of capturing the notion that sessions or information that’s sent before a compromise remains secure even after the adversary has compromised one of the endpoints. So we can see here on the right-hand side that we have three different, sorry, four different stages: K0, K1, K2, K3. The adversary compromises you at K1, but any information that’s being sent using K0 should hopefully remain secure. Um, and kind of a new notion that was introduced in the last decade or so, but is quickly becoming the norm also is post-compromise security. The adversary cannot read ciphertext after some healing period has occurred post-compromise. So in K1, the adversary compromises the state, but in K2, both Alice and Bob manage to communicate without the adversary injecting any messages or modifying any communication, and so in K3, the adversary should be locked out again, unable to read any further messages from this point. So both of these security properties are interested specifically in security in the face of adversary compromise, and both are quickly becoming standard for long-lived protocols such as those being used within the space setting.
Um, okay. So why are we kind of talking about this? Isn’t this kind of already solved? And so what’s kind of interesting about the space setting is because of this intermittent communication, because the network topology is kind of constantly evolving and is dynamic in some way compared to the internet on Earth, deep space communications have multiple challenges, specifically the introduction of significant and variable delays ranging from seconds to minutes to hours, and frequent and long interruptions of communications where as a result of the movement around a planetary body, you’re unable to communicate with any of the other nodes, and so there’s no alternative path. And so this can influence things such as simply delays on the messages but also introduces significant packet loss within this setting. And so this is difficult to address within the space setting because in addition to packet loss being potentially higher, the delays that are being introduced as a result of this intermittent communication mean that this kind of hides whether packet loss has occurred. And so for protocols where we’re interested in establishing a secure channel via a key exchange protocol, you might try and establish a new secure key, the packet get lost, but you think, “Well, maybe they’re just out of sight at the moment, I can’t communicate,” and so I start trying to send information. So this packet loss can kind of hide whether or not a key exchange or key establishment has been successful.
So, I’ve been kind of talking about the security that is expected of the actual end-to-end communication. This requires keys, of course, um, and so how do we actually establish these keys? So typically to establish confidentiality and authenticity within network communication protocols, we need to establish keys, and the typical way that we do this is through a process that we call a handshake. So if you think of the TLS handshake for instance, where you send client hello, server hello, client finish in order to establish some session key in order for communication. This is what we’re talking about here. And so kind of the point that I want to bring up is because the space setting introduces and hides this kind of packet delay or packet loss, any delay or dropping of the packets prevents the key establishment. And if we came back to those kind of fine-grained security properties, this forward secrecy and this post-compromise security, what we can kind of see is that any delay in establishing fresh keys also delays in the establishment of these fine-grained security properties. Perfect forward secrecy won’t kick in until you freshly establish your keys. Post-compromise security won’t get in until you have a communication in which the adversary has not injected any messages. This requires communications to occur. And so logically, if you have a higher probability of packet loss, then the failure of the handshake increases kind of dramatically. So delays or dropping of handshake messages extends the window of impact of compromise. And so this also delays the security properties that we were talking about before.
And so kind of the proposed solution that we have in our particular draft um, is about asynchronous the use of asynchronous handshakes. So asynchronous support for handshakes, i.e., allowing for one party to be able to freshly update or freshly establish their secrets without communication from their communicating party, will help us offset these massive delays in packet delivery and thus be able to establish these fine-grained security properties more quickly. So these asynchronous handshakes allow us to establish fresh keys and refresh keys without the parties being interactive, and this provides us with resilience against packet loss during this key establishment. And so this helps us shorten the window of impact. And so from our particular perspective, what would an appropriate look protocol look like for this setting? We would like to see an asynchronous key agreement protocol that is standardized that achieves notions such as forward secrecy and post-compromise security.
But that’s kind of a specific solution, and I didn’t really want to talk about a specific solution for the moment, because what I kind of wanted to talk about more broadly is that there are a number of working groups that are starting to look at what network properties should be used within space settings. And so this is things like the TIP-TOP working group, this is things like the DTN or delay-tolerant networking group, this is the SpaceRG group, and so there are a lot of eyes currently looking at what network protocols we should use, what security properties we should achieve, and I think it’s very important that whatever security that we put into space will be hard to upgrade, it will be hard to replace. So I was kind of this is a call to action and just being like, let’s make sure that we get it right, so let’s participate within these working groups. Thank you very much for your time. And I guess questions.
Deb Cooley: Yeah, we have a couple of minutes for questions, so we can go ahead and do that. John.
John Mattsson: Yeah, happy to see more discussion on post-compromise security. I’ve been arguing for that for years. This is not just relevant for space but for basically all infrastructure use of TLS. And TLS and QUIC and TLS and QUIC was actually a step backward in times of secure re-keying. Uh, one I find this a little bit contradicting unless you start talking about solutions. You say you want to have long-lasting sessions to avoid costly handshakes, but you also say that post-compromise security is like a must. But I don’t know what the solution would be, but for example, MLS commit with post-quantum security is post-quantum cryptography is huge. It’s much larger than a TLS handshake with traditional crypto, so it’s a bit unclear here if you can get everything you say you want.
Ben Dowling: Yeah, I think that’s a perfectly valid like question to ask about like the efficiency gains that you get from using like TLS handshakes versus like an MLS kind of like asynchronous update. I think this talk was less about proposing the specific thing, although we have an interest in one particular kind of solution to this, but like I don’t think it’s necessarily contradictory that a long-lived session with asynchronous updates is going to require significant bandwidth overhead or significant computational overhead.
Benjamin Kaduk: Hi, Benjamin. Thank you for this talk. Um, so we don’t have time to discuss this, but I guess a request: perhaps on the list it’d be helpful if you could delve into some more detail about some of the numeric properties of these systems. Like how often they’re out of scope. Um, this also applies like to how the transport system has to react, because like, you know, the transport system uses packet loss to proxy for congestion, and so like the whole system has to be designed to like deal with deal with this property. So I think if you were able to lay out a little more detail like what the like what the actual physical properties of the system are, like bandwidth, latency, you know, packet loss, that kind of stuff, how long you’re out of out of phase, that’d be super helpful for the design problem. So I’ll take my answer off the air, but that’d be helpful.
Ben Dowling: Okay, thanks, Benjamin.
David Schinazi: Hi, David Schinazi, airport enthusiast. Um, you’ve done a great job of convincing me why MLS is a good use for these space use cases, because there are times where devices aren’t online at the same time. The draft kind of related to this regarding like making serious modification to QUIC to inject TLS, I am however not sold on. I think first like my first meta point is either you use TLS or you use something online or sorry MLS or something online for what it is, and if you really, really need to combine the two, use MLS to exchange TLS certificates and then use regular QUIC. I think that’ll be a way less work and a lot easier to do and a lot easier to make safe because redesigning something will take a lot of review to get right. So I would recommend doing that.
Ben Dowling: Okay, thank you very much for your feedback.
John Mattsson: So um, I was very excited to see this because the entire last chapter of my PhD thesis is about how to use MLS to tie into TLS. Um, and one of the main criticisms I got of that was, “What on earth are you going to use this for?” So very nice to see a use case. Cheers, appreciate it.
Brian: Thanks. Yeah, I really appreciate this work and this effort, and I’ll probably be contacting you and soliciting some feedback on some ongoing work in this area because, like you said, it’s absolutely important to not mess up.
Ben Dowling: Perfect. Thank you.
Deb Cooley: Okay, so I think we’re done. There we go. And there’s no open mic, so there you go. We will see you in Vienna. And also that’s my bird feeder camera that got washed away with the spring water because I placed it too close to the river. It is no more. The blue the blue jays are sad. Bye all. Safe travels home. And thank you very much, Valerie. Thank you, Deb. Thank you all.