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

On Fri, Sep 25, 2015 at 10:55 AM, Kis, Zoltan <zoltan.kis@intel.com> wrote:

>
> On Fri, Sep 25, 2015 at 7:57 PM, Jeffrey Yasskin <jyasskin@google.com>
> wrote:
>
>> 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.
>>
>
> I do not think any browser will implement encryption of NFC content with
> key management.
> Indeed it is better to remove this. However, there is the second note in
> the 'obtain push permission' steps which explains how and with what risk
> NFC content can be trusted. Should we use no generalized term for that?
> Should we just take that (manageable) risk and assume (with this note) that
> browsers can trust the origin information they find in a Web NFC message,
> to be used with security policies (easing user prompting)?
>

Yeah, *browsers* should trust the origin information they find in a Web NFC
message. I do think the spec should warn *website authors* that the
information may have come from a malicious or pwned tag/peer, rather than
their own manufacturer, and that the website should check the data before
trusting it.


> 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).
>>
>
> Pages could attack devices via convincing the user to tap another device,
> and in the receiving/dispatching chain make an exploit which can go
> unnoticed (the receiving page on the attacked device has to have a watch
> set up for that origin). I see little chance for this.
>
> Pages could as well attack tags, by rewriting their content. Since
> rewriteable tags can be overridden by any client, this is no more threat
> than any other client. The thing we should make sure is that no such write
> happens without the user knowing about it.
>

Remember that we're trying to prevent web pages from writing to tags that
don't already advertise an origin matching the page's origin. So pages can
only attack "their own" devices.

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 have not been thinking much about that actually. I was worried about
> pages attacking (rewriting) tags with different origin information that was
> there. For instance, redirecting links to own services.
>

If the browser can restrict writes to own-origin tags, then pages can't
rewrite a tag with different origin information.


> The reader thinks the data is associated with the origin found in the Web
> NFC Id, whereas it has been broken in the middle.
>
> The harm caused by this is that watches targeting the original Id's won't
> fire any more (but those based on content type would continue working).
> However, if I am about to deploy a service using Web NFC Id's, I'd make
> sure to use locked tags, for instance used for bootstrapping a "session"
> between peers in a gaming data exchange.
>
>
>>>>    - 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.
>>
>
> I think it would be good to have a call on this topic, including security
> folks and implementation people. I wonder how security folks imagine
> implementing a policy which checks origins, when the integrity of (storing)
> the origins is not guaranteed.
>

+1. I'm only available Oct 12-16 this coming month, but I'd be happy to
participate in a call then, or TPAC might also be a good place to talk
about it.

Thanks for the other updates. The spec is much better after #50.
>>
>
> The thanks is on our side. We are extremely grateful for the lot of work
> you have put in reviewing the spec and in making suggestions.
>
> In PR #56 I hope to get fixed the issues raised by Mark and you.
>
> Best regards,
> Zoltan
>