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

"David B Harrington" <dbharrington@comcast.net> Tue, 05 May 2009 19:27 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 4AEF528C1C7 for <secdir@core3.amsl.com>; Tue, 5 May 2009 12:27:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.517
X-Spam-Level:
X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 DLcy-l0hF75W for <secdir@core3.amsl.com>; Tue, 5 May 2009 12:27:14 -0700 (PDT)
Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id DA4DF3A71D6 for <secdir@ietf.org>; Tue, 5 May 2009 12:27:09 -0700 (PDT)
Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA10.westchester.pa.mail.comcast.net with comcast id nmBx1b00416LCl05AvUcNN; Tue, 05 May 2009 19:28:36 +0000
Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id nvUb1b00a0UQ6dC3SvUbcE; Tue, 05 May 2009 19:28:36 +0000
From: David B Harrington <dbharrington@comcast.net>
To: 'Jeffrey Hutzelman' <jhutz@cmu.edu>, 'Barry Leiba' <barryleiba@computer.org>, secdir@ietf.org, iesg@ietf.org
References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu>
Date: Tue, 05 May 2009 15:28:34 -0400
Message-ID: <06a701c9cdb7$aed00f30$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: AcnNtSYsrMOk66M4RPGOpg+msofHJgAAhTKA
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu>
Cc: draft-ietf-isms-transport-security-model@tools.ietf.org, isms@ietf.org, isms-chairs@tools.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 19:27:15 -0000

OK, I'll change my answer. 

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?

dbh

> -----Original Message-----
> From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu] 
> Sent: Tuesday, May 05, 2009 3:10 PM
> To: David B Harrington; 'Barry Leiba'; secdir@ietf.org;
iesg@ietf.org
> Cc: draft-ietf-isms-transport-security-model@tools.ietf.org; 
> isms@ietf.org; isms-chairs@tools.ietf.org; jhutz@cmu.edu
> Subject: Re: [Isms] [secdir] secdir review 
> ofdraft-ietf-isms-transport-security-model-12
> 
> --On Tuesday, May 05, 2009 01:50:46 PM -0400 David B Harrington 
> <dbharrington@comcast.net> wrote:
> 
> > That is a deployment decision made by an administrator who has an
> > understanding of what is appropriate to the system in question.
MUST
> > is for implementers and SHOULD is for deployers.
> 
> Nononono.  When we say "MUST is for implementors", we mean that our 
> specifications give requirements for implementations which 
> claim to comply; 
> RFC2119 requirements language is generally inappropriate for 
> deployment 
> advice.
> 
> It is appropriate to say TSM MUST be use with a TM that provides 
> appropriate security; that is equivalent to saying that 
> implementations 
> MUST NOT use TSM together with an inappropriate TM, such as UDP.
> 
> 
> That said, selection of transport and security models generally is
an 
> operational decision.  TSM itself is really architectural 
> glue to allow us 
> to push some of the security infrastructure down into a 
> transport below 
> SNMP, such as SSH or TLS.  You'd never say "I want to use 
> TSM, now which 
> transport should I use"; you'd say "I want to use SSH -- oh, 
> for that to 
> work, I have to use it with TSM".
> 
> 
> -- Jeff
>