LDN High-level security review

[nickrmc83]

Hi,

We've (Thales E-Security) done a brief and informal high-level security review of the current LDN draft (26 July 2016 version). Looks mostly OK with a few clarifications we thought would be useful.

Let me know if it helps

Thanks

Nick

TeS-W3CLinkedDataNotificationsHigh-LevelSecurityReview-271016-0849-122.pdf

[rhiaro]

Thanks Nick! We appreciate the time you've taken to read through this. You've raised some interesting points. The last one I would like to quickly address now, and I'll go back through the others later.

I think a key worry as an end user would be spam

The section on sender verification is actually intended to address the receiver's knowledge that a message was sent by who says they sent it. Spam is addressed in Preventing Abuse, where we suggest to introduce constraints on the content of the notification. This doesn't solve the problem entirely, as if a spammer can determine the exact constraints being imposed by the receiver they can craft a message to match, but it raises the bar. Similar to email spam filters.

[csarven]

Nick, thank you very much for your review.

Though AuthN/Z are mentioned in respect to the sending and consuming of messages there's no mention of that during discovery. This could open a fishing attack whereby a resource linked to an inbox could be discovered without the consent of the owner. An example case could be a social network site that displays public information about the user to all. Without AuthZ'ing the consumers of this information the contact details (the linked data) for a user would be able to be harvested without the consent of the user.

Doesn't it go without saying that if a resource (the target) is accessible without authorization then it is being made available for public read? This is very much like putting up an email address in a web document. Naturally email harvesters discover it.

[rhiaro]

There's very little information around error codes. Many "return appropriate 4xx". There's a worry that this would open up an implicit discovery path if errors are not ordered. For example, if a malicious Sender was trying to ascertain if a particular entity had an inbox at a specific service provider, the Sender could simply try and send requests to Inboxes of their choice. Now if sending a message required an AuthZ token (let's assume our malicious sender doesn't have one or it's invalid) but our receiving web-service firstly checked whether an inbox exists before the AuthX details and returned a "404 Not Found" when no inbox exists or "401 unauthorised" when it does, the Sender can ascertain valid inboxes with out successfully AuthZ'ing.

We could perhaps add a section along the lines of:

5.7 Authenticated inboxes

If a receiver expects senders or consumers to authenticate, it SHOULD check the validity of their credentials before returning any other data, including other error codes. For example, the receiver shouldn't first check for the existence of the inbox and return 404 Not Found if the requester has not been verified.

[csarven]

I don't see any explicit "use HTTPS" recommendation. Probably implied.

I think this is orthogonal to the spec. Neither is it the case that the vocabulary term (ldp:inbox) must be resolved through HTTPS.

Requiring retrieval of the notification from the sender is more promising. A few observations:

• retrieving the notification immediately it is received doesn't help much - the spammer only has to maintain a working source address for a few milliseconds.
• retrieving the notification just before it is read would probably help (since the spammer has to keep its URI available for an extended period) - but at the cost of introducing user-visible delays and exposing information about the user's reading behavior to senders.

This is the same issue that large email providers face i.e. spam filtering.

These are all valid observations. They have varying degree of usefulness, and certainly not bullet-proof. Is there a particular issue here that's specific to LDN's mechanism that's not otherwise the same if a sender is allowed (by whatever criteria that's fulfilled) to POST?

[nickrmc83]

Doesn't it go without saying that if a resource (the target) is accessible without authorization then it is being made available for public read? This is very much like putting up an email address in a web document. Naturally email harvesters discover it.

Yes it does. The review is highlighting another use case notably disclosure of notification end-point by authorization only. We expected that the discovery end-point is likely controlled by a 3rd-party that the resource owner had previously made arrangements with. We expected a use case where the RO negotiated a policy with the discovery agent whereby their digital identity would only be disclosed based on some rules around the party discovering the RO's inbox. Hence the need to AuthN the discoverer in order for the discovery agent to disclose the RO's identity. This use case may be out of scope for any initial specification.

5.7 Authenticated inboxes
If a receiver expects senders or consumers to authenticate, it SHOULD check the validity of their credentials before returning any other data, including other error codes. For example, the receiver shouldn't first check for the existence of the inbox and return 404 Not Found if the requester has not been verified.

Yes something along these lines is much clearer and is less implicit from a security PoV.

I think this is orthogonal to the spec. Neither is it the case that the vocabulary term (ldp:inbox) must be resolved through HTTPS.

Yes agreed. If you do worry about AuthZ disclosure then a recommendation to use HTTPS would be more valid in that scenario though it should also be mandated when there's mention of use of any AuthX token else the token is available in the clear.

These are all valid observations. They have varying degree of usefulness, and certainly not bullet-proof. Is there a particular issue here that's specific to LDN's mechanism that's not otherwise the same if a sender is allowed (by whatever criteria that's fulfilled) to POST?

These were merely observations not really answers.

[rhiaro]

@nickrmc83, I added the authenticated inboxes section, with the paragraph I drafted above, plus a one-liner about using HTTPS with tokens. Is that enough for you to be happy closing this issue, or do we need to discuss further the endpoint disclosure?

[nickrmc83]

@rhiaro I think what you added is excellent. Restricted endpoint disclosure can be treated as a use case that's outside of the current specification. All I would say is that I would expect AuthZ discovery to be required for many discovery providers so that they can be compliant with governing regulatory bodies. One example is the EU's new General Data Protection Regulation (GDPR) (I'm not an expert by any means but similar laws apply across much of the world) which puts expectations and restrictions on the release of personally identifiable information with hefty fines for those who are non-compliant. In the case of GDPR indirect identity may include things such as IP addresses or cookie strings so I believe a discovered inbox would fall into this category (I'm not a lawyer).

As I say this can be a use case that's differed until JIT so with the changes you've made I am happy for you to close this issue :)

[rhiaro]

Excellent, thanks! I'll keep in mind the cases you've mentioned and we'll particularly look out for related things coming up while we're in CR, and we'll revisit if necessary