Re: [Tigress] Sketching a simple design

[Eric Rescorla <[e-mail]>]

> Hi Erik,

Eric.


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

R obviously has to be of sufficient size, but assuming it is (say 256
bits) then the chance of collision is vanishingly small.

We routinely assume that randomly generated values of sufficient size
do not have collisions in situations where the results will be far
more serious if they do, so I don't think this is a realistic
objection.


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

It's unfortunate that the requirements are so unclear on this topic,
as I had understood from previous conversations that we *were*
assuming the integrity of the channel. I would note that the document
tend to support this and are at best ambiguous.

>From Section 9 of the Requirements Document:

    An invitation for a shared credential transfer, sent to the Receiver
    device shall be a self-contained and self-sufficient data (e.g. token,
    URL, or QR code) allowing a user of the Receiver device to start a
    process of transferring and adding a new credential. Such invitation
    should be allowed to be sent over any generic communication channel
    (e.g. sms, email, NFC).


And S 5.2.2 of the threat model:

   Solution should require an end-to-end encrypted messaging channel
   or otherwise specify a way to send a secret out of band.

Moreover, if your concern is that the URL will be compromised and
everything is protected by some short code, then we have other
problems. So, I think we probably should discuss the threat model
some more.


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

This is correct for the basic protocol but I believe not for the one I
describe later in the message under the heading "Restricting the
exchange to two participants".


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

I'm not sure I follow you here. I would make several points.

1. I believe that this does meet the security requirements, without
   any additional protocol other than what I've sketched above. Can
   you share your concerns about why that's not the case?

2. I'm not sure why you are mentioning WebDAV here. This is just
   straight HTTP. I did at one point suggest WebDAV, but having
   thought through the problem more, I do not believe it is necessary.

As far as "valid justification" goes, this design has several
advantages over the REST API design in draft-art-tigress. First, it
doesn't require modifications to the Web server, as this is a
conventional configuration. Second, because the correctness and
security properties are largely enforced at the endpoints it largely
doesn't depend on the server behaving correctly beyond some simple
access control mechanisms (not allowing clients to enumerate files).

-Ekr