# Secdispatch @ IETF108 Thursday, July 30 2020, 11:00-12:40 UTC Chairs: Francesca Palombini, Kathleen Moriarty, Richard Barnes Minute takers: Carrick Bartle, Dan York Recordings: https://www.youtube.com/watch?v=V2C3v21m7nU Jabber Logs: https://www.ietf.org/jabber/logs/secdispatch/2020-07-30.html ## Chairs Summary The SECDISPATCH WG met on Thursday July 30. The agenda items were dispatched as follows: (1) IDevID considerations (Michael Richardson) * specification: https://tools.ietf.org/html/draft-richardson-secdispatch-idevid-considerations-00 --> Needs vendor involvement - get more people from the industry and then possibly bring it back. (2) Strong Assertions of IoT Network Access Requirements (Brendan Moran) * specification: https://tools.ietf.org/html/draft-moran-suit-mud-00 --> Dispatched to SUIT. (3) The GNU Name System (Martin Schanzenbach) * specification: https://tools.ietf.org/html/draft-schanzen-gns-00 --> If this is to be done to the IETF, this should be a BoF; guidance to the ADs for the BoF to coordinate/deconflict with DINRG. ## Detailed Minutes ### Introduction (Chairs) Slides: [Chairs update](https://www.ietf.org/proceedings/108/slides/slides-108-secdispatch-chairs-03) Dispatch process: doesn't adopt drafts, only directs drafts to WGs Test hum ### 1. IDevID considerations ## [link to mail post](https://mailarchive.ietf.org/arch/msg/secdispatch/Hqe1lHG2wnW_9NxJLazEYbmGYN0/) Slides: [IDevID and Trust Anchor provisioning considerations](https://www.ietf.org/proceedings/108/slides/slides-108-secdispatch-idevid-and-trust-anchor-provisioning-considerations-00) * presenter: [Michael Richardson](mailto:mcr+IETF@sandelman.ca) * time requested: ? * time allocated: 20 min * objective: get advice to determine what to do with the draft * specification: https://tools.ietf.org/html/draft-richardson-secdispatch-idevid-considerations-00 This document has evolved from others How does computer know who to trust? Software update trust anchor rules everything Stage 1 bootloader key most important key Manufacturer needs to keep private key private Not aiming to write ISO evaluation process Not aiming to give recommendations; just listing solutions and properties, e.g. energy guide Might not need high security Registrar considerations about enterprise private CAs One document is in the process of hopefully being adopted in ANIMA (happening a the same time). Other document is prescriptive Supports work in other groups This isn't a protocol Could be in SAAG but would need review Discussion: * **Mohit Sethi**: These kinds of recommendations are good; how do we get people in supply chain to get involved? What we're writing might not be possible. Devices have chips; how best to involve people in that supply chain. * **MCR's responses**: I've been trying to pass this to people who are authorized to answer these questions * A lot of talks and presentations to get the right people to review this * It costs $10M to do this in a chip factory--wouldn't want to give away secrets * Not asking for secrets, but what we can depend upon afterwards * **Ben Kaduk**: The premise is that we've written a bunch of protocols, guidance to peoople on how to incorporate into our ecosystem. How do we get the right people to review this? * How they achieve this, not our problem; these are devices of particular quality; we want to enumerate what those categories are * Ben: good way to think about it. * **Roman Danyliw**: We have a reference model of how people should do it; manufacturers won't show details, but I'm section 2 in this document; auditor saw everything behind the door. * MCR: exactly * Roman: Are we confident that we've enumerated all the details given that we don't have access to this process? * MCR: In the right place; got a PM about this interacting with NIST document. Will come back to it again. * **Henk Birkholz**: Important to have a lot of people involved who know how these work, but important to guide discussion carefully. Need to do sanity checks. This might be a never-ending thing; need to have precise vision statement; then this could work. * **Eric Rescorla**: Seems like something that would be useful, but not an internet question. Private keys certificates are important but not our thing. These devices are endpoints with specific policies. People who work on this should start their own consortium. "Describe something in your CPS." While this is interesting, we should not do it. * **Warren Kumari**: Not arguing against this, but people might get wrong impression. System may not be secure even if it meets checklist. Auditors may not understand what they're doing. * **Dave Thaler**: NDAs prevent auditors from saying what color it is. * MCR: Put in an order for 100,000 parts and we can talk about it * Dave: Would draft actually be used? * MCR: If that were the case, we should abandon it. Relevant industrial fora would have to repeat this work. Those fora look to us for underlying questions. Determining which color of security they need is something they do rather well at their own peril. They do talk about CMS, SCEP, but look to us for building blocks. * **Rich Salz**: I think this is kinda neat. I tend not to like architectural diagrams. Premature to adopt this anywhere. Go to trusted computing group--only one instance of this. Otherwise this will land with a thud. Internet file system companies: they weren't interested in a BOF. Can't go to a big company and ask about their stuff. I just don't see this succeeding. * **Laurence Lundblade**: "What color is this": similar to certification program. FIDO program: does some of this. Doesn't specify implementation, set requirements so you know how well it does these things. Classification. The value of this is that people want to know. Not to drive manufacturers, but because we want to know what they're doing. * MCR: Supply chain auditing problem: high-level efforts to make this happen in other places. No low-level description they could rely on. Number of parts, ability for them to go and investigate each one becomes less because multiple subsystems involved. Rich's point is well taken. MCR: There are some links in slides of conversations. Richard Barnes: What I'm hearing is feedback that this is afield of IETF focus. We need an indication that relevant folks would be conforming to this and folks would be consuming that, saying they'll contribute to this work, and we may not have that. Sounds to me like no for now, but could come back if we had vendor involvement. Feedback was uniform; don't need hum. (Asked for rebuttal; no one commented.) ### 2. Strong Assertions of IoT Network Access Requirements ### [link to mail post](https://mailarchive.ietf.org/arch/msg/secdispatch/yAeSgixbBM-cBr-he1T20C4nlbE/) Slides: [draft-moran-suit-mud-secdispatch](https://www.ietf.org/proceedings/108/slides/slides-108-secdispatch-draft-moran-suit-mud-secdispatch-00) * presenter: [Brendan Moran](mailto:Brendan.Moran@arm.com) * time requested: 2-3 minutes (+ discussion) * time allocated: 20 min * objective: get wg adoption; get confirmation by secdispatch that it belongs to suit * specification: https://tools.ietf.org/html/draft-moran-suit-mud-00 * prior discussion: https://mailarchive.ietf.org/arch/msg/suit/z0pU6ERSH1sapk15UM0fAGeoEvY/ * discussion of other work in the area: https://datatracker.ietf.org/doc/html/draft-richardson-opsawg-mud-acceptable-urls-00 Presentation: * Originated in MUD. Question: whomud defines what a device should do, but gap about who should do defining. * Where MUD URLs are authenticated. Gives infrastructure policies to device communication. * Clear problems with having unauthenticated reporting for security properties. (802.1x variant) * Settng policies on what your network does. Reasona behind using URL instead of static reporting. * MUD signatures: one way of locking this down. * MUD signatures require root of trust. Checking web reputation. * If reports wrong URL, pretends to be different device. * Server hosting URL; 8520 calls out possibility of rogue CA, can arbitrarily change network policy. * Device communication may be altered by configuration. Might need multiple MUD URLs, adds complexity. * Want to simplify trust model. Binding base set of policies to entities that know about that device. Authors of firmware, entities that do configuration. Know how devices should behave. Can delegate a policy. * Bind this together with MUD, SUIT, EAT. Obtain profile before device needs it. Eliminates latency. Bind firmware and configuration to particular MUD file. If MUD URL instead, would bind particular MUD signer to particular version of firmware. To determine which MUD file applies, use EAT to send info back to network infrastructure. Alternative to 802.1x. Turns MUD manager into relying party. * Advantages: reduces # of actors in system. Trusting vendor, argument for reducing level of complexity in supply chain by coming to single rather than multiple audit. Explicit authority chain. Rogue CA drops out of threat model. If don't want to use this approach, need to question trusting * Question around delivering baseline of how device should behave. * Onboarding flows: how MUD files change over time. How signers of files change. Requirement for onboarding flow. Alternative to MUD URL reporting. Originally came up in SUIT. Chairs said they thought SUIT would be a good home for this, but going to SecDispatch would be a good choice. Discussion: * **Roman Danyliw**: Think this is nice, links together different technologies. Happy to hear from others, this seems to be in scope of SUIT. * **Richard Barnes**: I'm not involved in either working group; would RATS be better? * **Kathleen Moriarty**: RATS might be good; this could also be an extension to a COSWID. Extension capabitlities if a vendor is issuing COSWID anyway. * Brendan: SUIT already contains mechanism to contain a COSWID. * Kathleen: We'd have to think about this more in terms of what we can actually get vendors to do, so we can actually achieve secure hygiene, posture assessment, not just pushing a solution. What has most adoption potential. * **Henk Birkholz**: Could also be in RATS. We already have muddy RATS. In RATS, have to create evidence about resources. Security context of MUD has the same problem. No clear answer to that; problem here that crosses multiple MUD efforts. And also, I love this. * **Dave Thaler**: As one of the SUIT co-chairs, I think this is more suitable for SUIT. RATS has model for things like DHC, we do core stuff, but this goes in other group and we review it. SUIT doesn't have this model; what goes in manifest, goes in SUIT, not RATS. * **David Waltermire** (from Jabber) - (as SUIT chair) From a workload perspective SUIT is working on a single (manifest) draft at this point. Our other drafts are in the publication workflow. * **Roman Danyliw**: Work for both? My read of this draft is the shim we're talking about is really narrow. * **Brendan**: If we put an extension in COSWID, it would be similar. * NOTE: Multiple people in Jabber agreed that this would be a good fit for SUIT. Francesca: Agreement that this belongs to SUIT, we've heard from chairs and AD. This can be dispatched to SUIT. Richard: Roman, should WG chairs be ready to do rechartering? Roman: No one-size-fits-all, charters might fit both, double check why we put work in a particular place instead of silently being decided. ### 3. The GNU Name System ### [link to mail post](https://mailarchive.ietf.org/arch/msg/secdispatch/Kj8zXoQssiFLp8bM5l5n1OtXt7s/) Slides: [The GNU Name System](https://www.ietf.org/proceedings/108/slides/slides-108-secdispatch-the-gnu-name-system-00) * presenter: [Martin Schanzenbach](mailto:mschanzenbach@posteo.de) * time requested: 30 min * time allocated: 30 min * objective: find a home at IETF * specification: https://tools.ietf.org/html/draft-schanzen-gns-00 Presentation: * Implementation of GNU name system. Can find draft in link. * Overview of system * Tries to address DNS issues: traffic amplification, censorship, not already addressed by DoH, DoT, etc. * Fully decentralized; names not global * Features privacy, provides PKI * Creates and identifies zones. * Interoperable with DNS. A user shouldn't even notice which is being used. We've done studies on this. * Common use cases (addressing, directory), presented this in 104, Secushare planning to use this; health care use cases, connect IoT devices without requiring dedicated ? * Technical overview: GNS stores information in Distributed Hash Table. Naive approach: key is name, value is RR data. Query privacy: when you query a record, Private Information Retrieval: attacker can't tell what's being queried. Zones can't be enumerated. Censorship, DDoS resistance. * Equivalence between DNS/GNS: PK record: public zone key. PK record data tells you where to look next in delegation. * Example: assume administrator, Bob has bob.com in .com zone. .com zone has key-value pair. Public key of Bob. Bob can put records in zone. * If other user wants to resolve bob.com, try to discover bob in .com zone, get query, iteratively query DHT name servers until actual record is found. * Why did we do this? Have been at IETF a few times. Tried to register special domain name, document that tried to clarify this process. Invited to present work in 2014, presenting current state at IETF 104, showed our way out of problem in IETF 93, not to put name space at top-level domain. * Last year: presented at ICANN, emerging identifier panel. * Received funding to make specification, including second implementation. * Implemented in 2012, has changed a lot. Written in Go. Written according to spec. * Uploaded current draft. * Informational tag. Looking to improve protocol and spec. * Next steps: received valuable feedback, e.g. cryptography. The way zone and zone keys are created are static. Improve symmetric encryption scheme. Should be updated. Planning to incorporate. Interested in receiving more feedback. Any existing group would be interested? Another group (?) has aspirations in creating working group. Integrate. Discussion: * **Francesca**: mailing list feedback: needs more discussion. Needs to be on standards track rather than informational. * **Wes Hardaker**: Thanks, nice to see it formally documented. IETF and ICANN issues have taken way too long. Interoperable with DNS: not true since conflicts can arise; really a parallel system. Where this might go: why GNU DNS? It's my favorite, but what's the best model in ease of use, scalability. First come, first serve not the model here. Why look at DNS? Still researchy. If complete replacement, seems like research, not WG. Perhaps send it to DINRG (over in IRTF), although concerned about whether that RG could handle all the different decentralized technologies. * **Ted Hardie**: Procedural: if IETF, control shifts to IETF. Resulting protocol may not resemble this one. If documenting what you want to do, different goal. Relationship to DNS described in ways that doesn't map in ways to properties DNS trying to give you. Idea of single root of DNS known to be globally unique at point in time. Hyperlocal root system gives different properties. Ability to resolve names at multiple different roots. What server to ask about name. Getting into place where phishing style attacks are extremely easy. Told to bring to wrong dispatch group. What namespaces do you need to build this for? User identifiers in local system has property of uniqueness not related to global property that DNS has. If this happens in IETF, dispatch to Dispatch. Not about cryptography, it's about identifier properties. BOF or Dispatch question. * **Eric Rescorla**: Re: what Ted was saying, inconsistent results, not a property we want to talk about at the IETF. Dispatch: what do you want? Document somewhere? ISC. Pretty clearly a research project. If want standardize, I don't see us doing that. * Martin: To answer Ted's question: informational because that's what it currently is, but that doesn't mean what it is can't change. If can do it better, can change it. Single root: similar to hyperlocal DNS. Most names will be globally unique, have option to override. Not an expert on where to dispatch it. GNS was a research project, still is, but want to graduate from it. Should be a path out of that. * Eric: If want this developed in I* community, take it to IRTF. * **Ben Schwartz**: A bunch of proposals for alternatives to DNS. Etherum Name Server, Namecoin, Handshake name service. Have to recognize that it's appealing to have namespace alternatives. Can create fresh name spaces over and over again. Sources of caution: if we allow GNS into this, difficult to explain why we'd work on this and not alternatives. Competing namespaces that serve same function is a poor outcome. Looked into allocating special use TLD and weren't able to get that; process by which anyone can get TLD: logical integration point to operate with rest of DNS. Chain up to root you control; anything beyond that you can control. That process isn't free or easy. If add up cost of getting through standards body, might find that it'll be competitive. * **Rich Salz**: Thanks for your persistence. We have an existing protocol, we want to get it documented. We're looking to evolve it. The first argues against IETF except historical thing. Second thing is good for cyrptography nerds. Multiple places this could go. Had a BOF before, but it was more of a presentation. Get people to say they're interested in working on next version of protocol. Is it research, tweaking, security or DNS group? Appreciate coming here to try to get a community. Don't know where that would be. * **Warren Kumari**: The technology is cool and sexy. Problem with trying to use as namespace for things like hosts. If system being used for user identity or other things we want to identify with things on internet, but conflicting with DNS leads to bad outcome. A unique www.facebook.com is an important property. Agree with Ben that if rooted under clearly deliminated TLD would ameliorate a lot of concerns, but the way it's designed at the moment, run into dangerous problems. Everyone's version of name need to be the same. This tries to solve that in interesting ways. * **Wes Hardaker**: One request: stop referring to similarity to hyperlocal root. GNS is not. [RFC 8806](https://tools.ietf.org/html/rfc8806) that specifies what is often called "hyperlocal root" is very clear that it is tightly linked to root of DNS. GNS allows changes to the root zone. Yeti is close because they change the key, but this distributes multiple different roots. You're misuing the hyperlocal root term. Martin: Thanks for the pointer. Keeping separate from DNS: independent from root governance. Just a technical protocol. Not for hosting and addressing. * **Cullen Jennings**: How to dispatch: what would you like to see happen? * Martin: Ideally, would like to become WG and adopt draft. * Cullen: Are you looking to document existing process or want feedback from wider community. * Martin: The second one. If we have to, we'll just document what we did, but that's not our first choice. * **Richard Barnes**, summarizing as SECDISPATCH co-chair: What I'm hearing is if this is going to get worked on at the IETF, need to have full BOF and have feedback from multiple groups, from naming groups, cross-area problem. The decision to grant BOFs is open to the chairs. Feedback from people about whether BOF makes sense. * **Kathleen**: Take to mailing list so we can keep everything in one place. When get to stage of requesting BOF, will inform ADs about decision. * **Francseca**: ADs? * **Richard?**: Will mailing list help you? Continue using SecDispatch? * **Martin**: Opening another mailing list isn't necessary. * **Ben Schwartz**: I support dispatch to DINRG. Charter namechecks namecoin and Ethereum name service as examples in scope. GNS in that line, that's where the expertise is. Reflects the maturity of this. Can't get started on standardization until there's an emerging consensus about how it should work. * **Richard**: Feedback from DINRG already? * **Martin**: We presented it to DINRG at IETF 104, but haven't received feedback. * **Ben Kaduk**: Been told that updates from DINRG will be dispatched. * **Eric Rescorla**: Concur with Ben, not maturity to have BOF. * **Wes Hardaker**: You're in a weird place because you've articulated the problem you're trying to solve, but how to address scalability and uniqueness? BOF not the right choice. Would be a big failure. BOFs shouldn't have a complete statement. "Is this a problme the IETF can solve?" Answer currently would be no. Not because you're not solving a good problem. Scalability concerns. Fantastic research problem. DINRG the right place to go. Ask them; don't just give a presentation. Ask to be active draft. * **Richard**: Thanks for feedback. Summary: if IETF, needs full BOF. Feedback, deconfliction with DINRG to make sure it's IETF work. ADs, seem clear to you? * **Roman Danyliw (AD)**: Seems right. Equities to consider here. Ben and I are committed to talk to IRTF to broker that conversation. ### AoB - Open Mic ### Any other business? Richard Barnes: Go socialize. Roman: prep beforehand on mailing list, agenda, helped with process. Thanks to chairs for doing that. Need discussion before SecDispatch helps it be productive. Please continue doing that.