[Teep] comments on draft-ietf-teep-architecture-03

[Schönwälder, Jürgen <[e-mail]>]

Hi,

I am new to TEEP (so please forgive my ignorance) and I thought I
start by reading the architecture document. Below are my comments on
draft-ietf-teep-architecture-03. In general, I found the document to
be helpful and in reasonably good shape.

- RFC 2119 language

  This seems mainly used in the section about attestations. Do we
  really need RFC 2119 terms in this architecture document? Some of
  the SHALLs do not seem to be really needed.

- UA == CA ?

  The introduction introduces UA but then this is only used again once
  in 5.2. Given that section 2 starts with defining CA, is CA the same
  as UA (and hence UA should be replaced with CA)?

- root of trust

  This definition remains a bit unclear and it ends with an ad-hoc
  reference to a NIS draft. I searched for RoT in the document but it
  is not widely used. Perhaps this term can even be replaced by simply
  expanding the definitions of TFW a bit?

- acronyms and terms

  I notice that not all terms for which acronyms are defined at the
  end of section 2 are actually defined terms. Perhaps they should all
  be defined? Missing are TAM (Trusted Application Manager) and SD
  (Security Domain). The later one (SD) in particular would benefit
  from a definition.

- assumptions

  Does it make sense to have a top-level section consisting of just two
  sentences? Perhaps move this into a subsection of the architecture
  section?

- #notionalarch

  What is #notionalarch? A broken reference to Figure 1?

- typo caption figure 2

  s/wtih/with/

- typo 5.5

  s/would required/would require/
  s/recieve/receive/

- typo 5.7

  s/may different/may be different/

- trust anchors

  It seems that managing trust anchors will be crucial in order to
  deal with 'crypto gone wrong' scenarios. Is it really smart to leave
  management and updates to proprietary mechanisms? Why can't trust
  anchors not be managed like other TEE data? What is the reason to
  declare this out of scope - too complex? too hard to find agreement?
  Will trust anchor changes cause installed TAs to be removed if they
  lost their trust?

- message security

  It may help to clarify what the 'ends' are in the statement
  "messages are signed end-to-end". In particular, is the end the TEEP
  Agent and the TAM?

- teep broker

  I am not sure what "A shared module in REE comes to meet this need."
  tells me. What is a "shared module"? Perhaps the sentence can simply
  be removed.

  I am not sure the text is really clear. There are two kinds of
  interactions, a CA needing a TA to be made available and CA using a
  TA. I assume the first goes with the TEEP broker but the later via
  REE OS mechanisms. Or does the TEEP broker provide the single
  interface via which CAs request TA services?

- attestation

  "but the OTrP protocol SHALL allow" - this is the first time OTrP
  shows up and RFC 2119 language is used; did you mean to say a TEEP
  protocol? or something like that?

- crypto properties

  Does it really make sense to fix digital signature formats in an
  architecture document? The list of formats will likely change over
  time; so it is good to define MUST for today's blessed list?

- figure teep attestation layout

  Perhaps change the layout such that the claims are listed one below
  the other instead of next to each other (this way things may fit
  into the space - yes, I am still using 80 column terminals).

- typo attestation flow

  s/Attesations/Attestations/

- security

  Why does that text say "should be validated" instead of "must be
  validated"?

  What is the GetTAInformation function discussed in the security
  considerations? It seems to fall out of the air.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>