HRPC @ IETF 113

1. Introduction

Welcoming Sofia as co-chair

Notewell

Overview of hrpc by Mallory

• scope of work; analysis of protocols
• overview of hrpc outputs (RFCs, papers in academic journals/conferences, a movie, other media, etc.)
• taking guidelines to review work

2. Privacy, security and surevillance in 5G (John Preuß Mattsson)

update to previous presentation at hrpc

3GPP releases and generations

overview of 3GPP generations and planned releases till 2024
2G and 3G to be phased out in most regions

False base stations

ideas presented in previous presentation were approved.
in the long-term, things are not perfect.
encryption of SUCI is optional (so still not perfect). but should be used in lots of regions of the world

mobile country code and mobile network code is still not encrypted.
consequence: users in roaming can be easily identified

interop with legacy. the vulns still exist in 2G, 3G and 4G.
not seen in practice, but one could in theory jam all 5G signal to force someone to connect to 3G/4G.

media reports re russia tracking foreign users

New studies on privacy of identifiers in 5G and 6G

3GPP Rel-18 ongoing study

looking at privacy of identifiers
possible attacks using combining identifiers and time information (or using sort of machine learning)
things should be fixed in 6G based on these results

Identifiers for 6G network nodes

study to inform design goal: privacy-sensistive information to be transferred on needs-basis and deleted when not needed

Service-based architecture and interconnect security

ideas presented in last meeting mostly all approved
TLS 1.3 to be mostly used inside networks (within the network)

Mitigating the compromise of long-term keys

Ericcson had proposed using Diffie-Hellman, declined
"great SIM heist"
Snowden leaks had info that there was compromise of SIM encryption

there was a proposed study to how 5G could fix this
but it objected to by France, UK and US. support from Sweden, Finland, Germany and US companies
no technical reasons given

Access authentication in 5G

list of methods for primary (access)
and secondary (user connections going out of mobile network operator) authentication in 5G networks
forward secrecy supported by newer TLS versions

of course, forward secrecy is not enough.
forward secrecy protects in one-direction (secures exchanges BEFORE the compromise)
post-compromise security can be achieved with EC(DHE)
doing both forward secrecy and post-compromise is best practice, and aligns with zero-trust principles. see RFC7624.

France also recommended for IPSec to rerun ephemeral at least every hour/after 100GB transfer. this should be considered for all flows though.

RFC 8446. psk_ke does not offer client identity protection and forward secrecy.
IETF needs to be better at labeling weak mechanisms as "NOT RECOMMENDED"
these things have practical impact, at least at 3GPP.
eg. 3GPP has forbidden cipher suites without forward secrecy in (D)TLS 1.2. allowed again in (D)TLS 1.3 however.

authenticated encryption in user plane

2G: control and user plane both used unauthenticated encryption
3G and 4G: control plane used authenticated encryption, user plane used unauthenticated encryption
5G onward: full user plane authentication is mandatory to implement (but optional to use?)

3GPP/GSMA algorithms

weak security in 2G and older.

user consent in mobile networks

inspired by GDPR and other privacy laws, which have strict requirements about getting consent before collecting/storing/using data.

TR 33.867 gives recommendations about this.

Q&A

Niels ten Oever: What is the 3gpp mailing list for PFS?
John:
SA3 mailing list. you need to be a member of 3gpp to subscribe. mail archive is openly accessible.
some things are discussed in face-to-face meetings. sometimes meetings don't capture all details. but you can find the companies that supported/objected to a proposal.

Niels: Could you reflect on the privacy and human rights implications of private 5G networks and edge computing in 5G networks?
John:
private 5G networks will only be used for industry. most devices on the network will be IoT devices. so may not have a lot of human rights/privacy implications. implications will depend on the industry.
for edge computing, the risk is that more information is spread in more nodes at the edge, but there are proposals to have better security in storage. one suggestion is to use trusted enclaves.

Stephane Bortzmeyer: how can we find out how common certain algorithms are?
John:
don't think there are any public stats/info on what companies are using what using algorithms. for studies, they might do internal survey. that would be a useful resource for the public. eg. would be good to know how many operators have turned on SUCI encryption.

Mallory: what are pertinent WGs
John: focus on forward-secrecy and web in TLS 1.3. 3GPP started using TLS for long-term connections. need for constant improving of security and privacy in protocols. IETF is doing a great job, but there's still scope for more.

Coalition for Content Provenance and Authenticity (Jacobo Castellanos)

Witness.org is an org working for folks using media/video journalism. don't usually work in standards-setting orgs.

C2PA informed by our work on content provenance and authenticity

Provenance and Authenticity (P&A) infrastructure

tools/services/frameworks processing and presenting details about the source and history of digital assets. verifiable and tamper-evident.

About WITNESS

WITNESS works on authenticity infrastructure. we have advocated that such infrastructure should always be opt-in, recognising that people may not want it always (esp. for privacy concerns). there should be ways for sensitive info to be redacted in those circumstances.

From niche tools to infrastructure

the shift is being aided by the use by large companies and coalitions
how do we prevent prevent and mitigate harms in this shift

C2PA

C2PA creates technical standards to have an interoperable way for provenance and authentication

WITNESS is one contributing member among many companies and orgs

one specification has been published, are moving past design stage and 1.0 spec will be published soon

Specification

Imagine three actors.

Actor 1: takes picture.
tool creates manifest. includes metadata. hashed and signed.

Actor 2: edits image on Photoshop.
result is another manifest. hashed and signed.

Actor 3: publisher (say NYT)
result is another manifest. hashed and signed.

User can see ALL manifest, and so be aware of who has made changes and when.

(caveat: this is not for what is true/not true. it just gives verifiable information about changes, so users can make more informed decisions)

WITNESS objectives

prevent, mitigate harms
within the human rights framework
foster use, say how can journalists documenting videos of human rights abuses use it.

WITNESS is leading the harms modeling.
also helping draft guiding principles of the C2PA.
harms assessment should continue beyond spec v1.0

supporting creation of tools that are aimed for human rights defenders and journalists.

guiding principles of the C2PA

1. privacy (eg. spec must allow content creators to remove sensitive information). (eg. spec must not require identify of the person to be associated with the content)
2. accessibility + global audience
3. simplicity and reducing cost burden
4. preventing misuse

Harms modelling

1. identifying purposes and use cases
2. harm, misuse and abuse assessment
3. mitigation strategies

we started this from the design stage. now that it is being implemented, we're going from a potential harm modeling and analysis to a real one.

the asessment methodology includes:
* internal assessment (internal consultations and discussions, groups do consist of experts)
* external consultation (folks w/ diff tech/lived/practical/professional experience)

overview of results

1. denial of consequential services -- opportunity/economic loss
2. infringement of human rights -- dignity, liberty, privacy loss
3. erosion of social and democratic structures
4. risk of injury (emotional or physical)

(note that some are not direct harms, but risks may be exarcebated by use of C2PA tech)

spec and harms analysis are also available on the C2PA website.

example 1

say an activist inadvertently includes location data. and is later targeted.
reduction in anonymity and pseudonymity is one risk.
this relates to user experience (spec allows it, but UI/UX also should be clear).

example 2

social media companies could give more value to media that uses provenance and authenticity.

outputs of harms modeling

• informing specifications
• accompanying documents (UX guidance, explainers, etc.)
• non-tech response actions (governance and supporting diversity of use)

Q&A

Patrick (Ofcom): legacy media that does not have C2PA metadata, is this a "two tier" system making all older media obsolete?
Jacobo: we are certainly aware of this. what happens to people who legitimately do not want to use provenance infra.

Stephane Bortzmeyer: how do i ge the public key to check the signature? how can i be sure?
Jacobo: specs are tied to the use of certificate authorities that verify the signature. don't have precise answer about keys right now.

Mallory: are there other SDOs/groups working on this, or impacted by this design? eg. ISO has imaging related groups
Jacobo: there are other groups.

Mallory: already seeing the CA discussions re Russia. does an entity need to be a part of the coalition to a CA-equivalent for C2PA.
Jacobo: the specs have a section on "trust lists". entities creating the manifests work with a group of CAs.
Mallory: actors may not act good faith, spec may want to address what kind of action can be taken against them.

Nick Doty (CDT): have you gotten any feedback about the associated explainers (which seem like a great idea to me)
Jacobo: not sure whether explainers are part of all SDOs. SDOs are not generally very representative, so creating an explainer was v important for WITNESS. it should be usable by a non-tech audience. some (positive) feedback.
Nick Doty:

draft-guidelines (Gurshabad Grover)

moved from last call to irtf review

Gurshabad: have addressed most of the feedback. requests for minor changes to attribution, but I don't think we have any serious objections to the current text, which advises against attribution because of conflicts with privacy/security.

next steps?

Colin Perkins: thanks for updates! re: remedy and attribution, clearly an area where it's been difficult to reach consensus in the group. as a protocol designer, I struggle to see what that section means. if the group does have consensus that this is the best it will get, that's fine.

Gurshabad: remedy and attribution are part of the human rights framework. so best to include it and discuss the tradeoffs. having an element in the protocol that includes attribution is overall against security, privacy, anonymity, pseudonymity. attribution is probably weighed against.

Colin: agree that you may be judging consensus correctly, but not sure what this means for the protocol designer. authors have a particular view on how to interpret rights. but for a non-humans-rights-expert, examples (not just national laws, but direct implications) would be useful to concretize

Gurshabad:

Mallory: attribution is present because of a right to remedy, that we should give people some accountability or way to address. when considering these rights in balance, individual attribution in the protocol could have an overreaching harm to everyone. so attribution is intended to be more minor (only instrumental to the right of remedy), which is why the text is shorter.

Colin: protocol designers who read this may not have the same background.

Mallory: next steps: re-review with Colin; other issues have been resolved.

Colin: I do have some technical comments to follow-up, but great improvement. will review carefully in the next few weeks.

Sofia: +1 for clarity of examples.

draft-association (Niels ten Oever)

authors (from academia, civil society)
celebrating a birthday now, 3 years since irtf document
changes since -07:
* removed some 8280 bits
* clearer abstract and definitions

next steps for -10:
* better connect the literaturAdded emphasis that document is about humane review with the case studies

Mallory: thanks to the group for reviews.
Nick: thanks for quick reviews. can work on the next steps w/ you. after these changes, next steps would be last call?
Mallory: two years ago, we redesigned the doc. things have flowed smoothly since then. so that should continue towards publication. let's take it to the list.

draft-giuliano-blocking-considerations (Lenny Giuliano)

Regional Internet Blocking Considerations - background

presented in intarea, some things may be interesting to hrpc

motivation has been recent discussions on blocking net connectivity for regions

just presents how that could happen

it's not a political/ethical opinion on blocking. it's not about blocking for security threats. more of a 'sanctions' lens.

we highlight well-known approaches for filtering/blocking and analyse their use for situations to implement regional blocking

Blocking techniques

• physical layer (disconnecting cables)
• routing layer (deepering, route filtering)
• packet layer (geoIP -- challenges)
• DNS (undelegating ccTLDs or other TLDs)

IETF folks may know about this already, more to educate policymakers

gaps in efficacy

May not meet goals of policymakers
eg. may want messages to go in and out of the region
may want certain parties in the region to coordinate

ASNs may appear in different regions (not always region bound)

decentralized infra may be mean that it may sometimes be impossible to disconnect a region

related work

• RFC7754: some overlapping themes, that's more on focused blocking.
• draft-censorship in PEARG

Q&A

Niels ten Oever: RFCs are not the best option for reaching the general audience. Work on draft-censorship has been ongoing for a while.

Stephane: what do you think of ISOC's position on this? disconnecting from the "internet" depends on what you're calling the "internet".
Lenny: how we are different is that we're not advocating one way or the other. but this doc is for who have a position and want to know the tech details.

Mallory: don't know if there's interest for continuing this work in the hrpc group, but discussion can continue of course on the list.

Eric Vyncke: Andrew Sullivan has published a paper on the political aspects.

Eliot Lear: need more discussion on goals (which ones are achievable, need to be crisper about those mechanisms). the field is fraught with intellectual landmines, thanks for creating this work. hope it can find the right home.

Ben Schwartz: change the intended audience to make it more useful. ID/RFC doesn't get the right audience. for a network operator, what are the considerations for when I say engage in depeering? what are the goals I achieve, not able to achieve that way.
Lenny: IETF should publish for the general public sometimes. all feedback welcome to the list/author emails.