Re: [yam] [Fwd: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03]

Ned Freed <> Mon, 08 March 2010 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 42A2F3A67E7 for <>; Sun, 7 Mar 2010 16:29:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UYAYGCJwPNHS for <>; Sun, 7 Mar 2010 16:29:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 776AF3A676A for <>; Sun, 7 Mar 2010 16:29:06 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sun, 7 Mar 2010 16:29:06 -0800 (PST)
Received: from by (PMDF V6.1-1 #35243) id <>; Sun, 07 Mar 2010 16:29:03 -0800 (PST)
Message-id: <>
Date: Sun, 07 Mar 2010 16:22:55 -0800 (PST)
From: Ned Freed <>
In-reply-to: "Your message dated Thu, 04 Mar 2010 16:54:11 -0500" <56D9734A7440776013CA8600@PST.JCK.COM>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8
References: <56D9734A7440776013CA8600@PST.JCK.COM>
To: John C Klensin <>
Subject: Re: [yam] [Fwd: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Mar 2010 00:29:07 -0000

> I concur with Barry.   I fear that the path Steve apparently
> wants to go down --as I understand it, to incorporate warnings
> in security considerations simply because a mechanism can be
> used to transfer bad stuff -- leads to madness.   But I'm happy
> to have you discuss it with him to see if you, together, can
> find an acceptable basis for moving forward.

There are really two issues here. First is whether or not to attempt to address
this in 1652bis. Even if I were to agree that we should address this, it most
certainly doesn't belong in 1652bis, if for no other reason than nobody dealing
with this issue is going to look there for advice.

As for whether ot belongs in 5321bis/5322bis, I'm afraid I have to agree with
John: This is a path to madness, or more accurately, to a world where security
considerations contain so many obvious, irrelevant, or both issues that the
real issues specific to a given protcol or format simply get lost in all the
other noise. And this is not a path which, if followed, will improve overall
Internet security. To the extent it has an effect, if will be the opposite.

I also have to say I find the notion that a short security considerations
section is necessarily a bad one to be worth pushing back against. There are
plenty of protocols and extensions that do not introduce additional security
considerations. We even have a term for this: Good design.