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

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)?


>
>
>> 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.


>
> 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.

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.


>
>
>>
> 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