Poll-Based Security Event Token (SET) Delivery Using HTTP
draft-ietf-secevent-http-poll-12

Note: This ballot was opened for revision 11 and is now closed.

Benjamin Kaduk Yes

Comment (2020-06-16 for -11)
Prompted by Mark Notthingham's comments, we should perhaps leave some
breadcrumbs that -push has discussion of alternatives considered and rejected,
though this is less important if that section is to be removed prior to
publication as an RFC.

It may be worth mentioning explicitly in Section 1 that one of the pieces of
configuration metadata to be exchanged includes the
authentication/authorization information for the Recipient, or to discuss
Recipient authentication/authorization in Section 3 where server (i.e.,
Transmitter) authentication is covered.

When we reference RFC 6125, we only mention the DNS-ID name type in Section
4.3 but not in Section 3.  As for -push, we don't necessarily need to mention
it in both places, but it might be nice to be consistent or to remove some of
the redundancy.

Section 5

As for -push, I think both SET Issuers and Transmitters (not just one or the
other) should consider the ramifications of sharing a particular SET.  While
it's true that (as the secdir reviewer of -push noted) when JWE is used the
Issuer has sole knowledge/control, but in other cases the Issuer may not know
the full recipient list.

Alvaro Retana No Objection

Comment (2020-06-23 for -11)
This document (and draft-ietf-secevent-http-push) should be tagged as replacing draft-ietf-secevent-delivery.

Erik Kline No Objection

Comment (2020-06-23 for -11)
[[ questions ]]

[ section 2.4.2 ]

* What should happen with an ACK-only request that has maxEvents: 0 and
  returnImmediately: false?

  Should the default value of returnImmediately be !maxEvents?

Martin Duke No Objection

Martin Vigoureux No Objection

Murray Kucherawy No Objection

Comment (2020-06-17 for -11)
A couple of questions arise for me about the use of requirements language:

Section 2.1:
* Under what circumstances would you not follow the advice of that SHOULD?

Section 2.2:
* "... the oldest SETs available SHOULD be returned first." -- why is that only a SHOULD?

Section 2.4:
* "... SHOULD parse and validate received SETs to meet its own requirements ..." -- when would you not do this?

And a nit:

Section 2.2:
* "An OPTIONAL JSON integer value ..." -- JSON defines "number", not "integer"; I understand what you mean, but that distinction has drawn complaints on previous documents.

Robert Wilton No Objection

Comment (2020-06-22 for -11)
Hi,

I found that document easy to read/understand (despite not really knowing what "SET"s are).  However, I did have a query about the algorithm:

It seems to me that if a client fails to acknowledge a SET (e.g. due to a bug, or perhaps a message is lost) then it has to wait until the server times out waiting for the SET acknowledgement before the server hopefully resends it.

However, I would normally expect that a client should automatically acknowledge all SETs in the order that it receives them because it doesn't seem to have a good reason not to do so.  Hence, I was wondering whether it would be useful to have an option to allow clients to request that the next "maxEvents" SETs also include any unacknowledged SETs?  This would allow clients to potentially recover lost SETs more quickly and more robustly?  I.e. for the case where a client expects to acknowledge all existing received SETs before/when requesting more.

Regards,
Rob

Roman Danyliw No Objection

Comment (2020-06-25)
No email
send info
Thanks for addressing all of my COMMENTs.

Warren Kumari No Objection

Éric Vyncke No Objection

Comment (2020-06-23 for -11)
Thank you for the work put into this document. It is easy to read.

I have a non-blocking question about section 2.2: for constrained devices, it would probably be useful to also set a maxSize (in bytes) for the returned SET(s). Was this considered ?

Regards

-éric

(Alissa Cooper; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Barry Leiba; former steering group member) No Objection

No Objection (2020-06-24 for -11)
— Section 1 —
Section 1 of the push draft explains that push is meant to be used under specific circumstances.  Is it the intent that push be used for those cases, and pull be used for everything else?  It might be good to say that explicitly here, perhaps as, “This is an alternative SET delivery method to the one defined in [I-D.ietf-secevent-http-push], and is used for cases where push-based delivery does not apply.”

— Section 2 —

   The SET Recipient MUST acknowledge
   receipt to the SET Transmitter, and SHOULD do in a timely fashion

Nit: “SHOULD do so”

— Section 2.1 —

   Before acknowledgement, SET Recipients SHOULD ensure that received
   SETs have been validated

Same comment as in -push: validation is a SHALL, and this says SHOULD.  But see my comment below for Section 2.4.

— Section 2.2 —

      maxEvents
         An OPTIONAL JSON integer value indicating the maximum number of
         unacknowledged SETs that SHOULD be returned.

The antecedent to SHOULD is unclear.  Are you really saying that the SETs SHOULD be returned?  Or do you mean that the SHOULD applies to the maximum number?  Assuming the latter, it’s better said this way:

NEW
      maxEvents
         An OPTIONAL JSON integer value indicating the maximum number of
         unacknowledged SETs to be returned.  The SET Transmitter SHOULD
         NOT send more SETs than the specified maximum.
END

         Recipients that would like to perform an acknowledge only
         request.

Nit: hyphenate “acknowledge-only”

— Section 2.4 —

   If the SET Recipient has received SETs from the SET Transmitter, the
   SET Recipient SHOULD parse and validate received SETs

Is it intended that validation is a SHALL in push and a SHOULD in pull?  If so, why?  Is it worth explaining that in the documents?

— Section 3 —

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

Same comment as in -push: what about DANE?  (Also for Section 4.3)

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -11)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -11)
No email
send info