<McCool> https://www.w3.org/2018/11/05-wot-sec-minutes.html
<scribe> scribenick: kaz
McCool: url above
... don't see any issues
... no problem
... any comments?
(none)
McCool: the minutes have been accepted
McCool: would like to add one item on "new meeting time"
Kaz: restart the procedure
... for Scripting and Security
... almost done but possible errors with link checker
McCool: will respond if any problem
Kaz: tx
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
McCool: PR 277 has been merged
McCool: Sebastian is waiting for the update for Editor's note on PR 269
McCool: fixed the conflict and should
be ready for merge
... also security terms PR
McCool: any objections to PR 268?
(none)
McCool: next security consideration section
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: (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
fyi, we might want to use https://www.staticaly.com/ as a possible alternative for rawgit
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]
See the Action wiki.