Subject: [Teep] Comments on draft-tschofenig-teep-protocol-01

From: Dave Thaler <[email-masked]>
Date: Wed, 27 Nov 2019 22:14:34 +0000

I of course support adopting this as a WG document.

As noted at IETF 106, I prefer "TEEP Protocol" instead of "TEEP-P"
just like we say "TLS Protocol", "RADIUS Protocol", and "SSH Protocol"
for example, rather than "TLS-P", "RADIUS-P", and "SSH-P".

As a technical comment, I do not like the limitation in draft -01 that it can
only use EAT, and think that needs to be fixed before I can implement this draft.
If we go back to the IETF 105 discussion on TEEP+RATS alignment (slides at
https://datatracker.ietf.org/meeting/105/materials/slides-105-teep-sessb-teep-rats-alignment-01),
slide 2 seemed to be the WG consensus at the time.  That means the QueryResponse
in draft-tschofenig-teep-protocol-01 passes Evidence, as opposed to Attestation Results,
and the TAM only interprets Attestation Results from a Verifier, not the Evidence itself.

Slide 10 of https://datatracker.ietf.org/meeting/106/materials/slides-106-rats-sessa-rats-architecture-00
from the RATS WG meeting at IETF illustrates that there are many evidence formats,
of which EAT is one, but for which there already exist other standards and other proprietary
mechanisms used in existing hardware.  For example, SGX uses an Intel proprietary format
for Evidence, and for TrustZone we use the TCG standard DICE certificate chains.  Neither of
those are EATs for Evidence, even though I want to use EATs for Attestation Results.
But it means that the QueryResponse has to support all of these formats, including arbitrary
Vendor-specific formats, if we want the TEEP Protocol to be usable with a wide range of TEEs.
As such, I think the EAT in the Query Response needs to be replaced with a byte blob and
some format identifier (IANA media type or whatever).   If that is done, then I believe
the draft is actually implementable for our use cases.

Dave