Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-secevent-http-poll-09 Reviewer: Robert Sparks Review Date: 2020-05-08 IETF LC End Date: 2020-05-13 IESG Telechat date: Not scheduled for a telechat Summary: Essentially ready but with some issues to consider before publishing as a Proposed Standard RFC This document is well-written and easy to follow. I have a couple of edge-case issues that I think should be considered though: This document allows, and anticipates, deployments where Recipients are not well authenticated. See, for example, the first sentence of section 4.1. There is also an unstated expectation in the document that the jti of each SET is hard to guess. If it's reasonably easy to guess jti values, a malicious Recipient could ack SETs it has never received and the Transmitter will remove that state, preventing a valid Recipient from ever receiving that SET. If that's an explicit requirement in the jwt or SET base documents for the jti to be hard to guess, please point me to it? If there's not, perhaps a short discussion in the security considerations requiring this property would be worthwhile? Is there a discussion somewhere of how long the transmitter is required to hold a given SET for a Recipient? Forever seems unreasonable. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
