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

[Mike Jones <[e-mail]>]

Thanks for your review, Roman.  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: Roman Danyliw via Datatracker <[e-mail]> 
Sent: Tuesday, June 23, 2020 6:51 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; Yaron Sheffer <[e-mail]>; [e-mail]
Subject: Roman Danyliw's No Objection on draft-ietf-secevent-http-push-12: (with COMMENT)

Roman Danyliw 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:
----------------------------------------------------------------------

Thanks for responding to the SECDIR review (and thanks to Valery Smyslov for doing it)

** Section 2.1.  Per “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” didn’t parse right.  What does it mean to “us[e] TLS provided by …”?

Mike>  Murry also noticed this.  I reworded this sentence according to his suggestion.

** Section 5.3.  Recommend being clearer that using TLS is a MUST.
OLD
   In some use cases, using TLS to secure the transmitted SETs will be
   sufficient.  In other use cases, encrypting the SET as described in
   JWE [RFC7516] will also be required

NEW
    TLS MUST be used to secure the transmitted SETs.  In some use cases, also
    encrypting the SET as described in JWE [RFC7516] will be required.

Mike> Done

** Section 5.3.  Per “SETs may contain sensitive information that is considered Personally Identifiable Information (PII).  In such cases …”, first off, I fully endorse and concur with the spirit here – being clear when you have sensitive information that confidentiality is a MUST requirement.  However, we need precision here – PII is a technical term in many jurisdictions, and the definition varies.  I wouldn’t want to make the normative guidance here conditional on this ambiguity.  I’d also note that Section 5.1. of RFC8417 refers to confidentiality requirements in the presence of third parties. 
Combining these observations will the editorial item above, I recommend:

“SETs may contain sensitive information, to include Personally Identifiable Information (PII), or be distributed through third parties.  TLS MUST be  …”

Mike> Thanks, done

** Section 5.3.  Per the reference RFC7525, I recognize that this sentence is identical to Section 5.1 of RFC8417.  Is there a reason why conformance to it
(RFC7525) is not a MUST (e.g., to ensure guidance on ciphersuites)?  You’ve already covered TLS version numbers with text and certificate validation with RFC6125.

Mike> It's now a MUST

** Section 5.5.  Per “At the time of receipt, the SET Recipient can rely upon transport layer mechanisms …”, since this whole specification is about a particular “transport layer mechanisms”, what is are the specific details here – or is this out of scope?

Mike> It now more specifically talks about TLS mechanisms

				Thanks again,
				-- Mike