[Ace] Roman Danyliw's No Objection on draft-ietf-ace-revoked-token-notification-08: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-revoked-token-notification-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Dale Worley for the GENART review.

** Section 3.4
   The specifically used hash function MUST be collision-resistant on
   byte-strings, and MUST be selected from the "Named Information Hash
   Algorithm" Registry [Named.Information.Hash.Algorithm].

Is there isn’t any mandatory to implement algorithm, how is interoperability
expected?

** Section 6.  I’m having trouble understanding who the “full TRL” download is
for.

-- Section 13.1 says “The AS MUST ensure that ... only authorized and   
authenticated administrators can retrieve the full TRL (see Section 9).”

-- Section 13.2 cautions:

   If many non-expired access tokens associated with a registered device
   are revoked, the pertaining subset of the TRL could grow to a size
   bigger than what the registered device is prepared to handle upon
   reception of a response from the TRL endpoint, especially if relying
   on a full query of the TRL (see Section 6).

It is there an assumption that administrators are operating on constrained
devices to create issues with downloading the full TRL?

** Section 13.3

   In order to avoid this, a requester SHOULD NOT rely solely on the
   CoAP Observe notifications.  In particular, a requester SHOULD also
   regularly poll the AS for the most current information about revoked
   access tokens, by sending GET requests to the TRL endpoint according
   to a related application policy.

Are the requestors going to be constrained devices?  If so, both of these
approaches seem problematic for device will limited battery power – either the
device needs to stay awake to watch Observe notifications or it needs to poll.

** Section 13.5

   In order to minimize such a risk, if an RS relies solely on polling
   through individual requests to the TRL endpoint to learn of revoked
   access tokens, the RS SHOULD implement an adequate trade-off between
   the polling frequency and the maximum length of the vulnerable time
   window.

As above.  Would an RS ever be constrained because polling would impact the
battery life.