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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 23 Jun 2020 06:50:30 -0700

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 …”?

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

** 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  …”

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

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