Push-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-push-14

[[ questions ]]

[ section 2.4 ]

* If the SET Issuer is not recognized as an issuer the recipient likes, what
  err string is best?  Most of the listed codes seem plausible in some small
  way, which lead me to think that either I'm confused or just a small bit of
  text might be added to one of the entry's description.

[ section 5.4 ]

* Is rate-limiting problematic transmitters also a reasonable approach?

[ section 5.5 ]

* Would it not also suffice to record in storage the relevant information from
  from the transmission context?

Section 2:
* "SET parsing and issuer and ..." -- s/parsing and/parsing,/
* I'm struggling a bit with the SHOULD and SHOULD NOT in the final paragraph.  When would you legitimately re-transmit a delivered SET, or not delay re-transmission after a failure?

Section 2.1:
OLD:
   ... request to an HTTP endpoint using TLS provided by the SET Recipient.
NEW:
   ... request to a TLS-enabled HTTP endpoint provided by the SET Recipient.

* This section makes several references to "header" that I think should be "header field".

Section 2.3:
* Same issue with the SHOULD in the first paragraph: When would you not use an appropriate HTTP response code?
* I think the "MAY" in the "description" bullet is superfluous, since you're describing interoperability with a human at this point.
* Same issue with "header" here, with three instances in this section.
* I suggest that the example figures in this section should be indented.  One of them is actually outdented.
* "example non-normative" should be "non-normative example", with three instances in this section.

Section 2.4:
* The table here is effectively a copy of the table in Section 7.1.2.  Could we just replace this section with a forward reference?

Section 4:
* "... always retry failed transmissions, however, it should ..." -- "however" should start a new sentence, or at least the first comma should be a semi-colon
* More generally, I wonder if leaving the "retryability" (I wish that was a word) to the discretion of an implementation, which feels mushy, could be improved.  In SMTP and various other protocols there's an indication, as part of the reply, that tells the client whether a failure might succeed later on a retry (say, a local resource limitation that might clear) versus one that will presumably never succeed (no such user here).  The DNS makes the same distinction.  For example, including in the registry a column indicating whether a response is indicating a temporary or permanent condition might be useful, or it could be a formalized part of the JSON reply.

Section 5.5:
* "... systems that the SET Recipient forwards the SET onto ..." -- suggest "... systems to which the SET Recipient forwards the SET ..."

Section 6:
* The variable use of "should" and "SHOULD" here made me look a bit sideways at this section.  They all "feel" the same, so the variance seems odd.

Section 7.1.1:
* For "Error Code", this set of restrictions allows me to register a code called "_".  Do you want more restrictions here?
* "For error codes registered by the IETF or its working groups, list "IETF SecEvent Working Group"." -- What if it was some other working group?

Thanks for responding to the SECDIR review (and thanks to Valery Smyslov for doing it).

Thanks for addressing all of my COMMENT items.

Like Eric and Erik, I was unclear on the "known to one another" bit, but it feels like this horse has now been sufficiently beaten...

I would like to draw your attention to the OpsDir comments (thanks Joe!), which have some nits that should be addressed - https://datatracker.ietf.org/doc/review-ietf-secevent-http-push-10-opsdir-lc-clarke-2020-05-14/

Thank you for the work put into this document. 

I have a single non-blocking comment about section 1: Suggest to clarify 'known to one another', what is meant by 'known' in this context? A reader could understand it as 'known IP address' or ...

Regards

-éric

This document (and draft-ietf-secevent-http-poll) should be tagged as replacing draft-ietf-secevent-delivery.

— Section 1 —
I agree with Éric’s comment that “known to one another” should be better explained — just something brief.

   Push-based SET delivery over HTTP POST is intended for scenarios
   where all of the following apply:

Is it the intent that push be used in all such cases, and pull in all others?  It would be good to explicitly say that, perhaps by adding “(with pull-based SET delivery used in all other cases)” to the above.

— Section 2 —

   o  The SET is authentic (i.e., it was issued by the issuer specified
      within the SET, and if signed, was signed by a key belonging to
      the issuer).

If the SET is not signed, how is authenticity determined and validated?  I understand that the specifics are out of scope for this document, but I’m trying to understand in general how this works.

   o  The SET Issuer is recognized as an issuer that the SET Recipient
      is willing to receive SETs from (e.g., the issuer is whitelisted
      by the SET Recipient).

Let’s get a head start on the movement away from “whitelist/blacklist” and change this to “is listed as allowed by the SET Recipient”, or some such.  What do you think?

   o  The SET Recipient is willing to accept the SET when transmitted by
      the SET Transmitter (e.g., the SET Transmitter is expected to send
      SETs with the subject of the SET in question).

It took me a couple of reads to understand what this is getting at.  Maybe this clarifies a little?:

NEW
   o  The SET Recipient is willing to accept this SET from this SET
      Transmitter (e.g., the SET Transmitter is expected to send
      SETs with the subject of the SET in question).
END

   The SET Transmitter MAY re-transmit a SET if the responses from
   previous transmissions timed out or indicated potentially recoverable
   error

Nit: “errors”

— Section 2.1 —

   To transmit a SET to a SET Recipient, the SET Transmitter makes an
   HTTP POST request to an HTTP endpoint using TLS provided by the SET
   Recipient.

How is TLS provided by the SET Recipient?
Or, perhaps, do you mean, “makes an HTTP POST request using TLS to an HTTP endpoint provided by the SET Recipient.”?

— Section 2.2 —

   Before acknowledgement, SET Recipients SHOULD ensure they have
   validated received SETs

Section 2 says, “Upon receipt of a SET, the SET Recipient SHALL validate”, so how does that work with the SHOULD here?  I think this is a problem with repeating normative statements: making sure they remain completely consistent.

— Section 2.4 —

   |                       | unacceptable to the SET Recipient. (e.g., |
   |                       | expired, revoked, failed certificate      |
   |                       | validation, etc.)                         |

Nit: “e.g.” and “etc.” used together is redundant; I suggest removing the former.

   Implementations SHOULD expect that other Error Codes may also be
   received, as the set of Error Codes is extensible

I suggest not using a 2119 key word here.  This isn’t really a SHOULD: an implementation that can’t tolerate extensions will be limited and eventually considered broken.  I think it’s better to just say this as a statement, beginning the sentence with the word “Other”.

— Section 3 —

   The TLS server certificate
   MUST be validated, per [RFC6125].

Is DANE (RFC 6698) not allowed?  Or should this be worded differently?  This also applies to the reference to cert validation in Section 5.3.

— Section 7.1 —

   Future assignments are to be made
   through the Specification Required registration policy

Please provide some brief guidance to the designated experts.  Thanks.

— Section 7.1.1 —

   Change Controller
      For error codes registered by the IETF or its working groups, list
      "IETF SecEvent Working Group".

Nit: This isn’t consistent with Section 7.1.2, nor with current practice.  It should just say “IETF”.

Hi,

I found this document easy to read.  A few minor nits:

1.2.  Definitions

   This specification utilizes the following terms defined in [RFC8417]:
   "Security Event Token (SET)", "SET Issuer", "SET Recipient", and
   "Event Payload".

   This specification utilizes terminology defined in [RFC8417], as well
   as the terms defined below:

This text could probably be simplified/made slightly less repetitive.

2.  SET Delivery

   Once the SET has been validated and persisted, the SET Recipient
   SHOULD immediately return a response indicating that the SET was
   successfully delivered.  The SET Recipient SHOULD NOT perform
   anything beyond the required validation steps prior to sending this
   response.  Any additional steps SHOULD be executed asynchronously
   from delivery, in order to minimize the expense and impact of SET
   delivery on the SET Transmitter.
   
Rather than "perform anything", perhaps "perform further processing of the SET"

Rather than "in order to minimize the expense and impact of SET
delivery on the SET Transmitter." perhaps "to minimize the time the SET Transmitter is waiting for a response".

2.2.  Success Response

   Note that the purpose of the acknowledgement response is to let the
   SET Transmitter know that a SET has been delivered and the
   information no longer needs to be retained by the SET Transmitter.
   Before acknowledgement, SET Recipients SHOULD ensure they have
   validated received SETs and retained them in a manner appropriate to
   information retention requirements appropriate to the SET event types
   signaled.  The level and method of retention of SETs by SET
   Recipients is out of scope of this specification.

The normative behaviour of retaining SETs is already specified in section 2.  It might be better to refer back to that previous paragraph rather than restating it here.

7.  IANA Considerations

Section 7.1.1 lists the change controller as "IETF SecEvent Working Group", but the examples just list "IETF".  Presumably one of these needs to change?

Regards,
Rob