Subject: [apps-discuss] Private fields in Webfinger output (was Re: webfinger privacy question/suggestion)

From: Evan Prodromou <[email-masked]>
Date: Thu, 01 Nov 2012 11:27:23 -0400

On 12-10-31 05:38 PM, James M Snell wrote:
>
>
>
> The critical points here are A) a user should never be surprised about 
> what data a particular service provider is offering up about them and 
> B) a user should never be surprised about which services are offering 
> up data about them.

I think we're on the same page. An example from Twitter (note: 
twitter.com doesn't yet support Webfinger). My account there 
<https://twitter.com/evanpro> has these scalar fields:

  * nickname - identifier, public
  * full name - public
  * location - self-reported, more like 'hometown'; *not* current
    lat/lon, public
  * bio - short self-description, public
  * homepage - public
  * email address - for alerts, private
  * telephone number - for SMS, private

All the "public" fields are visible to unauthenticated users on my 
profile page; I can't selectively share them. The only way to hide them 
is to delete them entirely.

"Private" fields are visible only to me and Twitter; I can't share them 
at all, with anyone, even if I want to.

Given this app profile, I'd say that:

  * full name, location, bio, and homepage should be included in
    Webfinger output
  * there is no need for the user to grant additional permissions,
    opt-in or opt-out, to the service to include public data in the
    Webfinger output
  * email address and telephone number should not be included in
    Webfinger output
  * functional endpoints like OAuth request-token endpoint should be
    included
  * derived data like last login IP, exact-ish location (derived from
    IP), workplace (derived from email address), should not be included

Is that about what you're thinking?

I think there's a subtle spectrum of opinions on the public profile fields.

  * The service should never share any of the public profile fields.
  * The service should only share the public profile fields if the user
    opts in.
  * The service should only share the public profile fields if the user
    has not opted out.
  * The service should only share the public profile fields if it knows
    there's a client that's going to use it.
  * The service should share all public profile fields, in hopes that
    someone will find it useful.

I'm probably on the end where if it's on the public profile page, it 
should be in the Webfinger output. I would disagree with the concept 
that, since Webfinger output is marginally easier to parse than the HTML 
of the profile page, it's dangerous to have the same data in JRD as in 
the HTML.

For the private fields, I think there are some more interesting examples 
from LinkedIn or Facebook where users can selectively share some 
personal data like email address and phone numbers with other users, but 
it'd probably be good for us to worry about that later.

-Evan

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 01 Nov 2012 11:55:14 -0400

On 12-10-31 05:38 PM, James M Snell wrote:
>
>
>
>
> Very straightforward really... Org A wishes to access information 
> about Org B's users without all the parties in between knowing what's 
> being requested. For example... IBM has their SmartCloud for Social 
> Business service.. which is essentially a multi-tenant hosted version 
> of our Connections product. We have third party ISV's that integrate 
> with that product and provide extended services to our customers. This 
> is just an example, but what I want is to be able to provide secure 
> Webfinger services so that those ISV's can access non-public 
> information about specific users. It's the same basic WF protocol but 
> with an added layer of security that the privacy and confidentiality 
> of potentially sensitive business relationships.
>
Let me see if I've got this. Let's say that a client wants to get 
Webfinger information about [email-masked] . They make an 
unauthenticated request like:

     GET /.well-known/host-meta.json?resource=acct:[email-masked]
     Host: company.example

which generates a result like:

     HTTP/1.1 200 OK
     Content-Type: application/json

     {
	"subject": "acct:[email-masked]",
         "links": [
		"rel": "http://webfinger.net/rel/profile-page",
		"href": "http://company.example/profiles/3008"
         ]
     }

A malicious third-party attacker, observing this exchange, would know 
that an account "[email-masked]" exists and is valid, since the 
response came back with status code 200.

They could then:

 1. Make additional future requests to Webfinger about this account.
 2. Try using the account ID as an email address (or XMPP address) and
    send it spam.

Is that a fair characterization of the problem?

There's also the information in the Webfinger results themselves. 
Presumably the attacker could get this public information again (the 
request wasn't authenticated, remember), but here they got it 
"silently", and didn't have to make their own request. That's a wee bit 
more advantage.

It sounds like the ways we can mitigate the danger are:

  * Use HTTPS for the request. This would prevent (more or less?)
    third-party observers from seeing any of this request information.
  * Use an obfuscated identifier without authentication. This would
    prevent the attacker from re-using the identifier for email or XMPP,
    but they could still replay the request later.
  * Use an obfuscated identifier with authentication, and the identifier
    is tied to the requester. This would prevent both re-use for SMTP
    and replay over Webfinger.

Is that about what you're asking for?

Personally, I think specifying a way to use obscured identifiers is more 
trouble than just using HTTPS. But I acknowledge that there are some 
serious difficulties with using HTTPS (cost of certificates, use on 
virtual hosting or multi-homed systems).

-Evan

---

From: SM <[email-masked]>
Date: Thu, 01 Nov 2012 09:07:35 -0700

Hi Paul,
At 12:13 31-10-2012, Paul E. Jones wrote:
>No, but it is an open standards process where anyone can contribute text.
>I've contributed text and I've tried to address the issues raised w.r.t.
>privacy.  If it is not sufficient, then I need to be told what to put in
>there.

Ok.

>I think we should address post making info available and accessing it.  How
>is this:
>
>     If one does not wish to share certain information with the world,
>     do not allow that information to be freely accessible through
>     WebFinger and do not use any service supporting WebFinger.
>
>That said, I do think it's going a bit far.  Following this logic, we should
>go back and revise the DNS specs, too, to say "if one does not want the
>world to know what one is accessing, do not use DNS."  It's the same issue,
>really.

I agree that it would be going a bit too far to 
add that text to the draft.  I don't think that it is the same issue for DNS.

>This can certainly be said of Google advertising, for example.  It can be
>said of any web user habits, your email exchanges with me, blog posts,
>comments on web sites, etc.  WebFinger is just one more service like so many
>others.  The only thing that is perhaps strikingly different is that with
>WebFinger, one is publishing information about themselves in a concentrated
>place.  So, rather than visiting my home page to get some contact info, one
>can query it via WebFinger in a nice automated way.  This can be abused, of
>course, but so can posting profile information in one's Facebook account.

This is a general comment.  It's not because the 
world is stupid that I have to be stupid.  The 
point of having security or privacy 
considerations is to "think about it".  Quoting a 
sentence from Phillip Hallam-Baker [1]:

   "Webfinger as currently designed is not going 
to make the situation any worse,
    but it isn't going to make it better either."

People can be realistic and argue that privacy is 
not worth the bother as it is not going to make 
any difference.  I doubt that Google or Facebook 
are going to use that argument in their responses 
to the European Union.   Quoting the Managing Director of Facebook:

   "The recent audit by the Irish DPC recognized that Facebook’s
    current privacy practices go far beyond the existing legal
    requirements, which proves how seriously we take the issue."

   "‘Privacy by design’ is an important principle which is recognized
    in the Commission’s proposal.  It is also one of the core principles
    of Facebook's privacy programme:"

It is convenient to have a protocol, e.g. 
WebFinger, aggregate data and provide the 
information in a nice automated way.  As 
mentioned above, there is a risk for abuse.  I 
doubt that the risk can be eliminated.  Whether 
the risk can be mitigated is still debatable.  I 
referred to "correlation" in 
draft-iab-privacy-considerations-04 and asked 
whether it was an issue [3].  If the answer of 
the three authors of draft-ietf-appsawg-webfinger-02 is, for example:

  We tried to address the issue.  If the text is 
not adequate we need to be told
  what to add

I can understand that.  if the answer is:

  We are writing a technical specification and 
not a treatise about social networks

I can understand that too.  If the answer is:

   "WebFinger is just one more service like so many others."

I don't find it a convincing argument.  Even 
though it may not be the intent the argument 
comes out as "we don't want to be bothered with 
that or we do not want to do the work".

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07701.html
2. 
http://www.europarl.europa.eu/document/activities/cont/201210/20121008ATT53182/20121008ATT53182EN.pdf
3. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg07697.html

---

From: Evan Prodromou <[email-masked]>
Date: Thu, 01 Nov 2012 12:19:00 -0400

On 12-11-01 11:55 AM, Evan Prodromou wrote:
>> with that product and provide extended services to our customers. 
>> This is just an example, but what I want is to be able to provide 
>> secure Webfinger services so that those ISV's can access non-public 
> [...]
> that an account "[email-masked]" exists and is valid, since 
> the response came back with status code 200.
Actually, re-reading your description, it sounds like I might have 
mischaracterized the problem you're trying solve. You want it "so that 
those ISV's can access non-public information about specific users."

I think that you could do this pretty well just using one of several 
HTTP authentication mechanisms (OAuth, Basic, Digest, client certs, 
...). ISVs provision credentials out-of-band and then use those 
credentials in the Webfinger request to get more information.

-Evan

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 1 Nov 2012 13:40:36 -0400

On Wed, Oct 31, 2012 at 10:39 PM, William Mills <[email-masked]> wrote:
> While I agree with the privacy language and drive toward being completely
> aware of this I think it's unrealistic to put too much verbiage in on what
> would be a company terms of service or privacy policy.

+1, a protocol should not come with a terms of service.

>
> ________________________________
> From: James M Snell <[email-masked]>
> To: Paul E. Jones <[email-masked]>
> Cc: IETF Apps Discuss <[email-masked]>
> Sent: Wednesday, October 31, 2012 2:56 PM
>
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>
>
> On Wed, Oct 31, 2012 at 2:38 PM, Paul E. Jones <[email-masked]>
> wrote:
>
> James,
>
> HTTPS is recommended and shown throughout the document.  We do not say TLS,
> as HTTPS implies that.
>
>
> From the security considerations, I see...
>
> "Of particular importance is the recommended use of HTTPS to ensure that
> information is not modified during transit. Clients should verify that the
> certificate used on an HTTPS connection is valid."
>
> Why not make this a "SHOULD use HTTPS" (note the capitalized SHOULD) and
> provide a normative reference to TLS? Why not make use of TLS the default?
> Showing it in examples without a strong normative recommendation or
> requirement is a good way to have it ignored or supported as an
> afterthought.
>
>
>
> In the security section at the end of “Service providers and users…” how
> about this?
>
> Further, WebFinger servers MUST NOT be used to provide any personal
> information to any party unless authorized by the person whose information
> is being shared.
>
>
>
> Perhaps something along the lines of...
>
>   "Further, WebFinger servers MUST NOT be used to provide any personal
> information to any party unless explicitly or implicitly authorized by the
> person whose information is being shared. Implicit authorization can be
> determined by the users voluntary utilization of a service as defined by
> that service's relevant terms of use or published privacy policy."
>
> Would have to fiddle with the wording there but basically... if a user is
> voluntarily providing their information to a service that makes it know in
> advance what information is going to be provided via WebFinger (e.g. within
> a Terms of Service or Privacy Policy document) then we're good. Again, to
> reiterate the point I made in another note, a user should never be surprised
> what information is being shared and by whom.
>
>
> As a final paragraph in that section, how about this?
>
> Finally, a WebFinger server has no means of ensuring that information
> provided by a user is accurate.  Likewise, neither the server nor the client
> can be absolutely guaranteed that information has not been manipulated
> either at the server or along the communication path between the client and
> server.  Use of HTTPS helps to address some concerns with manipulation of
> information along the communication path, but it clearly cannot address
> issues where the server provided incorrect information, either due to being
> provided false information or due to malicious behavior on the part of the
> server administrator.  As with any information service available on the
> Internet, users should wary of information received from untrusted sources.
>
>
>
> That works.
>
> - James
>
>
> Paul
>
> From: James M Snell [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2012 12:32 PM
> To: Paul E. Jones
> Cc: IETF Apps Discuss; Hannes Tschofenig; SM
>
> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>
> Ordinarily I would provide a suggestion of alternative text but I've been
> tied up on a few other matters. That said, a few notes...
> The basic protocol itself is fine.. the way that the current resource
> parameter is defined, I could in theory use a uri scheme that allows me to
> hash the identifier without requiring changes to the basic protocol itself.
> That itself is not so much of a problem.
> What is a problem, however, is that you've mentioned a few times that TLS
> could provide the necessary privacy control but there does not appear to be
> any mention at all of TLS within the specification document. It really
> should be called out as a specific recommendation in the text.
> I also note that while you do cover some of the privacy issues in the
> security considerations, one point could stand to be made clearer: WebFinger
> should only be used to expose information the subject has explicitly opted
> in to be shared. Or put another way, WebFinger MUST NOT be used to provide
> information to any party the subject has not explicitly authorized. This is
> loosely implied by the current text but, unless I missed it, you never just
> come out and say it.
> A couple other points that come to mind when re-reading the security
> considerations...
> 1. There is nothing said about the validity and authenticity of the data
> returned. There does not have to be an exhaustive discussion on this matter,
> of course, but currently the protocol makes no guarantees and provides no
> mechanisms for assuring that the information returned for a given user is
> authentic, authoritative or valid in any way. It should at least be noted
> that such mechanisms are out of the scope of the WebFinger protocol.
> 2. A cryptographic hashed identifier could help prevent correlation style
> breaches in privacy if the hash is generated based on a shared secret key
> tied to the requesters authenticated identity. That is, if a WebFinger
> server requires authentication to request data, the requester can generate
> an hmac, for instance, using a shared secret key and specify that within the
> URI request. Used in combination with TLS, for example, this would provide a
> reasonable assurance of privacy between the requester and the service
> provider, keeping prying eyes in the middle from knowing whose information
> is being requested. Again, it is possible to do with currently without any
> changes to the WF protocol as defined so no normative changes would be
> necessary, but it might be worthwhile to draw out as an informative example.
> - James
> On Oct 30, 2012 5:48 PM, "Paul E. Jones" <[email-masked]> wrote:
> That's not an entirely true statement.  See:
> http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-02#section-11
>
> Question is whether that is sufficient.  Thus far, I've not received any
> additional text.
>
> Paul
>
>> -----Original Message-----
>> From: [email-masked] [mailto:apps-discuss-
>> [email-masked]] On Behalf Of SM
>> Sent: Tuesday, October 30, 2012 1:19 PM
>> To: Hannes Tschofenig
>> Cc: [email-masked]
>> Subject: Re: [apps-discuss] webfinger privacy question/suggestion
>>
>> At 03:16 30-10-2012, Hannes Tschofenig wrote:
>> >Have a look at: http://tools.ietf.org/html/draft-iab-privacy-
>> considerations-04
>>
>> Hmm, that draft was mentioned several months ago [1].
>>
>> >I have raised these privacy issues already last year. My comments got
>> ignored.
>>
>> The following question was asked around 11 months ago [2]:
>>
>>    "What are you planning to do to ensure the draft properly addresses
>>     security, privacy, and netiquette issues?"
>>
>> The current plan seems to be: do nothing.
>>
>> Regards,
>> -sm
>>
>> 1. http://www.ietf.org/mail-archive/web/apps-
>> discuss/current/msg04747.html
>> 2. http://www.ietf.org/mail-archive/web/apps-
>> discuss/current/msg03804.html
>>
>> _______________________________________________
>> apps-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

-- 
Joe Gregorio        http://bitworking.org