Poll-Based Security Event Token (SET) Delivery Using HTTP
Note: This ballot was opened for revision 11 and is now closed.
Alvaro Retana No Objection
This document (and draft-ietf-secevent-http-push) should be tagged as replacing draft-ietf-secevent-delivery.
Erik Kline No Objection
[[ 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
Murray Kucherawy No Objection
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
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
Thanks for addressing all of my COMMENTs.
Warren Kumari No Objection
Éric Vyncke No Objection
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
(Benjamin Kaduk; former steering group member) Yes
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.
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
— 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
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection