Subject: [Teep] draft-ietf-teep-protocol-05

From: Russ Housley <[email-masked]>
Date: Wed, 3 Mar 2021 15:56:11 -0500

In preparation for IETF 110, I read draft-ietf-teep-protocol-05.  I am writing to share my comments from that review.

TECHNICAL QUESTIONS AND SUGGESTIONS

In Section 4.2, tes discussion of token says:

      The TAM MUST expire the token value after receiving the first
      responce from the device and ignore any subsequent messages that
      have the same token value.

Should this say the first response that has a valid signature?  Otherwise, we are creating an opportunity for an attacker to quickly respond with a matching token but otherwise garbage.  Then a legitimate responder will be ignored.

In Section 4.2, the discussion of ocsp-data says: "certificates up to the root certificate".  I do not think we want an OCSP response for the trust anchor (a.k.a., root certificate).  I suggest: "certificates up, but not including, to the root certificate".

In Section 7, I think that future ciphersuites should allow MAC algorithms other than HMAC, such as GMAC.

In Section 9, please say whether future registrations will allow integrity-without-confidentiality ciphersuites.  Let's settle this now instead of dumping on the IANA Expert.

For the reference to OCSP, please use RFC 6960 (not RFC 2560).

The document talks about certificates, so it should reference RFC 5280.

EDITORIAL SUGGESTIONS

The document uses "trust anchor" and "root certificate".  Please pick one.  I greatly prefer trust anchor for alignment with RFC 5280.

In Section 3, the text says: "This specification defines five messages." For me, it would have been helpful for the five to be listed here before the description of the flows.  I suggest: "This specification defines five messages: QueryRequest, QueryResponse, Update, Success, and Error."

In Section 4.2: s/Listing supporting SUIT commands/Listing supported SUIT commands/

In Section 4.2: s/by the TAM A value of 0/by the TAM. A value of 0/

In Section 4.3, it says:

   tc-manifest-sequence-number
      The minimum suit-manifest-sequence-number value from a SUIT
      manifest for the Trusted Component.  If not present, indicates
      that any version will do.

Please reword to clarify the meaning of "version".  Elsewhere in this document, version is talking about the TEEP protocol version, but that is not the meaning here.

Russ

---

From: Dave Thaler <[email-masked]>
Date: Wed, 3 Mar 2021 21:06:21 +0000

> Should this say the first response that has a valid signature?  Otherwise, we are creating an opportunity for an attacker to quickly respond with a matching token but otherwise garbage.  Then a leg…

Yes, although there is also some discussion of possibly getting rid of the
token (but no consensus yet to do so) and using other mechanisms instead.

For the real answer to your question, section 6.1 second paragraph
says to drop the message if it is not valid according to the rules
in 4.1.2.  Section 4.1.2 explains that the TEEP message fields are only
looked at in step 6, so by the time you get to the text in section 4.2
you've already passed steps 1-5, so you get the meaning you stated.

> In Section 4.2, the discussion of ocsp-data says: "certificates up to the root certificate".  I do not think we want an OCSP response for the trust anchor (a.k.a., root certificate).  I suggest: "c…

Acknowledged.

> In Section 7, I think that future ciphersuites should allow MAC algorithms other than HMAC, such as GMAC.

Do you believe any text change is needed?

> The document talks about certificates, so it should reference RFC 5280.

Acknowledged.

> EDITORIAL SUGGESTIONS

Got them, thanks!

Dave

---

From: Russ Housley <[email-masked]>
Date: Wed, 3 Mar 2021 16:23:22 -0500

> Do you believe any text change is needed?

sure, just change "HMAC" to "MAC"

Russ