Re: [Teep] Implementation feedback on draft-ietf-teep-opentrustprotocol-01

[Andrew Atyeo <[e-mail]>]

Some really good feedback from Dave – my thoughts [AA] in the email below.

Andrew Atyeo
Security Architect
Intercede
Digital trust    people ǀ devices ǀ apps
Office: [phone]
www.intercede.com<https://www.intercede.com/>
Legal Disclaimer <https://www.intercede.com/privacy-cookies>
From: TEEP [mailto:[e-mail]] On Behalf Of Dave Thaler
Sent: 16 July 2018 15:25
To: [e-mail]
Subject: [Teep] Implementation feedback on draft-ietf-teep-opentrustprotocol-01

During the Hackathon yesterday, I started trying to write code for OTrP
to see what issues I would run into.   Below are some issues I ran into, in
addition to what I already gave as feedback on the arch doc.


1)      Section 6.5 explains that the TAM needs to receive a list of one or more

TA’s that are requested to be installed (S6.5.1 point 1A).  However, no

message is defined for doing so, which prevents interoperability.  I
think this message needs to be generated by the TEE (not the rich app),
for reasons I will explain in #3 below.

[AA] I don’t see the need for a message for defining the TAs that need to be installed. The OTrP messages are between the TAM and the TEE, but the desire to install TAs comes from the rich app. In practice, a rich app will have the identifiers of the TAs it requires built into its own code, since its own code will also be calling those TAs (e.g. once installed, to perform some DRM or payment authentication). Therefore a rich app is aware of the TAs it needs.

I don’t think this info can come from the TEE – since at this point the TA is not installed yet, so which part of the TEE would have the knowledge of which TAs are needed?



2)      Section 6.5 explains that the TAM needs to keep track of TAs installed
on all devices, even though its list might be wrong.   This has a scalability
issue.  Instead, I think there should be no such requirement.
[AA] the document should not mandate that a TAM needs to keep track of TAs. (Most would, but this is a implementation detail).
The whole of section 6.5 is for a ‘sample flow’, so I don’t think it is mandating anything.

3)      Putting my issue #1 and issue #2 together means there’s an extra round

trip that is unnecessary.  6.5 says the TAM receive a list of TAs needed,

and then the TAM just goes back and asks what is installed, just to get
a list of what needs to be installed.  This is unnecessary, the TEE can just

send a list of one or more TAs that need to be installed and aren’t already.

Hopefully this explains why I said in issue #1 above why I think the message
needs to be generated by the TEE.

[AA] but how could the TEE (which doesn’t have its TAs loaded yet) know what TAs should be loaded?

4)      Section 9.1.1 requires a list of OCSP stapling data, but as far as I can see,

the document provides no information or citation about the correct format
for such data.

[AA] This is a good point – this should refer to rfc6960

5)      The “did” field in 9.2.1.1 seems to be either (a) redundant and should be

removed, or (b) missing from other messages like Install TA.  The text explains
the field is to check that the message was received by the right device.  My
opinion is that since the TEE has to trust the TAM anyway, it’s the TAM’s
responsibility to send messages to the right device over an authenticated
channel (whether encrypted or not).  So I think it should be removed.

6)      Some fields, e.g. “signerreq”, have boolean values that are encoded as
strings (“true”, “false”). I think these should be boolean types, not strings,
which would also have the advantage of better compression if we can use
CBOR encoding.
[AA] I agree. At one point we had a bug open to address this, but I think there are some cases that are not addressed. For example 9.1.5 shows signerreq as a json Boolean (true), but then the example GetDeviceTEEStateResponse on page 36, and other places shows signerreq as a string (“true”).
There needs to be an cleanup, searching on true and false, to identify any missed cases where Booleans are still represented as strings.

7)      Section 6.5.1 point 9.A implies that to install a TA, one must have an extra
round trip first to create an SD if one isn’t already there.  I would expect one
common case to be where there is one TA per SD, so that all TAs are isolated
from each other.  As such, requiring the extra delay is inefficient in time,
bandwidth, and processing.   All the fields in CreateSD are already present
in an InstallTA message (except the “did” field mentioned above in issue #5),
so it could be done automatically by the first InstallTA message itself.
[AA] when the SD is created, an asymmetric keypair is generated (spaik), and the public part of this is returned. When a TA is installed, it is encrypted with this key. This enables some use cases where a TAM could interface to a SP and enable an SP to provide the TA encrypted such that the TA binary is not known by the TAM.
The spaik is also used to encrypt the personalization data (that is also sent in InstallTA), and there is also a use case for a TAM interfacing to an SP in order that the SP encrypts perso data for that TEE such that it travels via the TAM to the TEE, but without the TAM having access to that data
Since InstallTA requires knowledge of the public key returned from CreateSD, it is true that the extra round trip is required.
So the question is whether there is a case for installing TA (and their accompanying perso data) without the ability to provide confidentiality between an SP and the TEE by making that layer of encryption optional, and by allowing the TA (and perso data?) to be bundled into CreateSD


8)      The scope of uniqueness of the “rid” and “tid” fields is underspecified.

They just say “unique”.  I think “rid” is just supposed to be unique within

a given {session,”tid”} but I can’t tell for sure.  And I think “tid” is just supposed
to be unique within a given session (not globally across all sessions, all TAMs,

all devices), but I can’t tell.   They’re also formatted as strings, but I’m not sure
why they can’t be integers which I think would be much more efficient..

[AA] although it is not mandated, random guids can be a viable implementation choice for these (as it takes away the requirement to manage incremental counters) – so I would not want to see these become integers. By making them strings, a TAM can choose the mechanism it wants.

I take your point about “rid” and “tid” being underspecified. The truth is that values contained in these fields don’t matter to the protocol much. (they are mostly for the convenience of the TAM in order to match up request and response messages (rid), and (tid) to understand which messages belong in a ‘conversation’)

9)      I found it confusing that the names of the messages don’t match the name values
in the messages themselves (“GetDeviceStateResponse” vs

“GetDeviceTEEStateTBSResponse”, etc.)   Having these not match is bug-prone.

[AA] I agree. Instead of having a mixture of GetDeviceStateXXX and GetDeviceTEEStateXXX they should all standardize on GetDeviceTEEStateXXX.

Node that there are intentional differences at the end of those words (e.g. GetDeviceTEEStateTBSResponse vs GetDeviceTEEStateResponse is intentional as one of these is the ‘to be signed’ data and the other is the signed data.

10)  It’s unclear whether a rich app can depend on two TA’s from different TAMs,

and whether a TA can depend on a TA from a different TAM.  In the use case

where the device admin runs the TAM and controls all TAs on their devices the

answer would be no.  But in other use cases I’m not sure.   If so, then the question
arises about how dependencies are expressed and whether a dependency needs
to express which TAM is used.  This then begs the questions of whether a TA might
be via more than one TAM, or might change TAMs over time.   The answers here
probably belong in the arch doc.
[AA] TA inter-dependency is completely out of the scope of the OTrP protocol. (so the rich app vendor needs to know all the TA IDs they need installing, and which TAM(s) to get them from).

Dave