Minutes IETF108: secdispatch
minutes-108-secdispatch-05

# 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.