Re: [web-nfc] Review fixes for #44.

On Thu, Sep 17, 2015 at 7:42 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>
> On Wed, Sep 16, 2015 at 10:53 PM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>>
>>
>>    - Does "trusted integrity NFC content" ever exist? How would a
>>    browser identify it? If we don't have a way to identify it, it probably
>>    shouldn't be in the spec.
>>
>> It is explained that it's possible to have, by a priori measures for
> having that trust, or mechanisms like encryption (with key management),
> which fall out of the scope of the spec.
>

Are you planning to implement any of those in Chrome? If so, what technique
are you using? Do you know of other browsers that intend to identify
"trusted integrity" content? If Chrome or another browser is implementing
it, the techniques probably should be in the spec, since browsers will need
to interoperate.

Otherwise, if no browser is implementing "trusted integrity NFC content",
the term shouldn't be in the spec.


> If we remove this, then we need to have stricter permission policy, but
> simpler spec. The issue we are revolving around is that @sicking said in #3
> they'd trust NFC content for integrity once web pages cannot break it. But
> it's not good enough security still. So we tried to make a terminology
> about whether the browser trusts NFC integrity or not. Again, trust would
> come either from an assumption that @sicking has made, or a proper
> encryption and key management scheme. All this is for making permissions
> less obtrusive, or the possibility of getting rid of them altogether. If
> you have suggestions along these lines, would be welcome. We could also
> remove this from the spec, but keep it in the Security and Privacy doc. But
> having it here would allow implementations to make a decision about the
> trust level, resulting in less/no permission checks.
>

I believe Jonas is worrying about web pages attacking devices. If the
device has already been written to by a native app or other radio, and that
app says to trust a particular origin, the damage has mostly already been
done (except that the web page may be able to auto-update the exploit
better).

You seem to be worrying about devices attacking web pages. The threat there
is smaller, and can be handled by the *web page* decrypting or checking
signatures on the NFC content, rather than the browser changing the
permission UI.

>
>>    - I don't see any enforcement that pages only receive NDEF messages
>>       from their own origin. Where is it? I suspect once this enforcement is in
>>       place, you won't need to check for "https" in the Web NFC Id, since the
>>       "secure context" restriction will handle it for you.
>>
>> We don't enforce that, since we don't trust the NFC data that we are
> calling "origin". The UA could validate that as an origin, but the
> integrity of it cannot be guaranteed for writeable tags. For that reason we
> can take Web NFC Id as a label which can be watched, but not for policy
> enforcement.
>

I believe this conflicts with the security folks' requirements.


>
Thanks for the other updates. The spec is much better after #50.

Jeffrey