* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Secdispatch Status Pages

Security Dispatch (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2018-Mar-09 —  

IETF-108 secdispatch minutes

Session 2020-07-30 1100-1240: Room 5 - Audio stream - secdispatch chatroom


minutes-108-secdispatch-05 minutes

          # 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:
          --> 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
          Slides: [Chairs
          Dispatch process: doesn't adopt drafts, only directs drafts to WGs
          Test hum
          ### 1. IDevID considerations ##
          [link to mail
          Slides: [IDevID and Trust Anchor provisioning
          * 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:
          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
          * **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
          * 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:
          * discussion of other work in the area:
          * 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
          * 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.
          * **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
          Slides: [The GNU Name
          * 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
          * 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.
          * **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
          * **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.

Generated from PyHt script /wg/secdispatch/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -