Chairs: Sean Turner & Erica Olsen
Note-taker(s): Mike Ounsworth & Daniel Kahn Gillmor
Presenting: Maggie Delano & Jessie Lowell
Threat modelling is often familiar to those working in tech, but
thinking through gender-based violence threats may be outside the usual
things that tech makers think about.
(side-discussion from chat) -- Bob Moskowitz: are we considering
alternate threat landscapes over transports other than Bluetooth? ex.:
THREAD over 802.15.4?
Sean Turner (ST) / Eric Rescorla (ekr): No, the charter is specific to
bluetooth trackers, which are a specific category of device.
ekr (side-discussion from chat): in addition to asking BT tracker
manufacturers to build DULT-protocol
compliant devices, there are also devices with after-market
modifications, or devices from non-compliant vendors. We can work with
phone manufacturers to make it difficult for these non-conformant
trackers to work within these networks.
From chat (audio died): Jesse: To finish up what I was trying to say, I
know that these can seem like edge cases because they involve many
barriers and many angles. However, the elements are drawn from
situations I've encountered and heard from the field. It is more common
than not for survivors' situations vis a vis tech and family
arrangements to be complicated, and for there to be barriers.
Juan-Calros Zuniga: I have worked on privacy concerns around changing
MAC addresses and logging who has changed a MAC address.
ST: our charter scopes us to Bluetooth.
Tommy Pauly: Our charter does allow us to talk about link layers other
than Bluetooth, but we are restricted to location trackers.
Kris Shrishak: We should reach out to participants from other parts of
the world, especially the global south, because the cultural enviroment
might be very different.
Nalini: I second the "global south" comment. I work a lot in India where
devices like AirTags are prohibitively expensive, so the tracking risks
come from different sources.
draft-detecting-unwanted-location-trackers
Architecture diagram can be found here:
https://github.com/rdanyliw/ietf-dult/issues/1
Tommy Pauly & Brent Ledvina: --the note taker did not understand the
technical details ... something to do with coordinating with the
Bluetooth SIG for new TLV tags? --
Presenting: Brent Ledvina (Apple)
Rohan Mahy: Which usecases (from the first presentation) would map to
which document?
Brent: Really, that's document #4.
ekr: I volunteer to help with document 1.
Christine Fossaceca: there exist privacy preserving technologies that
allow obfuscating the identity of the device. We should leverage those.
I am happy to volunteer to as an author for document 1.
Brent: concerned that non-technical communities can find the bar for
participation daunting. Any thoughts on how to structure the documents
so that there are entry points that don't have super steep technical
language.
Sean: we'll look at creating some non-I-D means of assembling content,
including images, etc.
Erica: we are actively doing outreach as well, and that could help with
document #4
Mallory Knodel: in the HRPC there is a document on the broader issue of
tech-assisted intimate partner violence which might be overlapping here.
We really do need to engage outside the usual IETF bubble without
distracting from the goal of making the standardization happen. We need
to make sure the standards and mechanisms are accessible to the people
in the field doing the work.
https://datatracker.ietf.org/doc/draft-irtf-hrpc-ipvc/
Nick Doty: doing outreach in this direction is something we don't have a
lot of experience of in the IETF. W3C sometimes does a "explainer"
document. Maybe we should try plain language explanations when new
versions are released?
Sean: I am not sure that the IETF will do a good job of that. I am
hoping that some of the participating companies with a broader marketing
arm than the IETF can help with dissemination of this information to the
public.
Maggie: can we talk about dependencies between documents? it's hard to
figure out some things when others are absent, but we also don't want to
stall work.
Sean: we do it many different ways in the IETF. Sometimes we use full
waterfall, but then that doesn't always work, and we have to go back and
revise earlier versions. Let's try to start them all as early as
possible and make sure that they stay in sync. We need at least a draft
of document 4 toward the beginning.
ekr: we already have a bunch of stuff that's already written, and
existing deployments that are out there. two ways to improve the specs:
maybe we should fix bad things that are done in the specs; and maybe we
should find the insufficiencies, and try to bridge those gaps. I suspect
the current structure is going to be mostly intact. But i don't think
there is a dearth of work to do in the short term.
Tommy Pauly: I agree with what I've heard so far about document
ordering: threat model needs to come first. We can look at other IETF
work (ex.: QUIC) where someone came in with a working product, and then
we evolved and improved it to be much more robust but substantially
different from the starting thing. We could run with the same model
here: do incremental improvements on deployed DULT models.
SF: what if each revision of the draft costs thousands of $?
DKG: I am concerned about questions about evolution of this protocol.
Rolling out changes to tracker firmware and to detector devices (the
non-phone ones at least) may not be able to evolve quickly. This does
not smell the same as QUIC where all things involved were experimental
browsers and servers that could be easily iterated.
Jessie Lowell: (comment at mic mirrors comment from chat, copied here):
Jessie Lowell: Yes I agree that the scenarios are always a work in
progress - the three I wrote were meant as a starting point to introduce
some different common angles/threats/constraints, rather than
all-inclusive. In the data privacy world you have tools like LINDDUN and
MAP (Models of Applied Privacy) that can be useful for persona-based
threat modeling, and those are adapted from similar concepts in
traditional cybersecurity.
Jessie Lowell: Those tools don't precisely map onto this domain, I don't
think, but the basic concepts of persona modeling, security cards, and
so on, are pretty intuitive to me as a starting point for thinking about
threat modeling in the adaptable and maybe nontraditional ways needed
here.
Tommy: Responding to DKG: clarifying my comments: I meant iteration of
devices and trackers in test labs, not the in-field devices and tracking
networks, who will probably continue with whatever proprietary thing
they have today until IETF declares DULT 1.0.
Brent: I echo DKG: there can be extremely long tails of firmware update
timelines if a device is away from its Owner Device for a long period of
time. Let's not plan to iterate the DULT protocol in production. Finder
networks value offering is proportinal to the number of devices
participating. There could be many years of delay from when we update
the finder devices to when the network returns to the original capacity
for the base use case of finding my stuff.