Roman Danyliw Review Comments about architecture HOT 16 CLOSED

Section 1: change to word "risk", which reflects better.

Section 3.1: "trusted user interface" is generally referred in a use case context, not architecture specification. So consider to not give a formal definition. The actual component for a TA is perimeter interaction module as the paragraph gives as an example.

Section 3.3: changed to "one of the best ways"

Section 4.4: yes, the purpose of "support encryption" is to ensure data "not sent in clear".

Section 6.2: "Broker abstracts the message exchanges..."
@dthaler @hannestschofenig how about we say "Broker provides common APIs for the message exchanges"?

Section 7. What is the relationship between the attestation process in
Figure 6 and the conceptual message flow described in 6.2.1?
These are independent two flows. 6.2.1 talks about local device side TEEP Broker to TEEP Agent calls. Figure 6 is about attestation from device to the remote verifier in the TAM side.

"Verifier" is changed to consistently use capital initial.

Section 9: TEE shared secret attack threat --> will review

Section 9.1: "man-in-the-middle" alternative sex neutral word --> "person-in-the-middle" like chairperson in place of chairman :) But I am afraid that we are not ready to raise such a phrase in this RFC. Would be happy to adopt any other industry practice in this direction if there is a suggestion.

What a Broker can suggest? Maybe we can just remove this line since we don't provide an API or methods to allow a suggestion to be made. @dthaler @hannestschofenig

9.3 Compromised TEE --> No, TAM will be able to tell the TA list in a device, and stop installing new TAs that could fill up all storages.

9.7 TAM certificate life time follows the current practice by TLS certificates issued by most CAs, which is less than five years. It can be 1-2 years and up to a TAM provider to renewal more often. Change to 1 - 5 instead of 2 - 5 for a better inclusive range.

from architecture.

Look for vote on replacing "man-in-the-middle" with "person-in-the-middle". Thanks.

from architecture.

@dthaler @hannestschofenig please note my ask in the first reply above. Thanks.

from architecture.

Changed "man-in-the-middle" to "manipulator-in-the-middle" per Dave's check and suggestion.

from architecture.

Ben writes:

** Section 1. There are two different threat models implicitly described in
this section. The first paragraph seems outline the risk of multiple
applications on the same devices and the complexity of those applications. The
fourth paragraph describes the threat of threat actors with physical access.
Are we talking about both?

Correct.

Ming writes:

Section 3.1: "trusted user interface" is generally referred in a use case context, not architecture specification. So consider to not give a formal definition. The actual component for a TA is perimeter interaction module as the paragraph gives as an example.

I agree.

Ben writes:

** Section 4.4.
Implementations must support encryption to
preserve the confidentiality of such Personalization Data, which may
potentially contain sensitive data. Implementations must also
support mechanisms for integrity protection of such Personalization
Data.

Please clarify what it means to “support encryption.” Is this saying that all
personalization data at rest must be encrypted? No personalization data can be
sent in the clear?

The latter. (The former might also be needed in some cases.) Ming can you clarify this in the text?

Ben writes:

** Section 9. This section notes a few instances where a TEE should detect
that something potentially suspect is happening. How, if at all, should
logging of this phenomenon occur? How would someone managing devices become
aware of it or be notified?

Details are currently out of scope for TEEP, other than stating the consideration that implementations should do so.

Ben writes:

-- What suggestions can a Broker make? Per Section 6.1, I thought the Broker
only relayed messages between the Agent and the TAM.

As explained in Section 6.2.1, the Broker also interfaces between untrusted apps and the Agent,
so can "suggest" anything an untrusted app can do through the conceptual APIs discussed there.
@mingpeiwk perhaps the "While a TEEP Broker can in effect make suggestions" phrase can be
changed to something like "While a TEEP Broker can in effect make suggestions as discussed in Section {{apis}}"

Ben writes:

We have
already seen examples of attacks on the public Internet with billions
of compromised devices being used to mount DDoS attacks

Can a reference be provided for a single DDoS having billions of compromised
devices as sources.

@mingpeiwk I'd change "billions" to "a large number".
(https://en.wikipedia.org/wiki/Mirai_(malware) only mentions "large-scale" for instance so is not a reference)

from architecture.

Section 6.2: "Broker abstracts the message exchanges..."
@dthaler @hannestschofenig how about we say "Broker provides common APIs for the message exchanges"?

OLD:

A TEEP Broker abstracts the message exchanges with a TEE in a device.
The input data is originated from a TAM or the first initialization
call to trigger a Trusted Component installation.

The Broker doesn't need to parse TEEP message content received from a TAM
that should be processed by a TEE (see the ProcessTeepMessage API in {{apis}}).
When a device has more than one TEE, one TEEP Broker per TEE could
be present in the REE or a common TEEP Broker could be used by multiple TEEs
where the transport protocol (e.g., {{I-D.ietf-teep-otrp-over-http}}) allows
the TEEP Broker to distinguish which TEE is relevant for each message from a TAM.

The TEEP Broker interacts with a TEEP Agent inside a TEE, and
relays the response messages generated from the TEEP Agent back to the TAM.

NEW:

A TEEP Broker interacts with a TEEP Agent inside a TEE,
relaying messages between the TEEP Agent and the TAM, and may also interact with
one or more Untrusted Applications (see {{apis}}).
The Broker cannot parse encrypted TEEP messages between a TAM and a TEEP agent
but merely relays them.

When a device has more than one TEE, one TEEP Broker per TEE could
be present in the REE or a common TEEP Broker could be used by multiple TEEs
where the transport protocol (e.g., {{I-D.ietf-teep-otrp-over-http}}) allows
the TEEP Broker to distinguish which TEE is relevant for each message from a TAM.

from architecture.

Updated PR #256 with the changes above.

from architecture.

@mingpeiwk the changes in my comment 3 before this one have not yet been incorporated ("billions", "suggestions", and "support encryption" points).

from architecture.

Add a clarification about this comment:

Please clarify what it means to “support encryption.” Is this saying that all
personalization data at rest must be encrypted? No personalization data can be
sent in the clear?

Dave commented:

The latter. (The former might also be needed in some cases.) Ming can you clarify this in the text?

Agreed with Dave. It is security in motion.

Added the following in the doc:

"The encryption is used to ensure that no personalization data is sent in the clear."

from architecture.

@mingpeiwk perhaps the "While a TEEP Broker can in effect make suggestions" phrase can be
changed to something like "While a TEEP Broker can in effect make suggestions as discussed in Section {{apis}}"

Done

from architecture.

@mingpeiwk I'd change "billions" to "a large number".

Fixed

from architecture.

Ben writes:

Section 9. Nothing here seems to discuss attacks on the TEE's properties, and the
post-compromise implications of those attacks. For example, if all instances
of a TA share a secret key, used for decrypting the Personalization Data, then
a single successful attack on a TEE is sufficient to decrypt all
Personalization Data (previous and future). Given the prevalence of such
attacks (especially via hardware fault injection), it seems likely to be worth
mentioning. [1]

In general, we expect that a different secret key is used for different devices for Personalization Data encryption. Such a secret key is delivered to a TA using the public key of the TEE in the device. Such a shared secret key for all TA instances isn't a common case.

To mitigate this happening, I think we can add a statement to require that Personalization Data must not be encrypted with the same key for all devices.

@dthaler @hannestschofenig thoughts?

from architecture.

Ben writes:

-- Section 6. Typo. s/.././

@dthaler I cannot find "..". There is "..." in the Figure 5 after A B C. Those dots are optional; we just gave three sample models. Are you fine we remove "..." in that Figure?

from architecture.

Filed PR with my suggestions on remaining points.

from architecture.

On the "shared secret key", this line has been added by Dave in the doc:

"Personalization Data is encrypted with a key unique to that specific TEE, as discussed in {{trustanchors}}."

from architecture.

All comments have been addressed.

from architecture.