DULT @ IETF 121

Co-chairs: Sean Turner, Erica Olsen

Note-taking: Daniel Kahn Gillmor

• discussion about threat model
• ekr: the proposed text changes suggest that a different set of facts
  are relevant, but they don't (yet) address what the algorithm should
  be to detect those circumstances. We will still need the algorithm

draft-ietf-dult-accessory-protocol (Brent Ledvina)

• where should terminology section live?

  • ekr: i don't want a copy in each document. at the end of the
    production process we could copy/paste to make sure they're
    aligned, but not now. I'm inclined to leave it in this document.
    It needs to be part of the normative spec. Other docs can cite
    this one.
  • Barry Leiba: i agree with ekr that it can live here. But that
    means the other documents are MISREF until this is released.
  • Andrew Campling: standalone terminology document makes it easier
    to maintain.
    Agree with what ekr said earlier: let's have it here, in the
    thing that is the most technical. If there are more generic
    terms, we could put the high-level terms in the architectural
    document. As publishing, this is going to be a cluster of docs
    that will depend on each other, similar to what the privacypass
    work did.
  • dkg: if we publish as a cluster, this doesn't matter. if we want
    to put something forward first, we could try to move it to that
    one, but then that locks it in.
  • Sean: doesn't make sense to publish separately.

• Brent: who will review?

  • Barry Leiba
  • Daniel Kahn Gillmor
  • Eric Rescorla
  • other doc authors?

• (slide 6) Applicability statement: do we want it?

  • ekr: i'd write it into the rest of the spec, define "small",
    then say "if small, MUST do X"
  • Andrew Campling: size is a red herring. you can't hide a
    bicycle, but you can embed a tracker in a bicycle that someone
    is already using.
  • Maggie Delano: the tracker component might be detachable. if you
    make a tracker for a bicycle or luggage, so it thinks it's big,
    it could be detached and not know it, and it would still behave
    as though it were big.

• ekr: we should reconsider the breakdown of the documents, because
  they seem to be tightly intercoupled, and even though they match the
  larger pools of work, they might be better off integrated.

• deb: get the text down and then redo the organization afterwards.

• (slide 7) Sound maker requirement:

  • Nick Doty:
    https://cdt.org/insights/centering-disability-in-mitigating-harms-of-bluetooth-tracking-technology/
    speakers are important for people with vision disabilities.
    maybe we should require haptics or flashing lights or things
    like that.
  • dkg: i don't understand the argument for removal. just because
    manufacturers want to make something smaller/cheaper/whatever
    doesn't mean that we should say that's OK. This is about how to
    make a responsible device.
  • Andrew Campling: i predict a market for things like accessories
    that will muffle sound and block visual detection (waves his
    keychain)
  • Siddika Polatkan: if we're going to demand other things (e.g.,
    haptics), we need to supply technical requirements. ("bright
    lights" isn't sufficient, there needs to be a measurable
    requirement)

• (slide 8) Firmware update threat vectors

  • ekr: firmware update mechanisms should not allow third parties
    to violate these protection mechanisms

• (slide 9) Printing non-SN unique identifiers

  • Nick Doty: if someone finds a device like this and smashes it
    with their boot, how could they then identify it? I'm concerned
    about having it be only electronic.
  • ekr: the devices all have a unique identifier, even if it drives
    the published rotating identifiers. You want the radio
    identifier to avoid being identified over time by networks of
    radio receivers.
  • dkg: rotate the radio beacon; leave the static printed
    identifier (maybe write it on the internals of the device as
    well)
  • Andrew Campling: agree that we can have the static ID on the
    device.

• (slide 10) Add NFC requirements section

  • dkg: wording is confusing for those of us who don't understand
    NFC

draft-ietf-dult-threat-model (Maggie Delano)

• Slide on Scope

  • Brent: "easily-concealable" part might be edited
  • dkg: not sure what the word "consumer" does for us there.
  • Brent: why "broadcast"? what about a device with GPS and LTE?
  • Sean: it's ok to put "bluetooth" in there explicitly for now

• Slide on out-of-scope

• Slide on Design considerations

• Slide on Techncial Specifications

• Slide on Proposed Attacks in Scope

  • dkg: i don't understand how non-compliant tags are "in scope"
    without putting the universe in scope
  • ekr: we want to document the gaps in the system, and what the
    tradeoffs are when parts of it don't work
  • Brent: non-compliant tags are in scope specifically so they can
    be detected and excluded from the tracking networks.
  • Siddika: comparing speaker-disabled vs. altered-firmware. lots
    of youtube videos on removing speaker. perhaps we want things in
    scope when they're doable with minimal technical skill/knowledge

• Slide on Proposed Tracking Scenarios in Scope

• Slide on Proposed Requirements

  • ekr: putting numbers in here is just picking values in a vaccum.
    we should see what we can do, but i wouldn't aim for something
    that is unhittable.
  • Maggie: knowing how we measure the metrics lets us compare
    alternatives
  • dkg: false positive/negative rate depends on the built
    environment around people, differs depending on population of
    other devices, etc. I'm fine with aiming for concrete numbers
    for duration of scanning.
  • Brent: numbers are easier to measure if we talk about a single
    accessory.
    I'm fine with peace of mind for remote disabling, but if you
    can't find the device, then there's no evidence left to
    consider.
  • Nick: criteria for assessment would be good to have.
  • ekr: it's not clear from the radio environment whether unwanted
    tracking is taking place.
    I'm leery of disabling the unwanted tracker remotely use case.
    consider putting your paired device in airplane mode -- then
    someone could disable your trackers.
  • Bob Hinden: i flew here on a long plane ride. i have two
    trackers on me. if enveryone else around me has the same thing,
    it's all going to look like we're tracking each other. this
    seems really hard.
  • Maggie: i think this is an argument for customizability

• Slide on Open Questions

  • Maggie: I think i can make a table about assessment parameters