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

Michael Tuexen <tuexen@fh-muenster.de> Mon, 01 December 2014 19:28 UTC

Return-Path: <tuexen@fh-muenster.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9901A89C4; Mon, 1 Dec 2014 11:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBlNWAOyexYQ; Mon, 1 Dec 2014 11:28:25 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E676C1A89C7; Mon, 1 Dec 2014 11:28:22 -0800 (PST)
Received: from [192.168.1.102] (p508F31EC.dip0.t-ipconnect.de [80.143.49.236]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 7E2401C1622C0; Mon, 1 Dec 2014 20:28:19 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Michael Tuexen <tuexen@fh-muenster.de>
In-Reply-To: <CAOgPGoCrkz5pKT-qCnCNwEVsWE-9zzK9erMAU+_10NSvMTmrtQ@mail.gmail.com>
Date: Mon, 1 Dec 2014 20:28:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C4F8E721-C808-4497-B185-112C9A702016@fh-muenster.de>
References: <CAOgPGoCrkz5pKT-qCnCNwEVsWE-9zzK9erMAU+_10NSvMTmrtQ@mail.gmail.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/8fbnljNutglPMrB8SAPMpdk3cD8
Cc: draft-ietf-tsvwg-sctp-prpolicies.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [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 19:28:27 -0000

On 01 Dec 2014, at 19:39, Joseph Salowey <joe@salowey.net> wrote:

> 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.  
Hi Joe,

thank you very much for your review. See my comments below.

Best regards
Michael
> 
> 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
> ] is used, FORWARD-TSN chunks MUST
>    also be sent in an authenticated way as described in [
> 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
>    dropping."
> 
> 
> I think it would be good to include similar text in this document since it is relevant.  Are there any problems 
I see your point, but this usage of AUTH in combination with DTLS is not related to the
particular PR-SCTP policy. One could add a sentence stating that if DTLS over SCTP as specified
in RFC 6083, the corresponding security considerations also apply. Would that address your issue?
> introduced if the INIT or the INIT-ACK messages are not protected?  
No. You can't protect them, see
https://tools.ietf.org/html/rfc4895#section-3.2
> 
> Cheers,
> 
> Joe