Subject: Re: [Rats] 答复: 答复: Another RATS message flow model for consideration:

From: "Smith, Ned" <[email-masked]>
Date: Thu, 21 Nov 2019 04:07:07 +0000

The security concern is partially raised by the previous paragraph, namely that the RP shouldn’t take action or consume data from an Attester before receiving and evaluating the attestation Evidence as the point of attestation is to lend credibility and veracity to the data. This is a generalization that could be invalidated by use case or deployment specific circumstances, but seems to make sense as a guiding principle. The consideration is that if the perception of added complexity causes implementers to ignore the expectation that data isn’t trustworthy until the source of the data (attested environment) has been attested then it is a security consideration. Data SHOULD be presumed to be untrusted until proven trustworthy.

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Wednesday, November 20, 2019 at 6:31 PM
To: "Smith, Ned" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: 答复: [Rats] 答复: Another RATS message flow model for consideration:

Hi Ned,
Thanks for the good insights, please see my responses inline for your 2 emails below:

发件人: Smith, Ned [mailto:[email-masked]]
发送时间: 2019年11月21日 6:19
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>; [email-masked]
主题: Re: [Rats] 答复: Another RATS message flow model for consideration:

Also, the https://datatracker.ietf.org/doc/draft-xia-rats-pubsub-model/ omits discussion of pub-sub between Verifier and Relying Parties. Presumably, there can be multiple relying parties that use a common verifier. The Attestation Results resulting from the interactions between Attesters and Verifier become pub-sub “topics” for subscription by Relying Parties.
[Frank]: good point. And that pub/sub maybe is not the netconf/yang based, can be other methods, like: atom, xmpp and http-based. We have not considered this point right now, it can be in this draft later or discuss in other draft if the WG are interested.

Some attention should be given to the use case and architectural models. Presumably, there is a dependency / ordering that relying party enforces over the data it obtains (subsequently?) from the Attester. Otherwise, acting on un-attested data could imply a weakness in the data flow model. For example, a Relying Party might expect to receive a publication of an Attestation Results topic as an additional condition when being notified about a data topic originating from the same attested environment.
[Frank]: there may  be. But I hope not as it will introduce complexity. If we really need to deal with it, a simple way is to leave it to the Relying Party with some cache mechanism.

The current draft doesn’t adequately addresses the security relevant considerations given a pub-sub deployment that incorporates attestation IMO.
[Frank]: sure, definitely will do it in the future iterations. Is there any big security issues in your mind now? I am always curious~~

-Ned

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of "Smith, Ned" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 18, 2019 at 8:25 AM
To: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] 答复: Another RATS message flow model for consideration:

This “architectural model” parallels the roles message flow. I think it could be viewed as a third model something like a pub-sub broker where Relying Parties subscribe to Verifier (broker) to receive Attestation Results and Attesters publish to Verifier (broker) when a change to the Evidence is found.
                [Frank]: it’s a use case and a very good one, thanks~~ And there can be more use cases. Another example is simply periodically request/response message flow between each pairs.

                B.R.
                Frank

A pub-sub model might treat Claims as pub-sub Topics that can be subscribed to or published to.

I get that some pub-sub architectures eliminate the broker as a distinct entity, but conceptually the model isn’t fundamentally different than if there were a central broker.

-Ned

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 16, 2019 at 2:17 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Rats] 答复: Another RATS message flow model for consideration:

Oops, Some fixes of the below text:

发件人: RATS [mailto:[email-masked]] 代表 Xialiang (Frank, Network Standard & Patent Dept)
发送时间: 2019年11月16日 18:13
收件人: [email-masked]<mailto:[email-masked]>
主题: [Rats] Another RATS message flow model for consideration:

Hi RATS architecture design team and all,
In addition to the current passport model and background check model. I think there is a third message flow model possibly for us to consider:
Attester < -------------------- > verifier < -------------------------------- > relying party
                               Evidence                              attestation results

The key point of the above model is that verifier has independent connection with attester and relying party respectively, and there are two independent message exchanges between the attester and verifier, between the verifier and the relying party. Of course, if needed, there can be some trigger condition and interaction between these two connections.
The relative advantage of the above model is simple, and each role only see what he needs to see, like: evidence is not seen by the relying party, attestation results is not seen by the attester.

I am wondering whether the architecture draft will consider it?

B.R.
Frank

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 21 Nov 2019 09:45:47 +0000

I agree with your analysis in general, but need more thinking about the more specific security issue.

发件人: Smith, Ned [mailto:[email-masked]]
发送时间: 2019年11月21日 12:07
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>; [email-masked]
主题: Re: 答复: [Rats] 答复: Another RATS message flow model for consideration:

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 20, 2019 at 6:31 PM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: 答复: [Rats] 答复: Another RATS message flow model for consideration:

Hi Ned,

发件人: Smith, Ned [mailto:[email-masked]]
发送时间: 2019年11月21日 6:19
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
主题: Re: [Rats] 答复: Another RATS message flow model for consideration:

-Ned

                B.R.
                Frank

-Ned

B.R.
Frank