Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification regarding Data Protection #225

Open
hannestschofenig opened this issue Mar 25, 2021 · 4 comments
Open

Clarification regarding Data Protection #225

hannestschofenig opened this issue Mar 25, 2021 · 4 comments
Assignees

Comments

@hannestschofenig
Copy link
Collaborator

@hannestschofenig hannestschofenig commented Mar 25, 2021

The protocol between TEEP Agents and TAMs similarly is responsible
for securely providing integrity and confidentiality protection
against adversaries between them. Since the transport protocol under
the TEEP protocol might be implemented outside a TEE, as discussed in
Section 6, it cannot be relied upon for sufficient protection. The
TEEP protocol provides integrity protection, but confidentiality must
be provided by payload encryption, i.e., using encrypted TA binaries
and encrypted attestation information. See [I-D.ietf-teep-protocol]
for more discussion.

Re-work the text to clarify that this is a design choice whether to terminate TLS inside the TEE or outside. Different solutions have taken a different approach here and the architecture should be agnostic to it.

@dthaler
Copy link
Collaborator

@dthaler dthaler commented Jul 10, 2021

What is the issue? The text says "might be implemented outside a TEE" so it already implies it's a design choice.
Hence to me it's already clear enough and agnostic to it.

Also, as an aside, that paragraph is transport protocol agnostic, so if there were a binding over something other than TLS (e.g., DTLS or OPC UA's security protocol) it would still be correct.

I'd propose resolving this as wont fix.

@hannestschofenig
Copy link
Collaborator Author

@hannestschofenig hannestschofenig commented Jul 11, 2021

Here is my proposal: #229

@hannestschofenig
Copy link
Collaborator Author

@hannestschofenig hannestschofenig commented Jul 12, 2021

The issue is that I see others coming with different solutions that fit the same architectural description and problem statement.

Reading through the draft I noticed that there are a few places where we go the step from the architecture to the solution details. This is not really necessary and hence I wanted to make it a bit more generic

@dthaler
Copy link
Collaborator

@dthaler dthaler commented Jul 12, 2021

Fixed in draft -15

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants