Re: [saag] should we revise rfc 3365?

Nico Williams <nico@cryptonector.com> Thu, 24 May 2012 14:12 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA1FA21F86A0 for <saag@ietfa.amsl.com>; Thu, 24 May 2012 07:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-L65gPV339K for <saag@ietfa.amsl.com>; Thu, 24 May 2012 07:12:35 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5921F8675 for <saag@ietf.org>; Thu, 24 May 2012 07:12:35 -0700 (PDT)
Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id D142B1E08E for <saag@ietf.org>; Thu, 24 May 2012 07:12:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=c8GYfL+V29Pwg993AutlW DxH2J66I7XGIG1iuT675p8GWYhKlt2uYekWKkrHhy7xJeUBxJ6KLmT0BdkSzfR1n 8BY+tuA/5m5Uiwt67FrPPhISJgxCdLqfk3HiMR1TqETbthrxpaVQQW3Fth72kQ03 UUtPMYcHfHcO7tX/1lr55k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3HGqlrYwswR14GltEkmO eJsIk2o=; b=gmMXo7/0VMuDBGA65cPEM4nCiEdhdjUVrCI/rzqQKpY//4lPqWIr Lxr6AXby/zNG2FdsODWTQp3MiYY38aM4zBsRBGl+u9CxoCUGFzb4FArXGOYevknK Y8vKR5CuaDtnjaXtUtkfVT1Gh7ftNNzaTLiyRC73jKVtHAKUptiOB6M=
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 9F64F1E087 for <saag@ietf.org>; Thu, 24 May 2012 07:12:34 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so313925pbc.31 for <saag@ietf.org>; Thu, 24 May 2012 07:12:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.203.7 with SMTP id km7mr10540156pbc.7.1337868754331; Thu, 24 May 2012 07:12:34 -0700 (PDT)
Received: by 10.68.15.134 with HTTP; Thu, 24 May 2012 07:12:34 -0700 (PDT)
In-Reply-To: <4FBD6A78.2070204@cs.tcd.ie>
References: <4FBD6A78.2070204@cs.tcd.ie>
Date: Thu, 24 May 2012 09:12:34 -0500
Message-ID: <CAK3OfOiH6N3ZDCGFgXUiQbsBLMj1XYZu2L+iqzVW+VPX6JJi3A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Cc: "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] should we revise rfc 3365?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 14:12:36 -0000

I think we should say "should specify a MTI security feature" with
guidance as to when not to make it MTI or when not to bother
specifying the thing at all.  I-D authors should be required to
address this in the security considerations section.  Perhaps we
should stop at "tell us what you're doing about security and the
rationale for having or not having an MTI security feature".  The IETF
and IESG can review this and decide whether to insist that a protocol
have/not have a security feature.

Then DHCP could lack an explicit security feature on account of DHCP
being best secured by the link layer (the router/switch).  And so on.

Nico
--