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

["Morteza Ansari (moransar)" <[e-mail]>]

The document looks pretty good. A few minor comments in addition to Yaron’s notes:

Section 5.4: Why not recommend signing and encrypting the SET’s in the security consideration (use stronger language than “optionally”)?

Section 6.0: While the recommendation of using hash value is great for privacy, wouldn’t it seriously impact interoperability without stronger language and semantics for when it is a hash vs. actual value? Feels we are punting on this and making it implementor’s problem to figure out.

Section 7.1.1: Shouldn’t the error code syntax also allow at least “_” character since we use it in our codes?


Cheers,
Morteza

From: Marius Scurtescu <[e-mail]>
Date: Monday, February 4, 2019 at 10:43 AM
To: Yaron Sheffer <[e-mail]>
Cc: "Richard Backman, Annabelle" <[e-mail]>, Dick Hardt <[e-mail]>, SecEvent <[e-mail]>, Anthony Nadalin <[e-mail]>, Mike Jones <[e-mail]>, Marius Scurtescu <[e-mail]>, Morteza Ansari <[e-mail]>, Phil Hunt <[e-mail]>
Subject: Re: [Id-event] Push Delivery: working group last call

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 <[e-mail]<mailto:[e-mail]>> 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"
> <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> 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:
>
>      > 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
>
>      _______________________________________________
>
>      Id-event mailing list
>
>      [e-mail]<mailto:[e-mail]>
>
>      https://www.ietf.org/mailman/listinfo/id-event
>

_______________________________________________
Id-event mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event