search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Concept of "end-to-end security" #144

Open OliverPfaff opened 4 years ago

OliverPfaff commented 4 years ago

The concept of "end-to-end security" seems to deserve a more refined consideration. Some inputs

  1. Every security protocol actually delivers security between the ends that implement it - no matter if this is MACSec, IPSec, TLS, S/MIME....

  2. So "end-to-end" is not discrete (like a meter or an inch), actually it can be somewhat stretchy (it's more like percentage)

  3. Which "end-to-end security" is appropriate depends on risk assessments (assets vs. exposure/threats)

  4. There is no one-size-fits-all-needs "end-to-end security" mechanism, for example:

    • Protecting data on information-level (current suggestion referring to JWS/JWE...) does not protect against rogue components in the local network (sniffers, DoS...)
    • Protecting data on transport-level (TLS, DTLS) does not protect information that travels beyond client/server entities
    • Protecting the network (MACSec) does not protect data that leaves the (local) network
      etc
ereshetova commented 4 years ago

I guess the correct definition of what we meant by "end-to-end" here is indeed protection on data on information level between the two ends that need to exchange this information securely. I agree that it does not exclude the DoS threat, but it is generally very hard to exclude. About sniffers I am not sure what you mean, because if we do establish authentication&encryption between two end points that posses data, sniffing this data wont be possible unless you have actually obtained some higher system privilege on on the ends or hacked into the application itself.

But I think the point that "Every security protocol actually delivers security between the ends that implement it - no matter if this is MACSec, IPSec, TLS, S/MIME..." should be really mentioned in the doc to avoid confusion.

With regards to the choice when to choose end-to-end or other measure, I agree it all depends on your threat model and amount of risks one willing to take, I think this applies to any selection of measures in WoT, i.e. authentication mechanisms, choice of underneath secure protocol,e tc.

mmccool commented 4 years ago

Summary: We need a clearer definition. It can apply to multiple levels of the network stack. People often assume "end-to-end" is a "complete" solution and it's not, it depends on context.

Next steps: need basic definition in Architecture, more detailed discussion in Security Guidelines.

Actions:

  1. Create PR for basic definition in Architecture. Issue: https://github.com/w3c/wot-architecture/issues/430
  2. Create PR for adding a discussion section in Security Guidelines. This issue to cover.
mmccool commented 4 years ago

Next part of this discussion: where end-to-end discussion goes in Security document. Initial content can be based directly on the discussion above as a starting point.

OliverPfaff commented 4 years ago

Created a first proposal to have an anchor for this

OliverPfaff commented 4 years ago

First proposal done => unassign myself

mmccool commented 4 years ago

First draft has been done, but there are some pending wording changes requested and it needs further review. So we will leave this issue open and I'll re-assign @OliverPfaff to do the requested edits, then I will also assign @ereshetova to do a review pass. When that is done, and the above topics are addressed to everyone's satisfaction, we can close this issue.

OliverPfaff commented 4 years ago

I created a text update (see below) but faced issues in producing a PR (the tooling that is currently available to me seems to make that very tedious for me). For the time being I drop the proposed text below:

The notion 'end-to-end' security (short: E2E security) is often encountered when security is considered. Quite often, this notion is encountered in a way that is misleading: it is a matter of risk assessment to determine the "ends" that are to be protected in a distributed system such as WoT (identifying the domain-of-protection) and then select one or more security technologies to fulfill the identified demand (not: vice versa).

In that sense, there is no single, universal notion of E2E security in WoT. There is also no single security technology that allows to deliver E2E security for any definition of the ends. The perception of WoT security is to support users of WoT in implementing security architectures according their perception of the ends (which can vary across users, deployments etc.) using for instance: • CMS as well as XML/JSON/CBOR security (IETF resp. W3C) to provide E2E security on the level of application data • (D)TLS to provide E2E security between client and server processes • IPsec (IETF) to provide E2E security between endpoints in an IP-based inter-network • MACsec (IEEE) to provide E2E security between endpoints in one local network

The following technologies allow to address E2E security in the first sense (protecting exchanges between WoT system components on the level of application data): • If authenticity is desired for exchanged application data, then sign WoT objects (TDs, System User Data) using either digital signatures (using asymmetric cryptographic primitives) or Message Authentication Codes (MACs, using symmetric cryptographic primitives). Such digital signatures or MACs are created by the producers/issuers of the objects and validated by consumers of the objects (which should reject signed the objects whose signatures/MACs are invalid). For data expressed in JSON, RFC 7515 (JSON Web Signature (JWS)) provides a guideline for expressing digital signatures or MACs as well as security metadata using JSON-based data structures. RFC 8152 (CBOR Object Signing and Encryption (COSE)) does the same for CBOR. • If confidentiality is desired for exchanged application data, then encrypt WoT objects using well-known encryption primitives. For data expressed in JSON, RFC 7516 (JSON Web Encryption (JWE)) provides a guideline for expressing encrypted data as well as security metadata using JSON-based data structures. RFC 8152 (CBOR Object Signing and Encryption (COSE)) does the same for CBOR. Moreover the following is important here: o Confidentiality without authenticity (i.e. encryption-only) does not provide a secure scheme. Use authenticated encryption, not encryption-only to provide confidentiality o Classical cryptographic schemes (pre-AEAD) cover encryption-only and authentication-only. This requires an own design to deliver authenticated encryption and this tends to go wrong. Use AEAD schemes to deliver authenticated encryption (or use an underlying security protocol such as (D)TLS – when this can fulfill the identified E2E security demand)

ereshetova commented 4 years ago

I think this looks good! One thing maybe to make sure that all abbreviations are spelled out (like CMS) and also have a reference per each mentioned security mechanism.

OliverPfaff commented 4 years ago

I was able to overcome the issues mentioned in https://github.com/w3c/wot-security/issues/144#issuecomment-619917108 and created a PR based on the text already contained in https://github.com/w3c/wot-security/issues/144#issuecomment-619917108 (did not see Elena's comment until now => this is not yet covered in the PR)