Re: [Teep] I-D Action: draft-ietf-teep-protocol-09.txt

[Dave Thaler <[e-mail]>]

Thanks Michael!
BTW you can find the document's github repo by going to
https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/
and clicking on "GitHub Repository" under Additional Resources.

Dave

> -----Original Message-----
> From: TEEP <[e-mail]> On Behalf Of Michael Richardson
> Sent: Saturday, July 30, 2022 7:48 PM
> To: [e-mail]
> Subject: Re: [Teep] I-D Action: draft-ietf-teep-protocol-09.txt
> 
> 
> I took a look through draft-ietf-teep-protocol.
> This might be my first reading in a long time.
> I'm sorry I missed the WG session... conflicts.
> I did my annotations here, which might be amusing for some:
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhyp.is
> %2Fgo%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Farchive%252Fid
> %252Fdraft-ietf-teep-protocol-
> 10.html%26group%3D__world__&amp;data=05%7C01%7Cdthaler%40microso
> ft.com%7C4fe60e5bd0914125cb6b08da7285f084%7C72f988bf86f141af91ab2d
> 7cd011db47%7C1%7C0%7C637948217660929122%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C2000%7C%7C%7C&amp;sdata=aJfigtXvG9VcmZcW2OzDPCaAVk0T5cf
> kkL88HYJMSPQ%3D&amp;reserved=0
> 
> I'd send issues/PRs, but I didn't find a venue for the document.
> 
> section 4.2:
> } The TAM SHOULD set an expiration time for each token and MUST ignore any
> } messages with expired tokens. The TAM MUST expire the token value after }
> receiving the first response containing the token value and ignore any }
> subsequent messages that have the same token value.
> 
> I guess this is a defense against replays.
> I guess this document hasn't told me if it's over HTTP or carrier pigeon yet :-)
> How does the TAM know that the *first* isn't invalid?
> I guess it has already validated the message, so it must be okay.
> This isn't a replay window here.  Some motivation for what attack we are
> resisting here would be good.
> 
> section 4.3:
> } The absence of this parameter indicates that the format is "application/eat-
> cwt; }
> profile=https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-teep-protocol-
> 10&amp;data=05%7C01%7Cdthaler%40microsoft.com%7C4fe60e5bd0914125c
> b6b08da7285f084%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
> 948217660929122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&a
> mp;sdata=bMzC5S5idwvv3oV9HrEDdh%2BAVTqsOKz2fcOMkMfMGZE%3D&a
> mp;reserved=0
> } (RFC-editor: upon RFC publication, replace URI above with }
> "https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .rfc-
> editor.org%2Finfo%2FrfcXXXX&amp;data=05%7C01%7Cdthaler%40microsoft.c
> om%7C4fe60e5bd0914125cb6b08da7285f084%7C72f988bf86f141af91ab2d7c
> d011db47%7C1%7C0%7C637948217660929122%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C2000%7C%7C%7C&amp;sdata=d5K34pG8S7BU7rWs7wOu18Bj7cCTEXz
> NV7Qcr5%2FVsBQ%3D&amp;reserved=0" where XXXX is the RFC number of }
> this document.) It MUST be present if the attestation-payload parameter is }
> present and the format is not an EAT in CWT format with the profile defined }
> below in Section 5.
> 
> If we revise this document rfcXXXX-bis, then what will the absense of the
> payload format mean?
> It feels like premature optimization to set a default here.
> I think that the profile should always be present, or never present.
> 
> section 4.3.1:
> } When an Entity Attestation Token is used
> 
> ... and when EAT is not used?
> There are quite a number of places where the document says "when EAT..."
> and
> to me they read like stealth SHOULDs.   I understand that the document wants
> to
> enable other attestation systems other than EAT, and I'm okay with that.
> I'm not sure what to suggest, but it feels like a documentation bug.
> 
> such as:
>  section 5:
>  } While the TEEP protocol does not require use of EAT, use of EAT is  }
> encouraged and Section 4.3
> 
>  mcr: Need to list alternatives and reasons not to use EAT.
> 
> 
> section 4.4:
> } It can also be used to pass a successful Attestation Report back to the } TEEP
> Agent when the TAM is configured as an intermediary between the TEEP }
> Agent and a Verifier, as
> 
> this is another case where I think "when" is being used when SHOULD ought to
> be used.  Then it would be obvious that there is a case "when the TAM is not
> configured", and why would someone do A or ~A here?
> 
> section 4.4.1:
> } Example 1: Having one SUIT Manifest pointing to a URI of a Trusted
> Component Binary
> 
> I don't like them being called examples. They aren't things I can ignore.
> I think that they are usage scenarios, and there seem to be four important
> ones.
> 
> section 4.4.1:
> } The device must fetch the Trusted Component Binary in another connection }
> after receiving an Update message
> 
> I'd add an additional CON, and bring it up in Privacy Consideration.
>   The device must reveal eis location to the Trusted Binary server.
> 
> section 6:
> } Since the word "key" is mainly used in its other meaning, as a } cryptographic
> key, this specification uses the term "label" for this usage as } a map key.
> 
> Is this something that EAT should say?
> 
> section 7.1.2:
> } Hence, depending on the freshness mechanism in use, the TAM may need to
> } store data (e.g., a nonce) for some time.
> 
> This also suggests that for mobile devices that it may be hours to days before
> before right things are installed if they require unmetered WIFI to get the right
> pieces. The mobile device might change IP addresses and even geographies.
> 
> (I was thinking based upon some travel in 2019 that someone with a mobile
> device in some restrictive localities may find they have to change to their
> roaming SIM card in order to appear in their "home" country, at which point
> they might even wind up with a different set of requirements)
> 
> I'm also concerned about the number of dependancies upon other documents
> in other WGs that do not seem at all close to completing.  The dependancy
> graph might be useful, and "you" TEEP folks might have to organize
> interventions in other WGs to get documents advanced!
> 
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>