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

[Roman Danyliw <[e-mail]>]

Hi Mike!

Thanks for the clarifications below and the updated text now in -13.  It addresses all of my comments.

Regards,
Roman

> -----Original Message-----
> From: Mike Jones <[e-mail]>
> Sent: Thursday, June 25, 2020 1:41 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; id-
> [e-mail]; Yaron Sheffer <[e-mail]>
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-secevent-http-push-
> 12: (with COMMENT)
> 
> 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]; id-
> [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