Re: [secdir] Secdir last call review of draft-ietf-secevent-http-push-10

[Mike Jones <[e-mail]>]

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 <[e-mail]> 
Sent: Saturday, May 2, 2020 11:39 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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