Re: [Id-event] Barry Leiba's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)

[Barry Leiba <[e-mail]>]

Thanks, Mike, for the quick responses in both documents, and for
addressing my comments.

Barry

On Thu, Jun 25, 2020 at 1:55 AM Mike Jones
<Michael.Jones=[e-mail]> wrote:
>
> Thanks for your review, Barry.  https://tools.ietf.org/html/draft-ietf-secevent-http-push-13 is intended to address your comments.  Detailed replies are inline, prefixed by "Mike>".
>
> -----Original Message-----
> From: Barry Leiba via Datatracker <[e-mail]>
> Sent: Wednesday, June 24, 2020 1:41 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>; [e-mail]
> Subject: Barry Leiba's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-secevent-http-push-12: No Objection
>
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-secevent-http-push/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> — Section 1 —
> I agree with Éric’s comment that “known to one another” should be better explained — just something brief.
>
> Mike> I reworded this in response to Éric’s review.
>
>    Push-based SET delivery over HTTP POST is intended for scenarios
>    where all of the following apply:
>
> Is it the intent that push be used in all such cases, and pull in all others?
> It would be good to explicitly say that, perhaps by adding “(with pull-based SET delivery used in all other cases)” to the above.
>
> Mike> Both drafts now contain applicability criteria and say that sometimes both are applicable and sometimes they aren't.
>
> — Section 2 —
>
>    o  The SET is authentic (i.e., it was issued by the issuer specified
>       within the SET, and if signed, was signed by a key belonging to
>       the issuer).
>
> If the SET is not signed, how is authenticity determined and validated?  I understand that the specifics are out of scope for this document, but I’m trying to understand in general how this works.
>
> Mike> It it's not signed, the recipient is trusting that the transmitter is sending authentic SETs.
>
>    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).
>
> Let’s get a head start on the movement away from “whitelist/blacklist” and change this to “is listed as allowed by the SET Recipient”, or some such.  What do you think?
>
> Mike> Good catch.  Done.
>
>    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).
>
> It took me a couple of reads to understand what this is getting at.  Maybe this clarifies a little?:
>
> NEW
>    o  The SET Recipient is willing to accept this SET from this SET
>       Transmitter (e.g., the SET Transmitter is expected to send
>       SETs with the subject of the SET in question).
> END
>
> Mike> Thanks - done.
>
>    The SET Transmitter MAY re-transmit a SET if the responses from
>    previous transmissions timed out or indicated potentially recoverable
>    error
>
> Nit: “errors”
>
> Mike> Fixed
>
> — Section 2.1 —
>
>    To transmit a SET to a SET Recipient, the SET Transmitter makes an
>    HTTP POST request to an HTTP endpoint using TLS provided by the SET
>    Recipient.
>
> How is TLS provided by the SET Recipient?
> Or, perhaps, do you mean, “makes an HTTP POST request using TLS to an HTTP endpoint provided by the SET Recipient.”?
>
> Mike> This was reworded in response to a similar comment from Murray.
>
> — Section 2.2 —
>
>    Before acknowledgement, SET Recipients SHOULD ensure they have
>    validated received SETs
>
> Section 2 says, “Upon receipt of a SET, the SET Recipient SHALL validate”, so how does that work with the SHOULD here?  I think this is a problem with repeating normative statements: making sure they remain completely consistent.
>
> Mike> This was also reworded to remove extraneous SHALLs and SHOULDs in response to Murray's review.
>
> — Section 2.4 —
>
>    |                       | unacceptable to the SET Recipient. (e.g., |
>    |                       | expired, revoked, failed certificate      |
>    |                       | validation, etc.)                         |
>
> Nit: “e.g.” and “etc.” used together is redundant; I suggest removing the former.
>
> Mike> Done
>
>    Implementations SHOULD expect that other Error Codes may also be
>    received, as the set of Error Codes is extensible
>
> I suggest not using a 2119 key word here.  This isn’t really a SHOULD: an implementation that can’t tolerate extensions will be limited and eventually considered broken.  I think it’s better to just say this as a statement, beginning the sentence with the word “Other”.
>
> Mike> Done
>
> — Section 3 —
>
>    The TLS server certificate
>    MUST be validated, per [RFC6125].
>
> Is DANE (RFC 6698) not allowed?  Or should this be worded differently?  This also applies to the reference to cert validation in Section 5.3.
>
> Mike> Dane is now explicitly allowed in both drafts.
>
> — Section 7.1 —
>
>    Future assignments are to be made
>    through the Specification Required registration policy
>
> Please provide some brief guidance to the designated experts.  Thanks.
>
> Mike> Done - mostly copying applicable guidance from the JWT spec [RFC 7519]
>
> — Section 7.1.1 —
>
>    Change Controller
>       For error codes registered by the IETF or its working groups, list
>       "IETF SecEvent Working Group".
>
> Nit: This isn’t consistent with Section 7.1.2, nor with current practice.  It should just say “IETF”.
>
> Mike> It's now just "IETF".  (Several reviewers caught this!)
>
>                                 Thanks again,
>                                 -- Mike
>
>
>