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

Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 05 May 2009 19:09 UTC

Return-Path: <jhutz@cmu.edu>
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 468693A6E38; Tue, 5 May 2009 12:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.987
X-Spam-Level:
X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 NYkvilSA9R2D; Tue, 5 May 2009 12:09:18 -0700 (PDT)
Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 6A4FE3A6CFA; Tue, 5 May 2009 12:09:18 -0700 (PDT)
Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n45JAH51026910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2009 15:10:17 -0400 (EDT)
Date: Tue, 05 May 2009 15:10:17 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: David B Harrington <dbharrington@comcast.net>, 'Barry Leiba' <barryleiba@computer.org>, secdir@ietf.org, iesg@ietf.org
Message-ID: <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu>
In-Reply-To: <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu>
References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.201.16
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:09:19 -0000

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