Thanks for your useful review, Valery. I've attempted to address your comments in https://tools.ietf.org/html/draft-ietf-secevent-http-push-11. Replies are inline, prefixed by "Mike>". -----Original Message----- From: Valery Smyslov via Datatracker <noreply@xxxxxxxx> Sent: Saturday, May 2, 2020 11:39 PM To: secdir@xxxxxxxx Cc: last-call@xxxxxxxx; draft-ietf-secevent-http-push.all@xxxxxxxx; id-event@xxxxxxxx Subject: Secdir last call review of draft-ietf-secevent-http-push-10 Reviewer: Valery Smyslov Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines push-based Security Event Tokens (SET) delivery using HTTP transport. I think the document has few issues that are easy to fix. Major issue: 1. Section 5.1: In scenarios where HTTP authorization or TLS mutual authentication are not used or are considered weak, JWS signed SETs SHOULD be used (see [RFC7515] and Section 5 of [RFC8417]). I think this "SHOULD" is inconsistent with RFC8417, which states: Unless integrity of the JWT is ensured by other means, it MUST be signed using JWS [RFC7515] by an issuer that is trusted to do so for the use case so that the SET can be authenticated and validated by the SET recipient. If you believe that there are valid use-cases when unsigned SETs can be transferred over unauthenticated transport (violating MUST from RFC8417), then please describe them. Mike> In https://tools.ietf.org/html/draft-ietf-secevent-http-push-11#section-5.1, I removed the odd start of the sentence that you called out, leaving only an actionable statement that is consistent with RFC 8417. 2. Section 6. I think that Privacy Considerations lack discussion of what information an attacker can learn by analyzing HTTP responses if the HTTP connection is not protected by TLS. In this case even if the SET itself is encrypted, the attacker is able to get some useful information if it can read HTTP responses (e.g. if it is on the path). In particular, it can learn whether the SET is accepted or not and the reason for its rejection. Mike> I added a new paragraph at the end of the Privacy Considerations section https://tools.ietf.org/html/draft-ietf-secevent-http-push-11#section-6 to add this information. Minor issues: 1. Section 5.1: This [using JWS] enables the SET Recipient to validate that the SET Transmitter is authorized to deliver the SET. I think this sentence is formally wrong, because SET signature allows to identify SET Issuer, but not SET Transmitter. From my reading of the draft they can be different entities. The SET Transmitter in this case remains mostly anonymous. Mike> Thanks - corrected. 2. Section 5.2: As stated in Section 2.7.1 of [RFC7230], an HTTP requestor MUST NOT generate the "userinfo" (i.e., username and password) component (and its "@" delimiter) when an "http" URI reference is generated with a message, as they are now disallowed in HTTP. This requirement is already in RFC7230, so is there any need to repeat it? Is it related to security or to interoperability? In the latter case it's better to mention this requirement in Section 2.1. In the former case a few words explaining security implications of this requirement would help. Mike> I deleted this redundant statement. 3. Section 5.4: This may be mitigated by authenticating SET Transmitters with a mechanism with low runtime overhead, such as mutual TLS. I don't think that TLS can be attributed as "a mechanism with low runtime overhead" when you talk about DoS protection. TLS itself may be a target for DoS attacks, because server have to do quite a lot of computations before client presents its authentication information, which may be bogus. So, it has exactly the same problem you described earlier in this para. Mike> I deleted the "low runtime overhead" clause. 4. Section 6. In some cases, subject identifiers themselves may be considered sensitive information, such that their inclusion within a SET may be considered a violation of privacy. SET Transmitters should consider the ramifications of sharing a particular subject identifier with a SET Recipient (e.g., whether doing so could enable correlation and/or de-anonymization of data) and choose appropriate subject identifiers for their use cases. In my understanding of the draft SET Transmitters may be different entities from SET Issuers. I think it is SET Issuers who prepare SETs, not SET Transmitters. In general SET Transmitters don't know what's inside the SET (if JWE is used) and cannot modify it (if JWS is used). Mike> Good catch. I changed "SET Transmitters" to "SET Issuers". 5. (not related to security) Section 2.4: Implementations SHOULD expect that other Error Codes MAY also be received, as the set of Error Codes is extensible via the IANA "Security Event Token Delivery Error Codes" registry established in Section 7.1. I think that the normative "MAY is used improperly here and should be "may" instead. I also think that some words of what implementations should do with unknown error codes would help. Mike> Thanks - corrected. Nits: 1. Table 1 is difficult to read due to unusual text formatting within the cells. Mike> I'll work on this with the RFC editor, should it remain difficult to read when using xml2rfc v3 output. Thanks again, -- Mike -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
