Skip to main content

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

Yes


No Objection

Warren Kumari
(Alissa Cooper)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Duke)
(Martin Vigoureux)

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

Erik Kline
No Objection
Comment (2020-06-23 for -11) Sent
[[ 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?
Murray Kucherawy
No Objection
Comment (2020-06-17 for -11) Sent
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.
Roman Danyliw
No Objection
Comment (2020-06-25) Sent for earlier
Thanks for addressing all of my COMMENTs.
Warren Kumari
No Objection
Éric Vyncke
No Objection
Comment (2020-06-23 for -11) Sent
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 IESG member
Yes
Yes (2020-06-16 for -11) Sent
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 IESG member
No Objection
No Objection (for -11) Not sent

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2020-06-23 for -11) Sent
This document (and draft-ietf-secevent-http-push) should be tagged as replacing draft-ietf-secevent-delivery.
Barry Leiba Former IESG member
No Objection
No Objection (2020-06-24 for -11) Sent
— 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 IESG member
No Objection
No Objection (for -11) Not sent

                            
Magnus Westerlund Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Martin Duke Former IESG member
No Objection
No Objection (2020-06-25) Sent for earlier

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -11) Not sent

                            
Robert Wilton Former IESG member
No Objection
No Objection (2020-06-22 for -11) Sent
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