Thanks for your review, Robert. I'm working on addressing the review comments
received and wanted to have a clarifying discussion on some of yours before
deciding what corresponding edits to make.
I think there's a misunderstanding about "jti" values and the security model.
Because communication is over a TLS-protected channel between two parties, it
would be fine if the JTI values were totally guessable, such as "A", "B", "C",
etc. There's no opportunity for an attacker to inject traffic into or to
listen to the stream. Does that make sense to you?
As for limits on how long a transmitter is required to hold a SET, I propose to
add this text:
Transmitters may also discard undelivered SETs under deployment-specific
conditions,
such as if they have not been polled for over too long a period of time
or if an excessive amount of storage is needed to retain them.
-- Mike
-----Original Message-----
From: Id-event <id-event-boun...@ietf.org> On Behalf Of Robert Sparks via
Datatracker
Sent: Friday, May 8, 2020 11:57 AM
To: gen-art@ietf.org
Cc: last-c...@ietf.org; draft-ietf-secevent-http-poll....@ietf.org;
id-ev...@ietf.org
Subject: [Id-event] Genart last call review of draft-ietf-secevent-http-poll-09
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.
_______________________________________________
Id-event mailing list
id-ev...@ietf.org
https://www.ietf.org/mailman/listinfo/id-event
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
