INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2022-09-08 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jay Daley / IETF Executive Director Jenny Bui (AMS) / IETF Secretariat Martin Duke (Google) / Transport Area Lars Eggert (NetApp) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area Paul Wouters (Aiven) / Security Area Qin Wu (Huawei) / IAB Liaison REGRETS --------------------------------- Roman Danyliw (CERT/SEI) / Security Area Mirja Kuehlewind (Ericsson) / IAB Chair Francesca Palombini (Ericsson) / Applications and Real-Time Area Alvaro Retana (Futurewei Technologies) / Routing Area OBSERVERS --------------------------------- Marc Blanchet Spencer Dawkins Christian Hopps Kiran Makhijani Lee-Berkeley Shaw Robert Sparks Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to today's agenda? Paul: Can we add a small item on DNSSEC for ietf.org and another one for the executive session. Lars: I have an addition which is also probably for the executive session. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes from August 25 being approved? Hearing no objection so it sounds like those are approved. I know the narrative minutes haven't been out for the full two weeks but I also didn't get any changes for those; do you want to keep those another couple of weeks or is there any objection to approving those as well? I'm hearing no objection, so it looks like those are approved as well. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn) [IANA #1229681]. Amy: We'll keep this in progress for Roman who's not with us today. o Martin Duke to find designated experts for RFC 9297 "HTTP Datagrams and the Capsule Protocol" [IANA #1238909]. Amy: This is a new action item for Martin. * OPEN ACTION ITEMS o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in October 2022. Amy: This is on hold until October. o Murray Kucherawy and Martin Duke to contact the HTTPBIS chairs about the request to register a HTTP/2 Frame Type registration [IANA #1237502]. Martin: We decided not to do that, I think. We're not going to register the code point that Google requested. I don't think as the IESG we need to get into a conversation about changing the policy. I propose we just kill this action item. Lars: Why are we not discussing this with the WG? Martin: For the actual code point request, it turns out that it's an entirely internal project. Lars: You're speaking with your Google hat on now? Martin: There are two things; this specific request, which it turns out not worth doing because it turns out it's an internal project. Lars: The request is being withdrawn, is that what I'm hearing? Martin: it would have been nice not to have to screen these things on our ingress but… Warren: But even if it's an internal project, which I don't know anything about, there is a somewhat regular precedent for code points being assigned for internal stuff. Otherwise Google is going to choose 63 and somebody is going to use 63 in the future and it'll either leak from the Google network into the Internet or when somebody on the internet tries to use it and it doesn't work. There's still a risk of collision. Martin: That would be better in my opinion but that's not consistent with the policy the WG has set up for this registry. Warren: Should someone at some point say maybe we should have an experimental range? Lars: We have a request. It sounded for a minute like Martin said Google is withdrawing the request. If that's the case, then an email would be nice so we know it's formally withdrawn. If the request is pending, I think we've got to go forward with the approach we discussed last time which is to talk to the HTTPBIS WG about how they feel about this request. I informally looped in Tommy Pauly because he's on the IAB and we chatted about this on the side a little bit. The chairs, at least, have heard about this a little bit. Martin: I think the current situation is, if it's going to be this difficult then forget it. I think that's the accurate summary of my colleagues here. If the policy was simpler and didn't require an RFC or whatever, then I think we would go ahead and request it. Lars: So if the request is dropped it would be nice to get an email to that effect. I'm not pushing you to drop it. Otherwise if it's not dropped we have to figure out what to do with it, and that entails going to the WG. Martin: Google hat off, I don't know if we want to continue to push the WG about this policy or not. Zahed: If it helps, I think the question that you're asking could be best answered by the WG chairs. If you want to continue, talk to the chairs. If you think it's too much work and you don't need it, just send us a mail that it's dropped. [crosstalk] Martin: My understanding of our discussion last week was that the stated intent based on the policy for that registry is you better have an RFC and there's this IESG backchannel if the thing is becoming unnecessarily burdensome. Which does not really lend itself to these sorts of internal projects. We were going to push on it because I thought this was going out over the internet. It's not going out over the internet so the heck with it. If I were an active participant in HTTPBIS I might suggest we change the policy, but I don't know if the IESG needs to put in more time. John: It seems to me like we have an existence proof that the policy on the registry is wrong, somebody should point that out to the WG, and if they want to do the right thing they can do it. If they don't, then it's up to them. This little exercise demonstrates that there's a need for a private use range in there, I think. That's exactly what you're doing, is private use. But it just gets punted back to the WG with that observation at this point. Warren: I know nothing useful about HTTP but I remember that there have been similar types of things in bgp, where people have said I'll just use this internally and it will never leak externally, then somebody else started using it and the world stopped working for some subset of people. Even if it's not used externally I have no idea what the implication is if one day somebody uses this in the real world. It seems like somebody should chat with the WG. Martin: The correct thing for Google to do is to filter out that frame type on its ingress. Warren: Until that frame type starts being used externally and suddenly people want to use it on the internet but Google has filtered it out. Martin: I agree, but also not my WG. Ultimately if there was a standard that used this code point we'd probably just change the constant in our code and it would work fine. Lars: For this request, if you want to drop it it would be nice to get an email, otherwise you and Murray are going to talk to the WG chairs. It seems like somebody should be writing an individual I-D that says there needs to be a private use range here. I don't care if that's you or somebody else, but that should also go to the WG and see what they do with it. So my suggestion would be to leave this open at least until the next telechat to see if we got an email that withdraws the request or not. We can't simply not do anything with it, because we got the request. Martin: All right. Amy: So this will stay in progress until we get a way forward. o The IESG to review the proposed revision to the Tao (https://github.com/ietf/tao/blob/main/Tao.md). Amy: This is on the agenda as a management item today. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-cose-countersign-09 - IETF stream CBOR Object Signing and Encryption (COSE): Countersignatures (Internet Standard) Token: Roman Danyliw Lars: You might want to refresh; I just cleared my Discuss. Amy: I have one Discuss; do you think this is going to require a Revised ID, Paul? Paul: Let's discuss this a little bit; we don't need Roman for that. The issue I have is it actually has a UNIX command but you can see there gem install cbor-diag. The problem is that with regular occurrences we see that packages from various installers are either abandoned by the authors, or backdoor replaced. I'm really nervous to have that exact command in the RFC in the main body, to say if you do this you can install this software. We have no control over this if there's ever something where the ownership changes to out of our control. I wouldn't mind if that was some sort of ietf.org resource where we put that code, but I kind of have a problem with saying to install this random piece of software [in the RFC] because if it's ever backdoored, copies of these RFCs are all over the internet so we can't undo it or say uninstall this because it's malicious. Lars: I agree, actually. I think it would be fine to simply point to the Github repository where the first line is how to install it. But then it's not in an RFC. I don't know if they even have a reference to that repository in the draft, which seems like a useful thing to add anyway. Paul: I'll take that up with Roman later on. I have no objection to a Github link or something that points to the software. Warren: Doesn't that basically apply to any time we talk about any software implementation at all? You have no way of knowing that certain implementations are horrendously backdoored. Paul: But we don't tell them to go and install from a random place on the internet. At least those commands would be limited to the vendor approved location and it's on the management of the vendor. Warren: I think we're giving people a lot more credit than is due, assuming they would ever do anything like read the code before installing it. But whatever. Paul: If you do a gem install you're not reading the code, you're just installing it. If we give a github link you can have a look at the link before you run the command. Warren: But that's exactly my point. If you point at the source code on github, like for Bind, yes somebody could go along and read the source code before downloading it and compiling it. But you know nobody does. Paul: But that page could be updated to say the bind code has been backdoored, don't use it anymore. Whereas the RFC text cannot be updated. Warren: You know what, I don't care. Moving on. Paul: So I'll talk to Roman about this. Amy: This will stay in IESG Evaluation and I'm going to put it in AD Followup for Roman. Éric V: The problem raised by Paul is much broader than just this draft. I would love to have this discussion at the IESG level someday. o draft-ietf-sidrops-rpki-rsc-10 - IETF stream A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists (RSC) (Proposed Standard) Token: Warren Kumari Amy: I have a Discuss in the tracker; do we need to discuss that today? Warren: Maybe? I looked yesterday and didn't see a Discuss. Murray: It's [mine] and it's IANA stuff. Warren: How hard is it to fix this? Murray: Not hard. I'm already replying. Warren: In that case, we have just discussed it and thank you Murray. Amy: Will this be a Revised ID? Murray: The changes will be small, but yes, it'll need a revision. Amy: Okay, we'll put this in Revised ID Needed. Thanks. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-teep-architecture-18 - IETF stream Trusted Execution Environment Provisioning (TEEP) Architecture (Informational) Token: Paul Wouters Amy: I have this as Consensus Unknown, i'm going to change that to a yes for you. I have no Discusses, so unless there's an objection now it looks like this one is approved. Éric V: You may want to make this Revised ID Needed to fix the comments as we agreed. Paul: There are a few comments, so let's put it in Revised ID Needed. Amy: Okay, this is Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-rats-architecture-21 - IETF stream Remote Attestation Procedures Architecture (Informational) Token: Roman Danyliw Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this one is approved for Roman. Paul: I see a number of comments so I think it's safe to put it in Revised ID Needed and I'll ping Roman as well. Amy: This will go into Approved, Revised ID Needed, and Roman can let us know when it's ready to go. Thank you. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-irtf-cfrg-hash-to-curve-00 IETF conflict review for draft-irtf-cfrg-hash-to-curve draft-irtf-cfrg-hash-to-curve-16 Hashing to Elliptic Curves (IRTF: Informational) Token: Paul Wouters Amy: Paul did the review for this document. I have no Discusses in the tracker, so unless there's an objection the no-problem message is clear to go back to the IRSG. I'm hearing no objections, so that note can go to them. 3.4.2 Returning items NONE 3.4.3 For action NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Stub Network Auto Configuration for IPv6 (snac) Amy: I have no blocks to sending this for external review, so unless there's an objection now it looks like this is approved for external review. Éric V: Just let me fix the charter, because the wording was not clear. I will clean up the charter a little bit tomorrow my time and then we can go forward. Amy: Okay, so external review is approved pending edits to the charter and you can let us know when it's ready to go. 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval NONE 5. IAB news we can use Warren: There was some discussion on draft-nottingham-avoiding-centralization and what the future of that will be. I think that will be a document that is worth people on the IESG having a look at and I will put a link in the chat. It's interesting. Also, if the IAB is going to be responding to the federal register's questions on Trade Regulation Rule on Commercial Surveillance and Data Security. It's unclear if they are going to be responding but it is something which I think a number of peoples' companies are likely to be commenting on, also something the IESG might want to have a look at because it is both architectural and covers stuff we are interested in. I think those are the primary things. 6. Management issues 6.1 Tao Revision (Lars Eggert) Lars: I hope everybody has had a chance to look at the new version of the Tao. Sorry there isn't a very readable diff. Is there any objection to publsihg this on the website as the current version of the Tao? Éric V: I didn't have time to review it completely but the beginning is basically assuming the meetings are occurring in person. There are no words about hybrid or remote. Lars: I think that's probably text that's unchanged. If you want to propose new-- Éric V: No, I have no time to do that. I would have just expected it to [have reference to that]. Lars: But are you okay with this being published even if it doesn't mention hybrid meetings? Éric V: [Nods yes]. Lars: Okay. Everybody else, are you okay with this, or at least not objecting? Thanks. I'll send a message to the editors and Greg. Oh, Greg is on the call. Do you need anything from me besides telling you it's okay to go? Greg: Replying to Niels's email [would be great]. Lars: Okay, I'll do that. Thanks. While we are on the Tao, I'm still waiting for the gendispatch chairs to tell me what they think the rough consensus was based on what we are going to do with the Tao going forward. In the meantime, we're just going to publish this. 6.2 [IANA #1238909] Designated experts for RFC 9297 "HTTP Datagrams and the Capsule Protocol" (IANA) Amy: This is the reminder of a new action item for Martin. 6.3 Datatracker and self-contained XML (Éric Vyncke) Éric V: You know in XML we can basically include files that are either local or remote. It's kind of dangerous if we put in our XML I-D repository documents which include documents in other places. So, Robert is on the call and Robert, please feel free to jump in because he has to explore this much better than I do. The point is basically to force all the XML I-Ds to have all the includes done before uploading to the I-D repository so nobody has to do the include anymore. It's a static XML document. Robert S: In particular, if the content of the references change, for example, and you re-render that XML later, you would get the same result and not the updated reference result. There's an issue on Github that has some of the details about other places where leaving the wrong includes can go wrong. Where I'm aiming to take this is that at submission time, there will be a step that fully expands and executes all the includes, shows the submitter the result, and then what goes into the repository is the fully expanded draft. The ticket has discussion about how we make this easy for authors so they can still keep pronouns for things like references in their source document so that they're not having to expand and then unexpand. That is technical work to be done but it is one of the requirements we plan to satisfy when we work towards this goal. It is a fairly large policy change and we wanted to make sure the IESG was giving us the direction to go there. Éric V: Thank you for the explanation, it was slightly different than what I said. Warren: I want to know what the implications of this are for people who are doing things like downloading the draft repositories and parsing them and things like that. Other than presumably we'll need to upgrade our internet connections. Robert S: Not particularly. The reference expansion on a typical draft adds like .2% to the size of the draft. Warren: I still download and use the text ones for a bunch of stuff. Robert S: Seriously, size isn't going to be an issue. The important thing is that at the point of submission, people aren't making a notewell statement. If there are includes that are left in what was actually submitted, then we don't have a record of what was actually submitted. Lars: That makes sense to me, Robert. It seems like in terms of authors, it's not a terribly big change if they're using modern tools. Specifically kramdown. I guess authors that author directly in XML will need to change. Or does xml2rfc spit out a submittable XML? Robert S: That's what I'm planning to have happen. We're basically there with prep tool. It would just prep a draft by fully expanding it and the XML that was the fully expanded result, the authors would get a chance to look and make sure it got the references they intended for it to get, or other content they were including with xi:include. And they would not actually have to change their workflow or how they keep their source, there would just be an extra step at submit time. Warren: An extra step the authors have to do? Or an extra step that happens on the once it's uploaded side? Does this happen before submission? Robert S: During submission. For the web based submission, authors would go in and at the point where you normally would wait and see 'did idnits run correctly?' you would get the 'I expanded your draft, do you want to look at the bits? Click yes or no.' We can add this to the API for the API submission if the author wants to look at the expanded bits before it finishes the expansion process. We can give people the option. Otherwise the API submission process can just sail past it. Warren: So for most authors they might not really care about seeing the thing, but they won't have to change stuff. Robert S: This is where I'm hoping we can take it. Rob: Why would we need to ask them to see the expanded one? Aren't the includes exactly what we would effectively use to generate the output anyway? Robert S: Some authors still don't trust when they submit the XML, they also provide text, because we had a long period where xml.tools.ietf.org was broken. We're still in a transition period where the bib.ietf.org bibxml still sometimes produces surprising results. So if the authors are particularly particular about what the content of the, for instance, references they had provided by an include contained, they would want to look to see that the tool did the thing they expected the tool to do. Rob: I would just suggest the link to say something like here's the link to see it, but you probably don't care about it, and that's fine. Or alternatively, if the tool could diff between what it generates as the text and what you uploaded and flag any differences, as another way of checking. I don't know if you'd have other cosmetic differences that would end up being painful. Robert S: I would have to go review the code to see where we are on this evolutionary path but we have a long term plan to stop letting people hand us the text if they're handing us the XML. Rob: That makes sense to me. I'm broadly supportive of this and I think it's a good idea. I parse the XML to do grammar checking and things. I'm sure I've set mine to ignore includes so this is probably good. Lars: One other thing, I'm thinking about the case where somebody has an XML that has includes in it, is used to uploading these, we make that change and it fails. It will be really useful if whatever message is being presented was actionable so they knew how to fix it immediately and resubmit. The one thing we don't want is to submit the text only version instead. Robert S: It's an antigoal to drive people away from submitting XML. Lars: Right. Something like a friendly 'here's how you should run your xml to rfc' to generate something we can take in. Robert S: Agreed. Lars: Do you want us to minute anything formal that we are okay with this direction? I guess we will get back to it when there is a bit more? Robert S: Sure. Just a line that we can point back to to remember we all talked about it and the IESG was aware and okay with the direction we are headed, and we can bring it back when we actually have the concrete implementation ready and people can look again before we pull the trigger. Sandy: Sorry if you already said this, Robert, but what is the timeline for implementing this? Robert S: Hopefully in the next 2 to 3 months. Sandy: Okay, perfect. As an FYI, we have not tested unprep that well but when we have run it there have been a couple of issues. We'll do some testing on our end to make sure it's working for us. Robert S: To be clear, I'm not thinking we would do a prep on prep thing. IT would be a prep-lite thing and they could look at the results but they would still have their source that would be the thing they modify for the next time. Sandy: So what actually gets stored in the datatracker? So when the RPC pulls the XML file? Robert S: The fully expanded version. So you're looking for the ability to get back to something that would pull references, and this is not intended to be unprep as currently implemented. It'll have to be something different. Sandy: Okay, got it. Lars: I guess we will revisit this when we are ready to try it, and we'll timeline it so it won't be right before an IETF meeting or something like that. Maybe the period between 115 and 116. Thank you. 6.5 DNSSEC for ietf.org (Paul Wouters) Paul: Jay sent a slack message and he is on the call as well. He was saying that we might be outsourcing things like hosting or domain name management in the next weeks or months and maybe it doesn't make sense to do this migration right now on these custom tools we're using. I just wanted to bring this back to the IESG and get some input on what people think we should do. Should we do this anyway with our tools for now or should we move forward? Jay: To add to that, nothing is going to happen quickly. We're going to have a process that takes some months to define the new infrastructure strategy. The current contract with AMS expires at the end of 2023 so our new supply strategy or whatever will not take effect until the beginning of 2024. That's why I'm comfortable with you changing signing periods, key strengths, all of that kind of stuff. The more awkward one about moving to a hidden signer is something I think is potentially more difficult to achieve in that period of time. Paul: Okay. That's fair. One of the new items that also came up was that I didn't realize the RR6 that are used right now on ietf.org data are valid for one year. For instance, tools.ietf.org has been or will soon be changed from an individual server to our server, and I think that's already happened. But if someone has that record remembered from nine months ago, they can still play that record as a valid DNS record because the signature is valid for a whole year. This is why normally signatures are not valid for more than a couple of weeks. Warren: Yes, they can. I put a link to the standard list of DNS outages. To me it feels like the threat model of accidentally forgetting to re-sign and having the signatures go invalid and all of ietf.org disappears off the internet seems much larger than the threat model of somebody has kept a copy of a record that we've changed the TTO of and plays it back. Paul: Warren, I understand that if you think of it in terms of threat model. But if you think in terms of what is the policy we are advocating everybody to use and we're not using it ourselves, it's much more a presentation and marketing issue. We should use our own recommendations for values we have in the RFCs and not make up our own. Warren: I think the advertising and marketing outcome when ietf.org falls off the internet because we cocked up the DNSSEC is much more harmful than pretty much no one has noticed that we've got-- Paul: Yes, but if we reduce the signatures from one year to one month, it's not going to fall off the internet unless the infrastructure run by Glen is offline for more than a month. Do we think that's likely? Do we have backups of the keys so that we can interfere? Warren: There's a difference between it having fallen off the internet for a month or somebody deleted the keys, and the job that does the signing didn't run. But anyway, I think the risk of things not re-signing is much larger than somebody might think we're using too long a time on the keys. I will just wait until we fall off the internet. I also think there's a risk when we change the algorithms. Martin: So if Glen is hit by a bus do we have a recovery plan? Warren: The DNSSEC part we could deal with through machinations. We could recover from that. Paul: I'm assuming we have backups of the data regardless. Jay: We have a contract with AMS that requires them to manage such things as Glen being hit by a bus. It's a black box contract and we don't have some of the details of things that go on within that contract. So we just have to assume that this is taken care of for now. Warren: I'm sure there are backups, but it is a black box contract. Jay: There are backup systems and we do know some of the details. Robert and I don't know about specifically accessing the keys and how that's managed within AMS. Warren: The DNSSEC part is trivial. Somebody can log in through the registrar. My thing is more the embarrassment of when the signer job fails or we try to change algorithms/key lengths and we break. Paul: We need to change the algorithm anyway because we're about to publish a document ourselves that says MUST NOT use [?]. We simply cannot stay on this algo. It's not a question of should we do this, it's a question of when to do it. Warren: I agree it's when, but if we do it now, and as soon as the contract ends, we've done it twice. Paul: Well, maybe. Depending on the new infrastructure we might end up with in 2024 we might just be able to give them our private key and they can just import the key and run with the same key without doing a rollover. There are options here. Warren: I've stated my position. I will happily be in the rough and when it goes kaboom I will point and laugh. Paul: Let me propose the following then. Wes and I are going to assist Glen in setting up a parallel copy that's doing the rollover for some testing. Once that is functional we will get back to the IESG and look for a final go-ahead. We can always abort if we don't get that. Jay: Are you also going to go to the community on the tools-discuss team as well? Paul: I'm happy to have more people contribute if this is tied more into tools or if the tools people are interested in being involved, sure. Jay: It would be good just to give those people a chance. Robert S: I think it would be a good idea to leave an artifact on a publicly archived list that a plan is being developed and there's an opportunity for other people to say something about it so later when people discover their cheese has been moved there's something to point to. Paul: That sounds good. Let me draft up something with Wes and we'll run it through the IESG first before we send it publicly. Lars: Was there also a related issue with the TLS certs? Did we talk about this? Or was it always DNSSEC and I'm misremembering? Paul: It was always DNSSEC. Lars: I thought someone mentioned something about TLS…. Robert: We dropped TLS 1 from those certs. That was a change we made at Cloudflare and nobody noticed. Lars: Okay, great. 7. Any Other Business (WG News, New Proposals, etc.) Murray: I just emailed everyone about the old/new document , IESG statement we were preparing. I would love to get that settled so please take a look and tell me if there are any last comments before we put this to bed. Lars: We also have the BOF call next Tuesday. I'l be traveling but i hope i can make it. I saw there are a few BOF requests that are coming in now. 6.4 Executive Session: IESG Appointment to the IETF Trust (Lars Eggert)