search

stackevo / spudreq

Substrate Protocol for User Datagrams (SPUD) Requirements
0 stars 4 forks source link

PR on security semantics #13

Closed hardie closed 9 years ago

hardie commented 9 years ago

During the Prague side meeting, I took an action item to generate a pull request to describe the security semantic requirements. It's turned out to be harder than I thought ("don't be evil, and don't use SPUD for evil" didn't quite fly), so I'm throwing up a pull request I know isn't adequate in the hopes it will spur someone to improve it.

calvert commented 9 years ago

Hi Ted -

Let me see if I understand what you were trying for. I think I see two goals (beyond "don't be a tool of evil"):

(i) SPUD should not undermine the overlying protocol's security.

(ii) SPUD should not enable providers to extort metadata exposure from users.

But also we maybe need to figure out what is the "endpoint" here. Is it the application? Or might there be a policy interface that also has something to say -- e.g., supplying a preconfigured secret or credential that proves policy-compliance, to be presented to the corporate firewall. I think it may be hard to rule out the latter possibility.

Regarding (i): If the overlying protocol is well designed, seems like this should not be possible. But how about this: SPUD MUST NOT leak information from the OT payload; SPUD's behavior must be completely independent of the content of the SPUD payload regardless of whether it is encrypted or not.

Regarding (ii), how about:

SPUD is not intended to support in-band negotiation of policy with network elements, and should not provide mechanism to enable this. Any such negotiation (e.g., obtaining proof of policy-compliance in order to gain passage) MUST be conducted a priori and out of band.

In my view, it's OK for SPUD to carry an opaque token that proves policy-compliance; SPUD just needs to be agnostic about the policy and what policy-compliance reveals about the user. But I don't know if that will be enough to make some people happy.

Ken

On 5 Aug 2015, at 16:33, hardie notifications@github.com wrote:

During the Prague side meeting, I took an action item to generate a pull request to describe the security semantic requirements. It's turned out to be harder than I thought ("don't be evil, and don't use SPUD for evil" didn't quite fly), so I'm throwing up a pull request I know isn't adequate in the hopes it will spur someone to improve it.

You can view, comment on, or merge this pull request online at:

https://github.com/stackevo/spudreq/pull/13

Commit Summary

PR on security semantics File Changes

M draft-trammell-spud-req.md (5) Patch Links:

https://github.com/stackevo/spudreq/pull/13.patch https://github.com/stackevo/spudreq/pull/13.diff — Reply to this email directly or view it on GitHub.

hardie commented 9 years ago

Hi Ken,

Replies in-line.

On Fri, Aug 7, 2015 at 3:40 PM, Ken Calvert notifications@github.com wrote:

Hi Ted -

Let me see if I understand what you were trying for. I think I see two goals (beyond "don't be a tool of evil"):

(i) SPUD should not undermine the overlying protocol's security.

​Yes. This is job one.​

(ii) SPUD should not enable providers to extort metadata exposure from users.

​Basically, if the metadata changes the security proper​ties of the overlying protocol, SPUD should not enable providers to require it be supplied.

​If an on-path network element​ sent back a message saying "applying BE markers to tube-id:XXX", one result could be the application sending a SPUD message requesting a different treatment for tube-id:XXX. That does make explicit something that was previously implicit, but it should not change the security properties of the overlying protocol (which apparently wished to have different treatment all along, and is now making it known explicitly). Does this disclose something new? Possibly, because it makes the request explicit and allows other on-path network elements to see it (where they might not have had the destination/port table that some middlebox previously used to infer the treatment desired). But it is an explicit disclosure, not a leak, since the app is in control. It also doesn't change the core security properties of the transport (does not exchange identities, etc.)

​This wants a lot of thinking about, obviously, but that's my current notion.​

But also we maybe need to figure out what is the "endpoint" here. Is it the application? Or might there be a policy interface that also has something to say -- e.g., supplying a preconfigured secret or credential that proves policy-compliance, to be presented to the corporate firewall. I think it may be hard to rule out the latter possibility.

Regarding (i): If the overlying protocol is well designed, seems like this should not be possible. But how about this: SPUD MUST NOT leak information from the OT payload; SPUD's behavior must be completely independent of the content of the SPUD payload regardless of whether it is encrypted or not.

​I like the first MUST NOT. I'm not sure we would ever see deployment of SPUD without encrypted payloads, but I guess I also agree with the second.​

Regarding (ii), how about:

SPUD is not intended to support in-band negotiation of policy with network elements, and should not provide mechanism to enable this. Any such negotiation (e.g., obtaining proof of policy-compliance in order to gain passage) MUST be conducted a priori and out of band.

In my view, it's OK for SPUD to carry an opaque token that proves policy-compliance; SPUD just needs to be agnostic about the policy and what policy-compliance reveals about the user. But I don't know if that will be enough to make some people happy.

​I need to think more about the policy compliance token, but my initial reaction is that you can't have such a thing without changing the nature of the overlying protocol, in part because you have to build in replay protection which ties the token to a specific protocol. If you were deploying such a policy compliance token for encrypted-DNS over SPUD​, for example, how would the compliance token work?

regards,

Ted

Ken

On 5 Aug 2015, at 16:33, hardie notifications@github.com wrote:

During the Prague side meeting, I took an action item to generate a pull request to describe the security semantic requirements. It's turned out to be harder than I thought ("don't be evil, and don't use SPUD for evil" didn't quite fly), so I'm throwing up a pull request I know isn't adequate in the hopes it will spur someone to improve it.

You can view, comment on, or merge this pull request online at:

https://github.com/stackevo/spudreq/pull/13

Commit Summary

PR on security semantics File Changes

M draft-trammell-spud-req.md (5) Patch Links:

https://github.com/stackevo/spudreq/pull/13.patch https://github.com/stackevo/spudreq/pull/13.diff — Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/stackevo/spudreq/pull/13#issuecomment-128849418.