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

From: Dick Hardt <[email-masked]>
Date: Thu, 24 Jan 2019 10:11:01 -0800

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: Yaron Sheffer <[email-masked]>
Date: Fri, 25 Jan 2019 19:58:32 +0200

The document looks good. Here's a bunch o' comments.

* Intro: receipt->recipient

* "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.

* "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.

* "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

* "Failure Response": why is responding with the right HTTP status code 
a MAY? What else do we expect them to do?

* "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".

* Error codes: what if the Recipient expects the SET to be protected 
(e.g. signed) but it is not? Is this "authentication_failed"?

* "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".

* 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.

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
> 
> 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: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 25 Jan 2019 20:18:52 +0000

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]> wrote:

[richanna]👍[/richanna]

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

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

[richanna]

Error responses will contain a JSON-formatted body, which the Transmitter MUST be prepared to accept.

[/richanna]

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

[richanna]👍[/richanna]

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

[richanna]👍[/richanna]

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

    Thanks,

                Yaron

    >       Dick and Yaron

    _______________________________________________

    Id-event mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/id-event

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 25 Jan 2019 12:25:03 -0800

Annabelle, let me know if you need any help with these changes.

On Fri, Jan 25, 2019 at 12:18 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> On 1/25/19, 9:59 AM, "Id-event on behalf of Yaron Sheffer" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> 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]
>
>
>
> 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]
>
>
>
> 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]
>
>
>
> 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]
>
>
>
> 👍, 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]
>
>
>
>     Thanks,
>
>                 Yaron
>
>
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 25 Jan 2019 23:04:12 +0200

Thanks for the quick response! A few comments inline.

On 25/01/2019 22:18, Richard Backman, Annabelle wrote:
> On 1/25/19, 9:59 AM, "Id-event on behalf of Yaron Sheffer" 
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> 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]
> 
> 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]
> 

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.

> 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".

> `authentication_failed` would be inappropriate. The Recipient should 
> return `access_denied` as it is unwilling to accept this SET from this 
> `invalid_request` and `access_denied` that is meaningful at runtime. 
> I’ll start a thread on this.
> 
> [/richanna]
> 
> identify classes of errors in response to which an automated system 
> could take some distinct action.”
> 
> [/richanna]

YS: guidance is always good.

>      > 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
>