Re: [Id-event] AD review of draft-ietf-secevent-http-push-07

[Mike Jones <[e-mail]>]

draft-ietf-secevent-http-push-08<https://tools.ietf.org/html/draft-ietf-secevent-http-push-08> was published to address these review comments.  (-09<https://tools.ietf.org/html/draft-ietf-secevent-http-push-09> addressed additional editorial nits.)  Descriptions of the changes made for these comments are inline, prefixed by "Mike>".



-----Original Message-----
From: Id-event <[e-mail]> On Behalf Of Benjamin Kaduk
Sent: Tuesday, December 10, 2019 4:36 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Id-event] AD review of draft-ietf-secevent-http-push-07



Hi all,



Due to the unfortunate delay in AD evaluation from my personal situation, I ended up being able to review push and poll side-by-side; this results in a couple places where we may want to update push with content from poll.  I've tried to keep such comments self-contained in the per-document reviews, though I expect that both authors and I will be consulting both documents during the course of the updates.



I think all of these should be fairly straightforward to address, so hopefully we can kick off IETF LC before the new year.





While I agree with the note in the shepherd writeup that it's appropriate to reference RFC 5246 specifically for TLS 1.2, we probably also want to reference RFC 8446 as the "current generic TLS reference"

at least once.



Mike> Done



Section 1



   A mechanism for exchanging configuration metadata such as endpoint

   URLs and cryptographic key parameters between the transmitter and

   recipient is out of scope for this specification.



I guess "cryptographic key parameters" was intended to be things like JST signing keys, but we could equally be talking about TLS certificates/CAs/DNS-IDs here as well, if we wanted.



Mike> This has been simplified to simply "cryptographic keys".



Section 2



   o  The SET is authentic (i.e., it was issued by the issuer specified

      within the SET).



Does "recipient does not have issuer's public key" just get lumped into the "not authentic" bucket?



Mike> Added "and if signed, was signed by a key belonging to the issuer".



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



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



We call out that we have to trust the issuer in general, and we have to trust the transmitter to send for a given subject, but we don't explicitly say anything about trusting the issuer to issue for that subject.  There are, of course, many scenarios where no such check is possible (e.g., when the subject is identified by the iss/sub pair and not a globally unique 'sub' claim), but perhaps there are cases where such a check is conceivable.  Do we want to say anything about it ("no, because it's too complicated to accurately described" is okay)?



Mike> No, because it's too complicated to easily accurately describe, and doing so would only be a distraction. ;-)



Section 2.1



   The "Content-Type" header of this request MUST be "application/

   secevent+jwt" as defined in Sections 2.2 and 6.2 of [RFC8417], and



I think we mean Sections 2.3 and 7.3 of that document.



Mike> Fixed



   The mechanisms by which the SET Transmitter determines the HTTP

   endpoint to use when transmitting a SET to a given SET Recipient are

   not defined by this specification and are deployment specific.



Any TLS certificate validation procedures (when HTTPS is used) would also be deployment-specific, of course, but do we think it's worth mentioning them here anyway (to seed the idea of using TLS)?



Mike> We talk about TLS validation multiple places already, so it's not clear to me that it would add value to also do so here.



The example in Figure 1 seems to not have an 'events' claim in the transmitted JWT?



Mike> Fixed



Section 2.4



Do we want to say anything about generic error-handling behavior when a SET Transmitter receives an error code that it does not know about (e.g., because that code has been allocated after the software was written)?



Mike> Added the sentence starting "Implementations SHOULD expect that other Error Codes MAY also be received"...



   | authentication_failed | The SET Recipient could not authenticate  |

   |                       | the SET Transmitter from the contents of  |

   |                       | the request.                              |



Are only the contents of the request allowed to be used for authenticating the Transmitter (as opposed to, say, TLS-layer client-certificate authentication)?

(Note that this text also appears in Section 7.1.2.)



Mike> Simplified to "The SET Recipient could not authenticate the SET Transmitter".



Section 3



It might be worth some discussion that for push, HTTP authentication authenticates the transmitter, whereas for poll it authenticates the recipient; workflows that need to authenticate the other party would have to rely on TLS, it seems.



Mike> Much of the text in this section was rewritten to make it simpler and clearer.



   The SET delivery method described in this specification is based upon

   HTTP and depends on the use of TLS and/or standard HTTP

   authentication and authorization schemes, as per [RFC7235].



Maybe reference RFC 2818 for "HTTP over TLS", to get parallelism of references?



Mike> Done



   Because SET Delivery describes a simple function, authorization for

   the ability to pick-up or deliver SETs can be derived by considering

   the identity of the SET Issuer, or via other employed authentication



Presumably this would involve some comparison/relationship between sender and issuer?



Mike> This was in the section that was rewritten for simplicity and clarity.



Also, I'm not sure I understand what is meant by "the ability to pick up SETs".  Is this the implied ability of a non-Issuer Transmitter to obtain the SETs being transmitted?



Mike> That terminology has been removed from the draft.



Section 4



   Delivery reliability requirements may vary from implementation to

   implementation.  This specification defines the response from the SET



Is this more of a per-implementation thing or a per-deployment thing?



Mike> It now says that the reliability requirements depend upon the use case.



   Implementers SHOULD evaluate their reliability requirements and the



(here, too)



Mike> Ditto



   if any, in order to meet their requirements.  SET Transmitters with

   high reliability requirements may be tempted to always retry failed

   transmissions, however it should be noted that for many types of SET



nit: comma after "however" (as well as the existing one before it).



Mike> Fixed



Section 5



We should probably pull in the "HTTP Considerations" subsection from poll.



Mike> Done



I want to see how the discussion goes on poll's "Access Token Considerations" first, but we may want something like that as well.



Mike> Yes, it makes sense to do that



Section 5.1



   In scenarios where HTTP authorization or TLS mutual authentication

   are not used or are considered weak, JWS signed SETs SHOULD be used

   (see [RFC7515] and Security Considerations [RFC8417]).  This enables



nit: I think we want "the Security Considerations of [RFC8417]".



Mike> I reworked this sentence to use normal reference styles.



Section 5.2



RFC 6125 is great and I'm glad we're referencing it, but it does leave a couple of gaps to be specified for a full picture of application usage.

Specifically, we should say what name from the certificate we validate (and, ideally, how the application knows what name it is expecting to see in that name field in the certificate).  Most applications these days will be using the DNS-ID, and perhaps something about wildcards and/or revocation info.  The last time I was making this comment on a document I pointed to RFC 8461 as a potential example to crib from, at least in terms of the types of things to talk about.



Mike> I added DNS-ID.



Section 6



I would have expected to see some form of reminder to encrypt data that needs confidentiality protection, in a privacy considerations section.



Mike> I added the sentence "Furthermore, data that needs confidentiality protection MUST be encrypted, either via TLS or using JSON Web Encryption (JWE), or both" to both drafts.



   If a SET needs to be retained for audit purposes, a JWS signature MAY

   be used to provide verification of its authenticity.



We should probably give the reader a bit more to conect this signature to the privacy considerations in question.



Mike> This sentence actually wasn't about privacy at all, so I deleted it from both drafts.



Section 7.1



   "Security Event Token Delivery Error Codes".  Initial values for the

   Security Event Token Delivery Error Codes registry are given in

   Table 1.  Future assignments are to be made through the First Come



It is a little confusing to say here at the top-level that the initial contents are in Table 1, but then also have Section 7.1.2 with the full initial registration (filling out the template).  I'd suggest to either mention both the table and Section 7.1.2 here, or just Section 7.1.2.



Mike> It now says "Initial values for the Security Event Token Delivery Error Codes registry are defined in <xref target="reqErrors"/> and registered below."



Section 7.1.1



   Change Controller

      For error codes registered by the IETF or its working groups, list

      "IETF SecEvent Working Group".  For all other error codes, list

      the name of the party responsible for the registration.  Contact

      information such as mailing address, email address, or phone

      number may also be provided.



The current thinking from the IESG is that we don't want to lock the immutable RFC into something that might go stale, and since IANA is good at tracking things, we can have them track the right contact-point within the IETF as well.  So, the expected "final state" is that the public registry lists "IETF" as the change controller, with IANA knowing to direct inquiries the WG list (until such time as updated by the IESG).  Thus, the document at this point should say something about "IANA is requested to direct inquiries to the [e-mail]<mailto:[e-mail]> mailing list, and the RFC Editor is requested to remove this sentence prior to publication"  This is something of a recent change, so we'll probably end up making further tweaks along the way, but that should be a good rough start.



Mike> Changed to "IETF".



   Defining Document(s)

      A reference to the document or documents that define the Security

      Event Token Delivery Error Code.  The definition MUST specify the

      name and description of the error code, and explain under what

      circumstances the error code may be used.  URIs that can be used

      to retrieve copies of each document at no cost SHOULD be included.



Is a document of some form required?  That's not consistent with the FCFS policy (as IANA does not want to be in the business of making the technical decision about whether the document qualifies for this purpose); should we be thinking about a Specification Required policy instead (with guidance to the experts to apply a very low bar)?



Mike> It's now "Specification Required".



Section 7.1.2



      Error Code: access_denied

      Description: The SET Transmitter is not authorized to transmit the

      SET to the SET Recipient.



In Table 1 we say "transmit the provided SET" (i.e., "provided" is not present here).  We should be consistent, though I don't really care which phrasing gets used.



Mike> Deleted "provided".



Appendices



It looks like we expect Appendices A and C to be removed before publication, but Appendix B (Acknowledgments) to remain.  Feel free to add the EDITORS NOTE to Appendix C as well.



Mike> Added instructions to the RFC Editor to do so.



-Ben



_______________________________________________

Id-event mailing list

[e-mail]<mailto:[e-mail]>

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



Mike> Thanks again, Ben!



                                                       -- Mike