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

Barry Leiba <barryleiba@computer.org> Fri, 08 May 2009 02:09 UTC

Return-Path: <barryleiba@gmail.com>
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 0D9663A6FA4; Thu, 7 May 2009 19:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.138
X-Spam-Level:
X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 XGiIoh-fIV9J; Thu, 7 May 2009 19:09:06 -0700 (PDT)
Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id B5D493A67FB; Thu, 7 May 2009 19:09:05 -0700 (PDT)
Received: by ewy24 with SMTP id 24so1539420ewy.37 for <multiple recipients>; Thu, 07 May 2009 19:10:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eM1Y+1syv701mN0NEXSk+38dINk3YIInWKgYsYKTN44=; b=MRKj4VOlTNPdEKwk9g57Pz9Z2mgXujun7N9pPhuB7aTb2oPtrso+f4N7IgIWp4ZbYk bHr4WxmYkxXcjjZabTddTR5aHuGucn01K//0zYmhWX76xYarCNHVxPzvXDX3fn+WsaR/ YsNq4bSYahFoYxE0Ew8E7mjjqpi8NTb+tzwr4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=mPUyleGooZh1a2Mj2ARwlvaL1mUVDGvxqrU549mXls+f63DS1NZ+0glCsE+oSn2HcK HHSpVmKciSLZ3VAx9whcBf/sFmb67xM7cBDA3/2lIaK6Um+M9uNdBU6nYR+q6i/M0d+Z Adxlf2FsebSIYQKVV1+zfHoBhYbVQDghrPxrI=
MIME-Version: 1.0
Sender: barryleiba@gmail.com
Received: by 10.210.130.14 with SMTP id c14mr3848956ebd.17.1241748630564; Thu, 07 May 2009 19:10:30 -0700 (PDT)
In-Reply-To: <tslk54sl7i4.fsf@mit.edu>
References: <6c9fcc2a0905021333j3dd58821v4726af092e30c1c1@mail.gmail.com> <200905051750.n45HorPw023985@mx02.srv.cs.cmu.edu> <0FBA56D16F71437450BC2779@minbar.fac.cs.cmu.edu> <06a701c9cdb7$aed00f30$0600a8c0@china.huawei.com> <DD929100D04E45C1BAD655F69E35F0C6@xpsuperdvd2> <tslk54sl7i4.fsf@mit.edu>
Date: Thu, 07 May 2009 22:10:30 -0400
X-Google-Sender-Auth: df2cf3bcf03b453a
Message-ID: <9abf48a60905071910rcf9e321ha0ab92e692a6aeed@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: David B Harrington <dbharrington@comcast.net>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: isms@ietf.org, secdir@ietf.org, "David B. Nelson" <dnelson@elbrysnetworks.com>, isms-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-isms-transport-security-model@tools.ietf.org
Subject: Re: [secdir] [Isms] secdir review of draft-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: Fri, 08 May 2009 02:09:07 -0000

Sam says...
> Or just use lower case should.  I think the advice is important enough
> it does not belong in an appendix.

Indeed.

I didn't mean for my comment to cause a big stir; I think it's easy to sort out.

I like my first suggestion, repeated here:

  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.

...but I'd also be happy with something like this, if you don't want
to use 2119 language:

  by the RFC 3411 architecture.  However, the Transport Security Model
  does not provide security mechanisms such as authentication and
  encryption itself, so deployments should [or "must"] use it with a
Transport Model
  that provides appropriate security.  Which threats are addressed
  and how they are mitigated depends on the Transport Model.

In any case, let's not spend any more time on this one.

Barry
-- 
Barry Leiba  (barryleiba@computer.org)
http://internetmessagingtechnology.org/