Re: [Tigress] Sketching a simple design

[Yogesh Karandikar <[e-mail]>]

Inline.

Thanks,
Yogesh


> On Aug 15, 2023, at 5:23 AM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Mon, Aug 14, 2023 at 11:19 PM Yogesh Karandikar <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Chris,
>> 
>> 
>>> On Aug 14, 2023, at 3:02 PM, Christopher Wood <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Yogesh,
>>> 
>>>> On Aug 14, 2023, at 4:35 PM, Yogesh Karandikar <ykarandikar=[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Hi Eric,
>>>> 
>>>> Please see replies inline.
>>>> 
>>>> Thanks,
>>>> Yogesh
>>>> 
>>>> 
>>>>> On Aug 11, 2023, at 7:04 PM, Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> Yogesh,
>>>>> 
>>>>> I attempted to address a number of these points in the message you are
>>>>> responding to, but perhaps not clearly enough, so let me try again.
>>>>> 
>>>>> 
>>>>> > Hi Eric, Dmitry and Brad,
>>>>> > 
>>>>> > Thanks for kicking off this conversation.
>>>>> > 
>>>>> > The solution that Eric (ekr) has proposed is elegant and simple. It
>>>>> > relies on the assumption that R is secret.
>>>>> > 
>>>>> > If R is not secret, then an attacker can easily modify or delete R.1,
>>>>> > R.2 etc.
>>>>> > 
>>>>> > Unfortunately secrecy of R can not be assumed.
>>>>> > 
>>>>> > The extra layer that Brad discussed in his side conversation seems
>>>>> > like a variant of Device Claim from draft-art-tigress.
>>>>> > 
>>>>> > As Brad pointed out, it’s good that various potential solutions are
>>>>> > headed in same direction.
>>>>> > 
>>>>> > Coming back to the secrecy of R in invitation, we have tried to
>>>>> > capture that requirement in the text ekr quoted.
>>>>> > 
>>>>> > >     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).
>>>>> > 
>>>>> > Example of sms implicitly hints that the invitation is sent over
>>>>> > non-secure channel.  But it does not explicitly spell it out.
>>>>> 
>>>>> Indeed it does not. We routinely treat SMS and email as secure
>>>>> channels (e.g., for 2FA or account recovery). Of course, their
>>>>> security properties are far from ideal, but they're also fairly
>>>>> far from just posting the message publicly.
>>>>> 
>>>>> 
>>>>> > Perhaps it might be worth discussing the requirement in detail.
>>>>> 
>>>>> Yes, I think the WG should discuss this requirement, as it seems clear
>>>>> that there's not agreement on this point and at least I didn't even
>>>>> understand that some people thought this text had this implication.
>>>>> 
>>>>> 
>>>> 
>>>> Thanks for pointing it out. We’ll certainly address this with a PR to the requirements document.
>>>> 
>>>> 
>>>>> > I’ll try to describe the requirements in a use case format.
>>>>> > 
>>>>> > - PersonA has a credential for AccessPointA.
>>>>> > - PersonA should be able to share that credential to anyone.
>>>>> > - They should be able to post an invitation at a town square to share
>>>>> >   it. That invitation can look like this:
>>>>> >     "Invitation to get credential for AccessPointA. It’s present at
>>>>> >     mailbox address R. First person to act will get the shared
>>>>> >     credential.”
>>>>> > - If PersonY is the first person to reach the mailbox R, only PersonY
>>>>> >   gets that credential. Also nobody else is able to thwart the sharing
>>>>> >   process by modifying or deleting any messages in the exchange.
>>>>> > 
>>>>> > Thoughts? Suggestion? Questions?
>>>>> 
>>>>> I would make several points. First, ignoring how this is implemented,
>>>>> this seems like an extremely bad set of properties, in that they
>>>>> create a race condition between the receiver of the credential and the
>>>>> attacker. We should expect the attacker to win a significant number of
>>>>> those races, with the result that not only is he able to disrupt the
>>>>> transfer of the credential, he actually ends up with it. That doesn't
>>>>> seem like a secure system and I don't think the IETF should
>>>>> standardize that.
>>>> 
>>>> Being able to deliver the invitation to intended recipient securely is the ideal property.
>>>> 
>>>> But we can *not* make assumptions about identity of the recipient or security of OutOfBand channel that carries the invitation. (From Tigress perspective the channel that carries the invitation is the OOB channel). E.g. Email is one such OOB channel.  I can hope that this email lands in the mailbox of intended recipients and no-one else has access to its contents. But I can’t be sure of that.
>>>> 
>>>> We are just trying to acknowledge the limitations of the current methods to deliver the invitation.
>>>> 
>>>> I’m not sure if the probability that the invitation gets securely delivered to intended recipient will ever reach 100%.
>>>> 
>>>> We still need a Tigress channel to complete the exchange after the invitation is delivered and acted upon by the recipient.
>>> 
>>> I can’t speak for Eric, but I think what he’s saying is that these non-secure channels are consistently used for second factor authentication mechanisms all the time. For example, they deliver one-time codes or password reset secrets fairly regularly. I just used a password reset email today, in fact!
>> 
>> Just trying to establish a baseline here.
>> 
>> We have some consensus that certain channels like SMS are not considered secure. Right? 
>> 
>> There is plenty of research about vulnerabilities where an attacker can easily get SMS intended for someone else. 
>> 
>> I found couple of interesting articles in a few minutes of searching : 
>> 
>> 
>> Security Analysis of SMS as a Second Factor of Authentication - ACM Queue
>> queue.acm.org
>> <favicon.ico>
>>  <https://queue.acm.org/detail.cfm?id=3425909>Security Analysis of SMS as a Second Factor of Authentication - ACM Queue <https://queue.acm.org/detail.cfm?id=3425909>
>> queue.acm.org <https://queue.acm.org/detail.cfm?id=3425909>	<favicon.ico> <https://queue.acm.org/detail.cfm?id=3425909>
>> 
>> Bolstering Data Privacy and Mobile Security: An Assessment of IMSI Catcher Threats
>> nist.gov
>> <favicon.ico>
>>  <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>Bolstering Data Privacy and Mobile Security: An Assessment of IMSI Catcher Threats <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>
>> nist.gov <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>	<favicon.ico> <https://www.nist.gov/speech-testimony/bolstering-data-privacy-and-mobile-security-assessment-imsi-catcher-threats>
>> 
>> 
>> 
>>> I don’t see a technical reason as to why the Tigress use case is unique and these channels cannot work for similarly sensitive secrets, such as those proposed in Eric’s solution sketch. And given that it greatly simplifies the design space here, I’d like to see us pursue that option.
>>> 
>> 
>> The non-secure channels are used for delivering a second factor. Also typically the OTP is only valid for a few seconds (enough time for legitimate user to enter it but not enough for attacker to use it).
>> 
>> Can we safely assume that the 2FA over non-secure channels is considered acceptable for a few seconds?
>> 
>> For Tigress, we want to acknowledge that the channels are non-secure. Yet, we want to let people use those channels. Because what happens after using those channels is expected to be secure. Also note that the after is the Tigress domain. 
>> 
>> 
>> The solution that Eric has proposed is simple and elegant. But it relies on the assumption that the mailbox address (R) is secret. 
>> 
>> That solution does not work when the channel used to deliver the R can not keep the R secret.
> 
> Yogesh,
> 
> Putting aside the security properties of SMS for a second, 
> 
> I've already explained twice, first in my original message, and then in my response to you yesterday,
> how my design can provide the at-most-once semantics you are asking for. I would appreciate it if
> you would address that (perhaps by explaining why I'm wrong) rather than just
> continuing to assert that it doesn't.

The other email had specific questions. I’ve already responded to those questions. 

This question about why the simple method doesn’t work is asked for the first time. 

So, I’ll address it here:

1. Basic method (Use R, R.1, R,2 etc for message locations).
- Sender stores [Message 1] at location R.
- IntendedRecipient and attacker both know R and can read [Message 1].
- Attacker can put change/delete [Message 2] at location R1 to disrupt the sharing flow.
- I believe you pointed out that R must be secret for this to work in that email.  
- I agree that if R is compromised this method will not work.

2.  Augmentation for at-most-once.
- Sender stores [X1, Message] at location R.
- IntendedRecipeint and Attacker both can read that if R is not secret. (As you pointed out in another email, it’s safe to assume that attacker wins most races. So Attacker read [X1, Message1] but didn’t delete it ).
- Both know location of the next message (PRF(R,X1)),
- IntendedRecipient puts [X2, Message 2] at location PRF(R, X1). 
- Attacker already knows the location because they have read the [X1, Message1]. Now they can change or delete [X2, Message2] from PRF(R, X1).

As far as I can tell, even the augmented method relies on assumption that R is secret. So to me that augmented method also doesn’t work if R can *not* be kept secret.

Please let me know if I missed some detail from the augmented solution. 

 

> 
> -Ekr
> 
>> 
>> 
>> Thanks,
>> Yogesh
>> 
>> 
>>> Best,
>>> Chris 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> 
>>>> 
>>>>> 
>>>>> Second, as I indicated in my response to Dmitry, although the basic
>>>>> scheme I described does not provide these "at-most-once" properties,
>>>>> later in my message I do describe an enhancement which is intended to
>>>>> provide them, under the heading "Restricting the exchange to two
>>>>> participants".  Briefly, the idea is that the Sender's initial message
>>>>> contains an additional secret X1 which is used along with R to
>>>>> generate the address of the receiver's response. The receiver deletes
>>>>> the sender's message after reading it, with the result that any
>>>>> subsequent participant is unable to generate the appropriate return
>>>>> address. It's of course possible I've missed something and this
>>>>> doesn't work. The cookie system designed in Brad's message also seems
>>>>> like it would address this issue, and IMO it's a lot simpler than
>>>>> adopting all of the machinery in draft-art-tigress.
>>>> 
>>>> Both of those approaches can work but they essentially shift the work of Req-ConnectionIntegrity into the protocol that is going to use the Tigress channel. 
>>>> 
>>>> Those protocols are defined out of scope of IETF and could chose whatever X1 and PseudoRandom functions. They could even define a completely different approach if they wish.
>>>> 
>>>> That increases the complexity of clients trying to implement the credential transfer solutions. The client has to implement n different methods for Req-connectionIntegrity to support n different verticals.
>>>> 
>>>> Whereas draft-art-tigress handles that complexity and provides a simple channel interface for clients. 
>>>> 
>>>> As an implementer, I would prefer the Tigress channel to handle the complexity and provide Req-ConnectionIntegrity.
>>>> 
>>>> 
>>>>> 
>>>>> Note that AFAIK none of these approaches prevents the race condition I
>>>>> alluded to above, which is why I still think it's necessary to assume
>>>>> R is secret or to have some other piece of secret material shared
>>>>> between sender and receiver. However, it does provide security againt
>>>>> subsequent leaks of R.
>>>>> 
>>>>> -Ekr
>>>>> 
>>>>> P.S.  Whatever you are doing when you respond seems to be be breaking
>>>>> threading, at least in gmail. Are other recipients having this issue?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Aug 11, 2023 at 9:03 PM Yogesh Karandikar <ykarandikar=[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> Hi Eric, Dmitry and Brad,
>>>>>> 
>>>>>> Thanks for kicking off this conversation.
>>>>>> 
>>>>>> 
>>>>>> The solution that Eric (ekr) has proposed is elegant and simple. It relies on the assumption that R is secret. 
>>>>>> 
>>>>>> If R is not secret, then an attacker can easily modify or delete R.1, R.2 etc.
>>>>>> 
>>>>>> Unfortunately secrecy of R can not be assumed.
>>>>>> 
>>>>>> The extra layer that Brad discussed in his side conversation seems like a variant of Device Claim from draft-art-tigress.
>>>>>> 
>>>>>> As Brad pointed out, it’s good that various potential solutions are headed in same direction.
>>>>>> 
>>>>>> Coming back to the secrecy of R in invitation, we have tried to capture that requirement in the text ekr quoted.
>>>>>> 
>>>>>>>> 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).
>>>>>> 
>>>>>> Example of sms implicitly hints that the invitation is sent over non-secure channel.   But it does not explicitly spell it out.
>>>>>> 
>>>>>> Perhaps it might be worth discussing the requirement in detail.
>>>>>> 
>>>>>> I’ll try to describe the requirements in a use case format.
>>>>>> 
>>>>>> - PersonA has a credential for AccessPointA.
>>>>>> - PersonA should be able to share that credential to anyone.
>>>>>> - They should be able to post an invitation at a town square to share it. That invitation can look like this:
>>>>>>     "Invitation to get credential for AccessPointA. It’s present at mailbox address R. First person to act will get the shared credential.”
>>>>>> - If PersonY is the first person to reach the mailbox R, only PersonY gets that credential. Also nobody else is able to thwart the sharing process by modifying or deleting any messages in the exchange.
>>>>>> 
>>>>>> 
>>>>>> Thoughts? Suggestion? Questions?
>>>>>> 
>>>>>> Thanks,
>>>>>> Yogesh
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> From: Brad Lassey <[e-mail] <mailto:[e-mail]>>
>>>>>>> Subject: Re: [Tigress] Sketching a simple design
>>>>>>> Date: August 8, 2023 at 2:33:25 PM PDT
>>>>>>> To: Eric Rescorla <[e-mail] <mailto:[e-mail]>>
>>>>>>> Cc: Dmitry Vinokurov <dvinokurov=[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]>
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Aug 8, 2023 at 8:52 AM Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>>> > 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- 
>>>>>>>> Tigress mailing list
>>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>>> https://www.ietf.org/mailman/listinfo/tigress
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks Eric,
>>>>>>> I think you made an important point at the mic during the meeting and that was that a lot of the complexity of the original Tigress proposal falls out of the fact that it is trying to have the sender and receiver "co-edit" the same resource. That functionality is the sort of thing that WebDAV set out to solve years ago, and hence why I think many of us jumped to that solution space.
>>>>>>> 
>>>>>>> If we instead read/write separate resources sequentially, it simplifies things greatly. In fact, Eric Kinnear and I effectively sketched out the same solution you describe here in a side conversation after the working group meeting.  It is probably a good sign that two different sets of people arrived at roughly the same rough conclusion independently.
>>>>>>> 
>>>>>>> There were two additional ideas that we discussed that could layer on top of this. The first was aimed at reinforcing the "only two" property that Dmitry and Yogesh brought up during their presentation and that was to have the server set a session cookie for both the sender and receiver and restrict the access to /R* to only two unique session cookies.
>>>>>>> 
>>>>>>> The second was to have a convention that the sender and receiver can PUT a file at /R.sender and /R.receiver respectively that contains a webhook URL and the server can ping that webhook whenever any new file is PUT to /R*.
>>>>>>> 
>>>>>>> I think both of these things could be optional enhancements, which would preserve the property that you can use an off the shelf HTTP server and be spec compliant.
>>>>>>> 
>>>>>>> -Brad
>>>>>>> 
>>>>>>>  
>>>>>> 
>>>>>> -- 
>>>>>> Tigress mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/tigress
>>>> 
>>>> -- 
>>>> Tigress mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/tigress
>>