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

From: Mike Jones <[email-masked]>
Date: Thu, 25 Jun 2020 05:54:32 +0000

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 <[email-masked]> 
Sent: Wednesday, June 24, 2020 1:41 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Yaron Sheffer <[email-masked]>; [email-masked]
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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 25 Jun 2020 08:52:13 -0400

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

Barry

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Jun 2020 15:13:07 -0700

Thanks for the updates, Mike.  Just one note...

> Subject: Barry Leiba's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)
[...]
> Mike> Done - mostly copying applicable guidance from the JWT spec [RFC 7519]

Unfortunately, the RFC 7519 guidance is perhaps a bit lacking, in that
while it says the experts should consider several factors (duplication of
existing functionality, general vs. specific applicability, etc.), it
doesn't say very clearly which direction any given factor should move the
experts in.  For example, while I expect near-universal agreement that
duplicating existing functionality should receive pushback, the agreement
may be less clear that proposals that are only useful by a single
application should get pushback.

I think we've done a little better with our guidance to experts in more
recent RFCs, but my spot-checking failed to find one that I liked.

-Ben