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

[Benjamin Kaduk <[e-mail]>]

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.

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.

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?

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

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.

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

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

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

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

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.

   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?

   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?

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?

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?

   Implementers SHOULD evaluate their reliability requirements and the

(here, too)

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

Section 5

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

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

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

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.

Section 6

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

   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.

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.

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

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

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.

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.

-Ben