[Gen-art] Genart last call review of draft-ietf-secevent-http-poll-09

Robert Sparks via Datatracker <noreply@ietf.org> Fri, 08 May 2020 18:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: gen-art@ietf.org
Delivered-To: gen-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C86513A0C18; Fri, 8 May 2020 11:56:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: <gen-art@ietf.org>
Cc: draft-ietf-secevent-http-poll.all@ietf.org, last-call@ietf.org, id-event@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.129.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158896421673.10670.4441228115784457096@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Fri, 08 May 2020 11:56:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/_Aitkm-ouoaBApZ0fcLnWkVJ3C4>
Subject: [Gen-art] Genart last call review of draft-ietf-secevent-http-poll-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 18:56:58 -0000

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


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

Is there a discussion somewhere of how long the transmitter is required
to hold a given SET for a Recipient? Forever seems unreasonable.