Subject: Re: [Model-t] linkability

From: Robin Wilton <[email-masked]>
Date: Wed, 8 Jan 2020 12:40:31 +0000

> 
> From: Eric Rescorla <[email-masked]>
> Subject: Re: [Model-t] A couple of questions from our discussion in Singapore
> Date: 15 December 2019 at 23:51:37 GMT
> To: Jari Arkko <[email-masked]>
> Cc: [email-masked]
> 
> 
> 
> 
> On Sun, Dec 15, 2019 at 4:34 AM Jari Arkko <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I’m trying to update our draft to cover various different issues. There were a couple of things that we discussed in Singapore and earlier but I can’t quite recall what they exactly were:
> 
> * I think Melinda brought up a point about decentralised apps and source of trust in them. What was that exactly about?
> 
> * Martin brought up a point about how some level of trust is needed for any system. Could you expand on that so that I would understand the issue?
> 
> * Dkg and Ekr mentioned linkability at the summer SAAG meeting. I wasn’t sure how that is related to the issues we’re discussion, can someone enlighten me?
> 
> It's been so long that I don't remember, but linkability seems like a pretty serious privacy issue. Indeed, it's the basis of Web tracking.
> 
> -Ekr

I think it was just a relatively high-level observation that linkability, as a privacy risk, was not addressed when the original threat model was being compiled, and that it would merit inclusion in any revised version (or, at least, in the discussion of what a revised version should cover).

HTH,
Robin

> 
> 
> Jari
> 
> 
> --
> Model-t mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.iab.org/mailman/listinfo/model-t <https://www.iab.org/mailman/listinfo/model-t>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Jan 2020 12:55:21 +0000

On 08/01/2020 12:40, Robin Wilton wrote:
> I think it was just a relatively high-level observation that
> linkability, as a privacy risk, was not addressed when the original
> threat model was being compiled, and that it would merit inclusion in
> any revised version (or, at least, in the discussion of what a
> revised version should cover).
Good point. That is discussed in 6973 [1] in various places
but (with a quick scan) I didn't see a crisp bit of text
one could offer to protocol designers as guidance for what
to do about linkability. (I.e. a snippet of text one could
imaging as a part of a BCP72 update.)

If anyone has suggested text be great to see that...

Cheers,
S.

[1] https://tools.ietf.org/html/rfc6973

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jan 2020 04:54:51 -0800

On Wed, Jan 8, 2020 at 4:40 AM Robin Wilton <[email-masked]> wrote:

>
>
>
> *From: *Eric Rescorla <[email-masked]>
> *Subject: **Re: [Model-t] A couple of questions from our discussion in
> Singapore*
> *Date: *15 December 2019 at 23:51:37 GMT
> *To: *Jari Arkko <[email-masked]>
> *Cc: [email-masked]
>
>
>
>
> On Sun, Dec 15, 2019 at 4:34 AM Jari Arkko <[email-masked]> wrote:
>
>>
>> I’m trying to update our draft to cover various different issues. There
>> were a couple of things that we discussed in Singapore and earlier but I
>> can’t quite recall what they exactly were:
>>
>> * I think Melinda brought up a point about decentralised apps and source
>> of trust in them. What was that exactly about?
>>
>> * Martin brought up a point about how some level of trust is needed for
>> any system. Could you expand on that so that I would understand the issue?
>>
>> * Dkg and Ekr mentioned linkability at the summer SAAG meeting. I wasn’t
>> sure how that is related to the issues we’re discussion, can someone
>> enlighten me?
>>
>
> It's been so long that I don't remember, but linkability seems like a
> pretty serious privacy issue. Indeed, it's the basis of Web tracking.
>
> -Ekr
>
>
> I think it was just a relatively high-level observation that linkability,
> as a privacy risk, was not addressed when the original threat model was
> being compiled, and that it would merit inclusion in any revised version
> (or, at least, in the discussion of what a revised version should cover).
>

3552 doesn't really cover privacy much at all.

-Ekr

> HTH,
> Robin
>
>
>
>
>> Jari
>>
>>
>> --
>> Model-t mailing list
>> [email-masked]
>> https://www.iab.org/mailman/listinfo/model-t
>>
>
> --
> Model-t mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t
>

---

From: Robin Wilton <[email-masked]>
Date: Wed, 8 Jan 2020 13:58:35 +0000

Thanks Ekr -

Between your reply (re 3552) and Stephen’s (re 6973), it seems to me that we need a way to ensure that linkability is adequately reflected in both places, but without duplicating or giving conflicting guidance. Here’s a suggested approach.

Looking first at 6973, I see that Marit Hansen was one of the authors. Marit was also co-author of probably the seminal paper on linkability, with Andreas Pfitzmann
( https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf <https://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.34.pdf> ), so her contribution to 6973 is highly likely to have been guided by concerns about linkability as a privacy threat.

Section 5.2.1 of 6973 ("Correlation <https://datatracker.ietf.org/doc/html/rfc6973#section-5.2.1>”) is probably the closest that RFC comes to describing linkability as an issue, particularly this paragraph:

>   Correlation is closely related to identification.  Internet protocols
>    can facilitate correlation by allowing individuals' activities to be
>    tracked and combined over time.  The use of persistent or
>    infrequently replaced identifiers at any layer of the stack can
>    facilitate correlation.  For example, an initiator's persistent use
>    of the same device ID, certificate, or email address across multiple
>    interactions could allow recipients (and observers) to correlate all
>    of the initiator's communications over time.

6973 goes on to recommend data minimisation as a possible mitigation, but a pretty qualified one. I think this principle also surfaced in the discussions around RFC7258 (Pervasive Monitoring Is An Attack), but again, with qualifications:

>  IETF standards already provide mechanisms to protect Internet
>    communications and there are guidelines [RFC3552 <https://tools.ietf.org/html/rfc3552>] for applying these
>    in protocol design.  But those standards generally do not address PM,
>    the confidentiality of protocol metadata, countering traffic
>    analysis, or data minimisation.  In all cases, there will remain some
>    privacy-relevant information that is inevitably disclosed by
>    protocols.

IIRC, one approach discussed was to ensure that the data/metadata required by a given layer of the protocol stack should only be accessible to the nodes responsible for implementing that layer… but of course, the semantics of data at the application layer may well mean that the user’s actions can be correlated/linked despite anything that happens further down the stack.

Bottom line: 6973 is relatively recent (2013) and addresses correlation to a certain extent, but it may be hard to go further with practical advice for protocol designers. One option might be to look more closely at context. Nissenbaum’s paper <https://crypto.stanford.edu/portia/papers/RevnissenbaumDTP31.pdf> on Privacy as Contextual Integrity is now 15+ years old, but still meaningful. We could encourage protocol designers to consider the (usually implicit) context in which potentially linkable data items are being used, and what measures might be taken to prevent (or track) their use outside that context.

Looking next at 3552; you’re right, it doesn’t mention privacy as such - and since it’s the Security Considerations guidance, and Privacy Considerations giudance has its own home elsewhere, that’s fine. However, “context” might provide a bridge between the two: if you see privacy as contextual integrity (i.e. that data disclosed in one context shouldn’t show up in another one), then  violating contextual integrity implies a violation of confidentiality: you’re taking data that was disclosed to one party, and making it accessible to another.

So perhaps 3552 can briefly note that breaking a confidentiality mechanism is almost certainly a context/privacy violation, and then hand off to 6973 for the detail.

Hope this helps,
Robin