Subject: Re: [Id-event] Push Delivery: working group last call

From: Mike Jones <[email-masked]>
Date: Sat, 9 Mar 2019 17:45:48 +0000

Here’s my review of draft-ietf-secevent-http-push-04.

Abstract – Delete the comma after “recipient”.

1.2 Definitions – Delete “as defined in [RFC8417]” as this was already cited in the introductory sentence.

1.2 Definitions – Delete entire “SET Recipient” definition, as this is already defined in RFC 8417.

2. SET Delivery – “SET Transmission Request” sounds like a defined term, but isn’t defined.  Please lowercase “transmission request”.

2. SET Delivery – Delete the comma after “acknowledging successful transmission of the SET”.

2. SET Delivery – Change “SET issuer” to “SET Issuer” in the fourth bullet (and wherever else it’s in lowercase).

2. SET Delivery – In “The mechanism for validating the authenticity of a SET is implementation specific” change “implementation specific” to “use case specific” or “deployment specific”, as it’s the use case that defines the validation rules – not the implementation.

2.1 Transmitting a SET – Change “may be implementation-specific” to “are use case specific”.

2.1 Transmitting a SET – Delete the second space in “POST /Events  HTTP/1.1”.

2.1 Transmitting a SET – Delete the signature value “c2lnbmF0dXJl” from the example JWT, since “alg”:”none” signatures must be empty.

2.2 Success Response – Delete the quotation marks around “acknowledge”.

3. Authentication and Authorization – Add a comma before “as per [RFC7235]”.

5.2 TLS Support Considerations.  Saying that a transport-layer security mechanism is REQUIRED when SETs contain PII is unnecessarily heavy-handed.  The SET could be JWE-encrypted, in which case the PII is already protected – so no transport-level security mechanism is needed in that case.  Please reword this to say that PII must be protected with encryption, either by using an encrypted SET or by using transport-level encryption.

7.1.1 Registration Template, Error Code – Please change the allowed characters to match those allowed in OAuth 2.0 “error” values.  See https://tools.ietf.org/html/rfc6749#appendix-A.7.

7.1.1 Registration Template, Change Controller – Change “Secevent” to “SecEvent”.

7.1.2 Initial Registry Contents, invalid_request – Delete the comma after “parsed as a SET”.

7.1.2 Initial Registry Contents, invalid_key – Delete the period between “SET Recipient” and “(e.g.” and add a period at the end of the description.

7.1.2 Initial Registry Contents, access_denied – Delete the word “provided”, as it is confusing and adds no actionable information.

Appendix A, Other Streaming Specifications – Add text saying that the working group is also defining the Poll transmission mechanism and reference draft-ietf-secevent-http-poll.  Perhaps include the description of this functionality from the abstract of the specification.

                                                       Thanks,
                                                       -- Mike

From: Dick Hardt <[email-masked]>
Sent: Thursday, January 24, 2019 10:11 AM
To: SecEvent <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Annabelle Richard <[email-masked]>; Mike Jones <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>; Anthony Nadalin <[email-masked]>; Marius Scurtescu <[email-masked]>
Subject: Push Delivery: working group last call

Dear SecEvent participants,

This is to start a 2-week working group last call on draft-ietf-secevent-http-push-04

https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/

until Feb 8, 2019.

Please send any comments to the list. In addition, if you have no comments but support publication of this document as-is, please make your voice heard.

Thanks,

     Dick and Yaron

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Mar 2019 03:44:29 +0000

Having just finished editing the Poll spec, I’d like to add these points to my review of the Push spec.

5.2 TLS Support Considerations – Please change the sentence “In such cases, SET Transmitters and SET Recipients MUST require the use of a transport-layer security mechanism” to “In such cases, SET Transmitters and SET Recipients MUST encrypt the SET, either with a transport-layer security mechanism, with JWE <xref target="RFC7516"/>, or both”.  This will address my comment below and will match the corresponding text in draft-ietf-secevent-http-poll-02.

Acknowledgments – Delete the colon before draft-hunt-scim-notify-00 (matching a change to poll).

Acknowledgments – Change “the the SECEVENTS” to “the SecEvents” (matching a change to poll).

                                                       Thanks,
                                                       -- Mike

From: Mike Jones
Sent: Saturday, March 9, 2019 9:46 AM
To: 'Dick Hardt' <[email-masked]>; SecEvent <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Annabelle Richard <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>; Anthony Nadalin <[email-masked]>; Marius Scurtescu <[email-masked]>
Subject: RE: Push Delivery: working group last call

                                                       Thanks,
                                                       -- Mike

From: Dick Hardt <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, January 24, 2019 10:11 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Annabelle Richard <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; Anthony Nadalin <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Subject: Push Delivery: working group last call

until Feb 8, 2019.

Thanks,

     Dick and Yaron

---

From: John Bradley <[email-masked]>
Date: Wed, 27 Mar 2019 09:34:39 +0100

+1

On Mon, Feb 4, 2019, 7:43 PM Marius Scurtescu <marius.scurtescu=
[email-masked]> wrote:

> I support the publication of this document, with the changes suggested by
> Yaron Shefer and Annabelle Richard Backman..
>
> On Fri, Jan 25, 2019 at 1:04 PM Yaron Sheffer <[email-masked]>
> wrote:
>
>> Thanks for the quick response! A few comments inline.
>>
>> On 25/01/2019 22:18, Richard Backman, Annabelle wrote:
>> > Thanks for the feedback! Responses inline.
>> >
>> > --
>> >
>> > Annabelle Richard Backman
>> >
>> > AWS Identity
>> >
>> > On 1/25/19, 9:59 AM, "Id-event on behalf of Yaron Sheffer"
>> > <[email-masked] on behalf of [email-masked]
>> <yaronf.ietf@gmail..com>> wrote:
>> >
>> >      The document looks good. Here's a bunch o' comments.
>> >
>> >      * Intro: receipt->recipient
>> >
>> > [richanna]👍[/richanna]
>> >
>> >      * "The transmitter and recipient are known to one another." But
>> > then we
>> >
>> >      require the *issuer* to be authenticated by the Recipient. We need
>> to
>> >
>> >      clarify the relationship between Issuer (defined in the base spec)
>> and
>> >
>> >      Transmitter. BTW, Issuer should be capitalized.
>> >
>> > [richanna]
>> >
>> > The intent of that sentence is to indicate that the spec assumes the
>> > Transmitter already knows who it needs to transmit the SET to, and the
>> > Recipient knows who it expects to receive SETs from, and that discovery
>> > of either is out of scope.
>> >
>> > You’re absolutely right. Section 2 is missing a validation step: “The
>> > SET Recipient is willing to accept the SET, when transmitted by the SET
>> > Transmitter.” Also, we can add text to the definition of SET
>> Transmitter
>> > to clarify that it need not be the Issuer of the SET.
>> >
>> > [/richanna]
>> >
>> >      * "a decryption failure that may be due to misconfigured keys" -
>> > this is
>> >
>> >      a strange reason for retransmission, because it would normally
>> > require a
>> >
>> >      very slow manual operation, which could easily overwhelm the
>> > Transmitter.
>> >
>> > [richanna]
>> >
>> > I had in mind issues or delays with key propagation after a rotation,
>> > premature rejection of an outgoing key due to clock skew, intermittent
>> > failure when retrieving a Transmitter’s public key, etc. These are
>> > issues that may (depending on root cause) work themselves out after a
>> > few minutes, though I suppose they are not properly “misconfigured
>> > keys.” This example is probably just muddying the waters without
>> > contributing much to the text.
>> >
>> > [/richanna]
>> >
>> >      * "Transmitting a SET": if the normal response has an empty body,
>> > why do
>> >
>> >      we send "Accept: application/json"? The Accept header is not
>> > mandatory,
>> >
>> >      https://tools.ietf.org/html/rfc7231#section-5.3.2
>> >
>> > [richanna]
>> >
>> > Error responses will contain a JSON-formatted body, which the
>> > Transmitter MUST be prepared to accept.
>> >
>> > [/richanna]
>>
>> YS: I still think the Accept header is redundant (in particular because
>> if you cannot understand JSON, you cannot use this protocol at all), but
>> I can live with it.
>>
>> >
>> >      * "Failure Response": why is responding with the right HTTP status
>> > code
>> >
>> >      a MAY? What else do we expect them to do?
>> >
>> > [richanna]
>> >
>> > As I understand it, HTTP Servers have some discretion with regards to
>> > which status codes they respond with in certain situations. The “right
>> > HTTP status code” can be subjective, and may change over time as new
>> > status codes are defined for specific cases. SET Transmitters need to
>> be
>> > prepared to receive standard HTTP status codes, but I don’t see a
>> reason
>> > to impose more requirements on the SET Recipient in this area than HTTP
>> > itself does.
>> >
>> > [/richanna]
>> >
>>
>> YS: I agree with everything you say, but still, this would be more
>> correct: "the SET Recipient SHOULD respond with an appropriate HTTP
>> Status Code", even if the "appropriate" code is very fuzzy. Or else,
>> let's remove the RFC 2119 word: "the Recipient responds".
>>
>> >      * "the SET Transmitter is not permitted to transmit SETs issued by
>> the
>> >
>> >      issuer specified in the SET" - I suggest to change the text to
>> > indicate
>> >
>> >      this is from the point of view of the Recipient: "the Recipient is
>> not
>> >
>> >      willing to accept SETs issued by the specified issuer from this
>> >
>> >      particular SET Transmitter".
>> >
>> > [richanna]👍[/richanna]
>> >
>> >      * Error codes: what if the Recipient expects the SET to be
>> protected
>> >
>> >      (e.g. signed) but it is not? Is this "authentication_failed"?
>> >
>> > [richanna]
>> >
>> > SET signatures authenticate the Issuer, not the Transmitter, so
>> > `authentication_failed` would be inappropriate. The Recipient should
>> > return `access_denied` as it is unwilling to accept this SET from this
>> > Transmitter. Now I’m actually wondering if there is a difference
>> between
>> > `invalid_request` and `access_denied` that is meaningful at runtime.
>> > I’ll start a thread on this.
>> >
>> > [/richanna]
>> >
>> >      * "MUST support TLS 1.2" - we should allow for a future where TLS
>> >
>> >      1.3-only is acceptable. So, "MUST support TLS 1.2 or later".
>> >
>> > [richanna]👍[/richanna]
>> >
>> >      * IANA: the Expert Review policy requires a designated expert,
>> >
>> >      obviously. Since this is the only SecEvent registry that needs it
>> so
>> >
>> >      far, I'd rather go for the simpler FCFS policy.
>> >
>> > [richanna]
>> >
>> > 👍, though I think we should add text to the effect of “Error Codes are
>> > intended to be interpreted by automated systems, and therefore SHOULD
>> > identify classes of errors in response to which an automated system
>> > could take some distinct action.”
>> >
>> > [/richanna]
>>
>> YS: guidance is always good.
>>
>> >
>> >      Thanks,
>> >
>> >                  Yaron
>> >
>> >      On 24/01/2019 20:11, Dick Hardt wrote:
>> >
>> >      > This is to start a 2-week working group last call
>> >
>> >      > on draft-ietf-secevent-http-push-04
>> >
>> >      >
>> >
>> <https://datatracker.ietf..org/doc/draft-ietf-secevent-http-push/>
>> >
>> >      >
>> >
>> >      > until Feb 8, 2019.
>> >
>> >      >
>> >
>> >      > Please send any comments to the list. In addition, if you have no
>> >
>> >      > comments but support publication of this document as-is, please
>> >
>> >      > make your voice heard.
>> >
>> >      >
>> >
>> >      > Thanks,
>> >
>> >      >
>> >
>> >      >       Dick and Yaron
>> >
>> >      _______________________________________________
>> >
>> >      Id-event mailing list
>> >
>> >      [email-masked]
>> >
>> >      https://www.ietf.org/mailman/listinfo/id-event
>> >
>>
>> _______________________________________________
>> Id-event mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/id-event
>>
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>