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

[John Bradley <[e-mail]>]

+1

On Mon, Feb 4, 2019, 7:43 PM Marius Scurtescu <marius.scurtescu=
[e-mail]> 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 <[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] on behalf of [e-mail]
>> <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:
>> >
>> >      > 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/
>> <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]
>> >
>> >      https://www.ietf.org/mailman/listinfo/id-event
>> >
>>
>> _______________________________________________
>> Id-event mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/id-event
>>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>