Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12

"David B Harrington" <dbharrington@comcast.net> Tue, 05 May 2009 20:42 UTC

Return-Path: <dbharrington@comcast.net>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454F53A6D91 for <secdir@core3.amsl.com>; Tue, 5 May 2009 13:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymBLCW+9sRof for <secdir@core3.amsl.com>; Tue, 5 May 2009 13:42:33 -0700 (PDT)
Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 5142C3A6AFE for <secdir@ietf.org>; Tue, 5 May 2009 13:42:33 -0700 (PDT)
Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA06.westchester.pa.mail.comcast.net with comcast id noxb1b00117dt5G56wjqZ8; Tue, 05 May 2009 20:43:50 +0000
Received: from Harrington73653 ([24.147.240.21]) by OMTA13.westchester.pa.mail.comcast.net with comcast id nwk01b0090UQ6dC3Zwk0w8; Tue, 05 May 2009 20:44:00 +0000
From: David B Harrington <dbharrington@comcast.net>
To: 'Barry Leiba' <barryleiba@computer.org>
References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com>
Date: Tue, 05 May 2009 16:43:59 -0400
Message-ID: <06ae01c9cdc2$37bbe4e0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcnNvYH7CDZJrmj2Tqm7iS1rwxNuTAAAYdyQ
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <9abf48a60905051303h1543f323u1a8e3679445384f6@mail.gmail.com>
Cc: isms@ietf.org, iesg@ietf.org, isms-chairs@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] [Isms] secdir review ofdraft-ietf-isms-transport-security-model-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 05 May 2009 20:42:34 -0000

Hi Barry,

your formulation is "MUST ... use", where "use" is a deployment
decision, and MUST is inappropriate for deployment advice.
We currently use "SHOULD ... use", but Jeff thinks that in
inappropriate as well.

How about:
    by the RFC 3411 architecture.  However, the Transport Security
Model
    does not provide security mechanisms such as authentication and
    encryption itself, so operators are advised to always use this
    with a Transport Model
    that provides appropriate security, where "appropriate" for a
particular
    deployment is an administrative decision.  Which threats are
addressed
    and how they are mitigated depends on the Transport Model.

dbh

> -----Original Message-----
> From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On 
> Behalf Of Barry Leiba
> Sent: Tuesday, May 05, 2009 4:04 PM
> To: David B Harrington
> Cc: secdir@ietf.org; iesg@ietf.org; isms@ietf.org; 
> isms-chairs@tools.ietf.org
> Subject: Re: [Isms] [secdir] secdir review 
> ofdraft-ietf-isms-transport-security-model-12
> 
> > That is a deployment decision made by an administrator who has an
> > understanding of what is appropriate to the system in question.
> >
> > What is the correct non-RFC2119 phrase in which to couch our
> > deployment advice?
> 
> Well, this would make me happy; would it work for you (and others)?:
> 
> OLD:
>    by the RFC 3411 architecture.  However, the Transport 
> Security Model
>    does not provide security mechanisms such as authentication and
>    encryption itself, so it SHOULD always be used with a 
> Transport Model
>    that provides appropriate security.  Which threats are 
> addressed and
>    how they are mitigated depends on the Transport Model.
> 
> NEW:
>    by the RFC 3411 architecture.  However, the Transport 
> Security Model
>    does not provide security mechanisms such as authentication and
>    encryption itself, so it MUST always be used with a Transport
Model
>    that provides appropriate security.  What is "appropriate" 
> for a particular
>    deployment is an administrative decision.  Which threats 
> are addressed
>    and how they are mitigated depends on the Transport Model.
> 
> Barry
>