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

[Ballot comment]
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/

[Ballot comment]
— 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”.

[Ballot comment]
Thanks for responding to the SECDIR review (and thanks to Valery Smyslov for doing it)

** Section 2.1.  Per “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” didn’t parse right.  What does it mean to “us[e] TLS provided by …”?

** Section 5.3.  Recommend being clearer that using TLS is a MUST.
OLD
  In some use cases, using TLS to secure the transmitted SETs will be
  sufficient.  In other use cases, encrypting the SET as described in
  JWE [RFC7516] will also be required

NEW
    TLS MUST be used to secure the transmitted SETs.  In some use cases, also encrypting the SET as described in JWE [RFC7516] will be required.

** Section 5.3.  Per “SETs may contain sensitive information that is considered Personally Identifiable Information (PII).  In such cases …”, first off, I fully endorse and concur with the spirit here – being clear when you have sensitive information that confidentiality is a MUST requirement.  However, we need precision here – PII is a technical term in many jurisdictions, and the definition varies.  I wouldn’t want to make the normative guidance here conditional on this ambiguity.  I’d also note that Section 5.1. of RFC8417 refers to confidentiality requirements in the presence of third parties.  Combining these observations will the editorial item above, I recommend:

“SETs may contain sensitive information, to include Personally Identifiable Information (PII), or be distributed through third parties.  TLS MUST be  …”

** Section 5.3.  Per the reference RFC7525, I recognize that this sentence is identical to Section 5.1 of RFC8417.  Is there a reason why conformance to it (RFC7525) is not a MUST (e.g., to ensure guidance on ciphersuites)?  You’ve already covered TLS version numbers with text and certificate validation with RFC6125.

** Section 5.5.  Per “At the time of receipt, the SET Recipient can rely upon transport layer mechanisms …”, since this whole specification is about a particular “transport layer mechanisms”, what is are the specific details here – or is this out of scope?

[Ballot comment]
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

[Ballot comment]
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

[Ballot comment]
[[ 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?

[Ballot comment]
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?

[Ballot comment]
We mention DNS-ID in the context of RFC 6125 validation in Section 5.3, but
not in Section 3.  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 6

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 noted) when JWE is used the Issuer has sole
knowledge/control, but in other cases the Issuer may not know the full
recipient list.

Appendix A

(Some information leakage is possible even over the TLS channel, too.  Message
padding algorithms to prevent such side channels remain an open research
topic.)

To the IESG: note that Appenix B ("Other Streaming Specifications") is
currently slated for removal prior to publication.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-secevent-http-push-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the Security Event Token Delivery Error Codes registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Specification Required as defined in [RFC8126].

There are initial registrations in the new registry as follows:

Error Code: invalid_request
Description: The request body cannot be parsed as a SET or the
    event payload within the SET does not conform to the event's definition.
Change Controller: IETF
Reference: Section 2.4 of [[ this specification ]]

Error Code: invalid_key
Description: One or more keys used to encrypt or sign the SET is
      invalid or otherwise unacceptable to the SET Recipient. (e.g.,
      expired, revoked, failed certificate validation, etc.)
Change Controller: IETF
Reference: Section 2.4 of [[ this specification ]]

Error Code: authentication_failed
Description: The SET Recipient could not authenticate the SET
      Transmitter.
Change Controller: IETF
Reference: Section 2.4 of [[ this specification ]]

Error Code: access_denied
Description: The SET Transmitter is not authorized to transmit the
      SET to the SET Recipient.
Change Controller: IETF
Reference: Section 2.4 of [[ this specification ]]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-05-13):

From: The IESG
To: IETF-Announce
CC: Yaron Sheffer , draft-ietf-secevent-http-push@ietf.org, secevent-chairs@ietf.org, kaduk@mit.edu, yaronf.ietf@gmail.com, id-event@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Push-Based Security Event Token (SET) Delivery Using HTTP) to Proposed Standard


The IESG has received a request from the Security Events WG (secevent) to
consider the following document: - 'Push-Based Security Event Token (SET)
Delivery Using HTTP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-05-13. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This specification defines how a Security Event Token (SET) may be
  delivered to an intended recipient using HTTP POST.  The SET is
  transmitted in the body of an HTTP POST request to an endpoint
  operated by the recipient, and the recipient indicates successful or
  failed transmission via the HTTP response.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Yaron Sheffer. The responsible Area Director is Ben Kaduk.

This document defines an HTTP push-based protocol for delivery of Security Event Tokens (SETs, RFC 8417). This is one of the two options the working group is working on: push- vs. poll-based delivery.

2. Review and Consensus

The protocol is a simple and straightforward way to transmit SETs, and the working group supports it. Since we only have a small core of active participants, we ran into a problem while requesting formal indication of support, but eventually received enough messages in favor of publication to demonstrate consensus.

I have reviewed the document for this write-up, and my comments were incorporated into version -06 of the draft.

In addition there are multiple implementations, including one in production by Google (https://developers.google.com/identity/risc).

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

There is a normative downref to the obsolete RFC 5246, "TLS 1.2", which is appropriate in this specific context.

1. Summary

The document shepherd is Yaron Sheffer. The responsible Area Director is Ben Kaduk.

This document defines an HTTP push-based protocol for delivery of Security Event Tokens (SETs, RFC 8417). This is one of the two options the working group is working on: push- vs. poll-based delivery.

2. Review and Consensus

The protocol is a simple and straightforward way to transmit SETs, and the working group supports it. Since we only have a small core of active participants, we ran into a problem while requesting formal indication of support, but eventually received enough messages in favor of publication to demonstrate consensus.

I have reviewed the document for this write-up, and my comments were incorporated into version -06 of the draft.

In addition there are multiple implementations, including one in production by Google (https://developers.google.com/identity/risc).

3. Intellectual Property

Each author has confirmed conformance with BCP 78/79. There are no IPR disclosures on the document.

4. Other Points

There is a normative downref to the obsolete RFC 5246, "TLS 1.2", which is appropriate in this specific context.

Request for posting confirmation emailed to previous authors: Phil Hunt , Anthony Nadalin , Morteza Ansari , Annabelle Backman , secevent-chairs@ietf.org, Michael Jones , Marius Scurtescu