Re: [Tigress] Sketching a simple design

[Dmitry Vinokurov <[e-mail]>]

Hi Erik,

Thank you for proposal, here is some feedback.

I think on a high level the proposed protocol can work. As always, there are a few "if"s.

Comparing it to the REST/JSON protocol, I really can't see significant improvements with multiple resource creation (R, R.1, R.2 etc).
 
One potential but rather low risk is that R generated by a client (collision risk) vs R generated by server - if implemented properly on server, there is less chance of collision.

The larger problem, as I see it, is with reliance on security of the channel used to pass the unique value of R / URL to the shared resource from sender to receiver.

Tigress requirements document doesn't mandate that the invitation URL be sent over secure channel. 
Therefore we have to operate under assumption that the channel may be insecure - such as SMS/ email;
hence, the invitition URL - e.g. https://<server>/R can be intercepted (or mistakenly sent to a wrong receiver) - which is accepted and known risk.

This is identified as a high risk in the Threat model document. Tigress proposes to mitigate this risk with the secret sent out of band and additional second factor (verification code).

Using a real world analogy - sender puts a key (to a room) into a password-protected self-destroying case and places it into a deposit box at a train station - where anyone can access it, knowing the box number.
But only a legit receiver, who knows both the box number and the password to the case, can take it out of the box and open the case to fetch the key. 

Therefore, we assume that we can not guarantee that the communication via intermediate server is completely secure, but we want the protocol to guarantee 
that once the first receiving device starts the transfer flow, it can successfully complete it (first come first served approach that I mentioned in IETF 117 Tigress session).
The content of the data stored in the shared resource (aka mailbox) should't be spoiled or deleted before the transfer completion (Req-ConnectionIntegrity).
  
Going back to the proposed protocol - knowing the R, malicious actor can overwrite R, R.1, R.2 with harmful code (e.g. cat pictures, virus, spam information, ads)
or just delete R, R.1, R.2 etc. There is a chance that this might happen just by mistake, not with harmful intent. In any case, this breaks the (Req-ConnectionIntegrity).

If we say that we want to delegate this responsibility to the client protocol, we also need to define an additional protocol for the communication between sender and receiver clients.
I don't really see any benefits in adding a second protocol for the clients if this can be addressed in a single server protocol with resource locking between just 2 clients.   
I think that the fact that a off-the-shelf webserver, supporting WebDav can work for resource sharing, can't meet our security requirements (and hence we need to implement an additional protocol on the client level),  
is not a valid justification for using such web-server.


Dmitry Vinokurov
 Pay | 669-269-5514 | Infinite Loop 6, Cupertino, CA | [e-mail]