W3C home > Mailing lists > Public > public-wot-ig@w3.org > November 2018

[wot-security] minutes - 12 November 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Tue, 20 Nov 2018 01:00:17 +0900
Message-ID: <CAJ8iq9WhuXfrkHNuK4RU00TYMD=tqyEtaQsYO_PuTq4_-A2N4w@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
  https://www.w3.org/2018/11/12-wot-sec-minutes.html

also as text below.

Thanks,

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT Security

12 Nov 2018

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Agenda

Attendees

   Present
          Kaz_Ashimura, Michael_McCool, Elena_Reshetova,
          Tomoaki_Mizushima

   Regrets

   Chair
          McCool

   Scribe
          kaz

Contents

     * [3]Topics
         1. [4]Review of prev minutes
         2. [5]Agenda for today
         3. [6]Update on publication status
         4. [7]New meeting time?
         5. [8]Pending PRs
         6. [9]Elena's update
         7. [10]PR207 - revisited
     * [11]Summary of Action Items
     * [12]Summary of Resolutions
     __________________________________________________________

   <McCool> [13]https://www.w3.org/2018/11/05-wot-sec-minutes.html

     [13] https://www.w3.org/2018/11/05-wot-sec-minutes.html

   <scribe> scribenick: kaz

Review of prev minutes

   McCool: url above
   ... don't see any issues
   ... no problem
   ... any comments?

   (none)

   McCool: the minutes have been accepted

Agenda for today

   McCool: would like to add one item on "new meeting time"

Update on publication status

   Kaz: restart the procedure
   ... for Scripting and Security
   ... almost done but possible errors with link checker

   McCool: will respond if any problem

   Kaz: tx

New meeting time?

   McCool: please create doodle polls

   Kaz: will work on doodles for security and testing

   McCool: please work on testing (wed vs tue) first
   ... and then we should try security based on the result

   Kaz: ok

Pending PRs

   [14]TD PRs

     [14] https://github.com/w3c/wot-thing-description/pulls

   McCool: PR 277 has been merged

   [15]PR 277

     [15] https://github.com/w3c/wot-thing-description/pull/277

   McCool: Sebastian is waiting for the update for Editor's note
   on PR 269

   [16]PR 269

     [16] https://github.com/w3c/wot-thing-description/pull/269

   McCool: fixed the conflict and should be ready for merge
   ... also security terms PR

   [17]PR 268

     [17] https://github.com/w3c/wot-thing-description/pull/268

   McCool: any objections to PR 268?

   (none)

   McCool: next security consideration section

   [18]PR 207

     [18] https://github.com/w3c/wot-thing-description/pull/207

   McCool: Taki made a comment
   ... discussion at TPAC
   ... reference for security
   ... already had a comment on privacy risk
   ... mitigated by caching
   ... read through it again
   ... JSON-LD spec has a security consideration section
   ... decided to create a separate security risk section
   ... privacy risk and security risk


   <section id="sec-security-consideration-context">
   <h5> Context Dereferencing Privacy Risk</h5>
   <p> Deferencing the vocabulary files given in the
   <code>@context</code>
   field of any JSON-LD document can be a privacy risk.
   In the case of the WoT, an attacker can observe the network
   traffic produced by such deferences and can use the metadata
   of the dereference, such as the destination IP address,
   to infer information about the device especially if
   domain-specific
   vocabularies are used. This is a risk even if the connection
   is encrypted, and is related to DNS privacy leaks.
   </p>
   <dl><dt>Mitigation:</dt><dd>
   Avoid actual dereferencing of vocabulary files.
   Vocabulary files should be cached whenever possible.
   Ideally they would be made immutable, built into the
   interpreting device,
   and not derefenced at all,
   with the URI in the <code>@context</code> field serving only as
   an identifier of the (known) vocabulary.
   This requires the use of strict version control, as updates
   should use a new URI to ensure that existing URIs can refer to
   immutable data.
   Use well-known standard vocabulary files whenever possible to
   improve the chances that the context file will be available
   locally
   to systems interpreting the metadata in a Thing Description.
   </dd></dl>
   </section>
   <section id="sec-security-consideration-id">
   <h5> Immutable Identifiers Privacy Risk</h5>
   <p> The fact that a Thing Description contains a unique
   identifier means that should it be associated with
   a person it can be used to track that person and
   therefore pose a risk to privacy.
   </p>
   <dl><dt>Mitigation:</dt><dd>
   All identifiers should be mutable,
   and there should be a mechanism to update the <code>id</code>
   of a Thing.
   Specifically,
   the <code>id</code> of a Thing should not be fixed in hardware.
   This does, however, conflict with the Linked Data ideal that
   identifiers are fixed URIs. In many circumstances it
   will be acceptable to only allow updates to identifiers if
   a Thing is reinitialized. In this case as a software entity the
   old Thing ceases to exist and a new Thing is created.
   This can be sufficient to break a tracking chain when, for
   example, a device is sold to a new owner.
   Alternatively, if more frequent changes are desired during
   the operational phase of a device,
   a mechanism can be put into place to notify only authorized
   users
   of the change in identifier when a change is made.
   Note however that some classes of devices, e.g. medical
   devices,
   may require immutable IDs by law in some jurisdictions.
   In this case extra attention should be paid to secure
   access to files, such as Thing Descriptions, containing such
   immutable identifiers.
   </dd></dl>
   ]]

   McCool: linked data issue here
   ... make sure the context file is immutable
   ... take a look at it
   ... will talk with Sebastian and ask to merge it

Elena's update

   Elena: (shows the draft on her PC)
   ... 9. Security and Privacy
   ... go through risks, mitigation, ...

   McCool: security risks and privacy risks
   ... most of them in your draft look like security risks
   ... why don't you say "security and privacy risks" here?

   Elena: ok
   ... related to security and privacy
   ... the text is not very much changed
   ... 9.2 physical device misuse risk
   ... 9.3 provisioning and update risk

   McCool: 9.1 should be "unauthorized data access risk"
   ... and 9.2 is regarding physical device access risk
   ... rather safety maybe
   ... kind of worried about actuators misused
   ... and 9.1 is data misused

   Elena: can be many things
   ... maybe the section titles are not really good

   McCool: good to have interaction layer
   ... should be a fail-safe mechanism

   Elena: physical device direct access risk?

   McCool: still misleading
   ... maybe the first one should be cross-script access?
   ... would include both the cases
   ... 2nd one privacy/security risks
   ... camera related to privacy risk
   ... how can we avoid safety risks as well?
   ... may lack safety checks
   ... but they should
   ... next one?

   Elena: 9.3 provisioning and update risk

   McCool: more about tact factors
   ... accessed data or...

   (some more discussion on 9.1, 9.2 and 9.3)

   McCool: 9.3 is more serious threat
   ... malicious script risk?
   ... playing with software and device

   Elena: have to think about that

   McCool: need security update

   Elena: how does the malicious script happen?

   McCool: have same problem
   ... in some cases, repeat mitigation

   Elena: can try to rewrite the text

   McCool: probably you can leave 9.3 alone
   ... 9.2 as well
   ... but 9.1 is a bit ambiguous
   ... maybe the title should be changed
   ... 9.4...
   ... having a secure keys
   ... TPM model
   ... key stored in a secure way

   Elena: related to what the runtime should not expose
   ... don't really have the TPM model here

   McCool: 9.5?
   ... corrupted input risk
   ... mitigation here
   ... form validation
   ... including fuzzing
   ... maybe should reward this
   ... testing to includ fuzzing
   ... or fuzzing should be used during testing for robustness
   ... other than that, the text makes sense
   ... 9.6
   ... corrupted/compromised script risk

   Elena: how to name the title?

   McCool: the key idea here
   ... bugs on security risks

   Elena: complexity risk?

   McCool: 9.7 covers service risk
   ... not sure if 9.6 belongs to that
   ... 9.8 related to cross-reference?
   ... the ID may not immutable
   ... because it's recommended to do...
   ... stale to the list?
   ... security risk or privacy risk
   ... ID reusing is not a big problem
   ... the question is if I could force somebody to stale TD
   ... how it could cause a security risk?
   ... TD indicates old security scheme
   ... might cause security risk
   ... let's think of scenarios here
   ... let's leave it now
   ... could call it staled TD risk
   ... need to figure out what kind of attacks

   Elena: can do the changes
   ... should I send a PR?

   McCool: why don't you create a PR
   ... and I'll review it
   ... can you join the TD call on Friday?
   ... early morning in your place

   Elena: but this is for not TD but Scripting API

   McCool: ah, yes
   ... create a PR
   ... and ask Zoltan for review
   ... and we can look at it next Monday together
   ... go ahead and make changes

   Elena: ok

   McCool: what's a bug and what's a risk

PR207 - revisited

   fyi, we might want to use [19]https://www.staticaly.com/ as a
   possible alternative for rawgit

     [19] https://www.staticaly.com/

   McCool: (shows testing/ex.html)
   ... Kaz provided an example from EMMA specification
   ... and I've generated this template
   ... TD Implementation Report template
   ... still need to do by Wed
   ... will generate assertions
   ... thinking for security, we may need an additional section
   ... we have to explain what kind of test is needed
   ... penetration test, etc.
   ... on our implementation
   ... we have to the testing, and explain what kind of test was
   done
   ... fuzz testing for CoAP, etc.
   ... will draft an additional section 8 for that purpose
   ... note that the WG Charter says:


   In order to enhance the security of WoT systems, we will also
   generate and implement a security testing plan which will
   include both functional and adversarial testing of the proposed
   standards and their implementations. We will only recommend an
   implementation of the proposed standards for use in production
   once it has passed such testing.
   ]]

   Elena: would be difficult to test it...

   Kaz: it seems we need to try two levels of testing
   ... 1. basic TD features
   ... 2. security-ready features

   McCool: would like to draft some text for the security part

   [adjourned]

Summary of Action Items

   See [20]the Action wiki.

     [20] https://www.w3.org/WoT/IG/wiki/IG_Security_WebConf#Actions

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [21]scribe.perl version 1.154 ([22]CVS log)
    $Date: 2018/11/13 13:56:51 $

     [21] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [22] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 19 November 2018 16:01:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 November 2018 16:01:32 UTC