[secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05

Joseph Salowey <joe@salowey.net> Mon, 01 December 2014 18:39 UTC

Return-Path: <joe@salowey.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BAF991A8837 for <secdir@ietfa.amsl.com>; Mon, 1 Dec 2014 10:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sjcTzrDqOnS3 for <secdir@ietfa.amsl.com>; Mon, 1 Dec 2014 10:39:25 -0800 (PST)
Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185A81A8829 for <secdir@ietf.org>; Mon, 1 Dec 2014 10:39:23 -0800 (PST)
Received: by mail-qc0-f181.google.com with SMTP id m20so7988652qcx.26 for <secdir@ietf.org>; Mon, 01 Dec 2014 10:39:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=BARFuKZIQmfXF416khs5poS51zFbwdYYgY3vs0ZZg9I=; b=ekpmrnc99vfYH8K8QzvJF1WdAPVk1vM+gP5O9jfAmpc4HKR1cSD9zGJiylweOUQ2tL CcA3jEAWthg8Szfpdh+V3G8a6qtVmCt+XASDIVBaJ6lQqm0+T+qGmWp8YtGKtFKpDXIW VYEijHHHM42DM5lmCJ5cmvT4bCPKVrj2B+ZwCaVKXtNq4FjmA7L+kHu4w/mEcmCYlBEK HHZB0EbvclLqUBT2c7luYuXd+B+lpvmjl5EJgwghyuTqQoSzTRc5/nVGziw+ZKAdU/gU KHLmyUTE/9F1432wh2LD1q9jvee/pS9b9VuCtakj+zcOXN6EdUyHI0DQpKhdokwIMFcu I61g==
X-Gm-Message-State: ALoCoQmf4syAQEjUDRuAbXk2o58e5Yb8BKBolKEsoflOgLU5rvftAJ/oQ+GR4e6DG3y4YspW8l/n
MIME-Version: 1.0
X-Received: by with SMTP id z12mr3960397qge.75.1417459162341; Mon, 01 Dec 2014 10:39:22 -0800 (PST)
Received: by with HTTP; Mon, 1 Dec 2014 10:39:22 -0800 (PST)
X-Originating-IP: [2601:8:b300:a5:dc6:d9e5:2339:fbb3]
Date: Mon, 1 Dec 2014 10:39:22 -0800
Message-ID: <CAOgPGoCrkz5pKT-qCnCNwEVsWE-9zzK9erMAU+_10NSvMTmrtQ@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: secdir@ietf.org, draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org
Content-Type: multipart/alternative; boundary=001a1134f7c8db027105092bedca
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/wi2Z83bGqRwkWdwKFw1y1g6T2q4
Subject: [secdir] secdir review of draft-ietf-tsvwg-sctp-prpolicies-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: <http://www.ietf.org/mail-archive/web/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: Mon, 01 Dec 2014 18:39:27 -0000

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.

I have reviewed this document and believe it is Ready with minor issues.

This document describes new policies for the users of the SCTP Partial
Reliability service (SCTP-PR).  These policies cover discarding data after
too many retransmissions and discarding lower priority data.

The security considerations are a bit thin.  They mostly refer to RFC 3758
which is also a bit thin and was published before SCTP-DTLS was available.
There is some useful text in RFC 6083 (SCTP-DTLS) :

  "If PR-SCTP as defined in [RFC3758
<https://tools.ietf.org/html/rfc3758>] is used, FORWARD-TSN chunks
   also be sent in an authenticated way as described in [RFC4895
<https://tools.ietf.org/html/rfc4895>].  This
   makes sure that it is not possible for an attacker to drop messages
   and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this

I think it would be good to include similar text in this document since it
is relevant.  Are there any problems introduced if the INIT or the INIT-ACK
messages are not protected?