Reviewer: Kyle Rose
Review result: Has Issues
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.
This document is Almost Ready.
* The security issue outlined in section 13.5 ("Dishonest clients") adequately
justifies maintaining confidentiality of the full list of revoked hashes, or at
least of recent additions to the list, without reference to privacy as
mentioned in section 13.1. The privacy issues posed by hashes of tokens that
are not widely distributed or visible to passive observers are not at all clear
to me.
* Furthermore, doesn't the security issue identified in 13.5 imply that only
RSes should be notified of revocations, and clients left to wonder until their
requests are denied, or at least until after the RSes to which the token is
relevant have been notified? Secrecy matters really only because we want to
prevent bad actors with access to the token from taking advantage of it during
the window between revocation and RSes being aware of that revocation: if you
notify the bad actor proactively, it doesn't really matter that you kept it
secret from other nefarious observers. (Note that changing this would require
the changes to the recommendation from 13.4.)
For what it's worth, this is not a novel problem, and it is one that
plagues revocation systems in general. Moreover, all the possible
approaches are unsatisfying in some way, often relying on assumptions about
the state of mind/intent or expected behavior of the adversarial actor.
* I do not understand the criteria specified for purging hashes of revoked
tokens in section 10.1. In particular, why is the first criteria required? If
an RS never sees a particular token, this implies the hash would be kept
forever, or at least until memory pressure is encountered. Should the RS not
also be allowed to expunge a hash if the TRL endpoint signals removal via
expiry? At that point the token would be invalid anyway, revoked or not.
Other comments:
* I did not review the properties of, or analyze the correctness of, the
database consistency algorithm and associated update protocol used to keep
registered devices up-to-date with relevant token hashes. I do not know if this
algorithm and protocol were based on something specific, so if that is not the
case then my main observation would be that the consistency requirements here
are not unique to the proposed revocation function, so it may be worth
reviewing literature relevant to the problem space associated with database
view consistency across distributed and intermittently-connected devices to see
if there is something more generic that can be leveraged in solving this
problem.
* I also did not review any of the appendices.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
