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

Valery Smyslov via Datatracker <noreply@ietf.org> Sun, 03 May 2020 06:38 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 791363A161D; Sat, 2 May 2020 23:38:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Valery Smyslov via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, draft-ietf-secevent-http-push.all@ietf.org, id-event@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.129.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158848793845.30822.14865138131669756772@ietfa.amsl.com>
Reply-To: Valery Smyslov <valery@smyslov.net>
Date: Sat, 02 May 2020 23:38:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/IqOB6cWybGv0wbVoifTUGwwLB7k>
Subject: [secdir] Secdir last call review of draft-ietf-secevent-http-push-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 May 2020 06:38:59 -0000

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.


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.


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.


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.


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.


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


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.


Nits:
1. Table 1 is difficult to read due to unusual text formatting within the cells.