Re: [saag] should we revise rfc 3365?

Mouse <mouse@Rodents-Montreal.ORG> Tue, 29 May 2012 18:08 UTC

Return-Path: <mouse@Sparkle.Rodents-Montreal.ORG>
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 4306811E8122 for <saag@ietfa.amsl.com>; Tue, 29 May 2012 11:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.468
X-Spam-Level:
X-Spam-Status: No, score=-9.468 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_HI=-8]
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 cae-6lY58ezv for <saag@ietfa.amsl.com>; Tue, 29 May 2012 11:08:10 -0700 (PDT)
Received: from Sparkle.Rodents-Montreal.ORG (Sparkle.Rodents-Montreal.ORG [216.46.5.7]) by ietfa.amsl.com (Postfix) with ESMTP id 556E511E8102 for <saag@ietf.org>; Tue, 29 May 2012 11:08:10 -0700 (PDT)
Received: (from mouse@localhost) by Sparkle.Rodents-Montreal.ORG (8.8.8/8.8.8) id OAA06971; Tue, 29 May 2012 14:08:09 -0400 (EDT)
Date: Tue, 29 May 2012 14:08:09 -0400
From: Mouse <mouse@Rodents-Montreal.ORG>
Message-Id: <201205291808.OAA06971@Sparkle.Rodents-Montreal.ORG>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway.
X-Message-Flag: Microsoft: the company who gave us the botnet zombies.
X-Composition-Start-Date: Tue, 29 May 2012 13:25:45 -0400 (EDT)
To: saag@ietf.org
In-Reply-To: <999913AB42CC9341B05A99BBF358718D017FDDE4@FIESEXC035.nsn-intra.net>
References: <4FBD6A78.2070204@cs.tcd.ie><201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG><4FC4EBA7.9070106@cs.tcd.ie> <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG> <999913AB42CC9341B05A99BBF358718D017FDDE4@FIESEXC035.nsn-intra.net>
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: Tue, 29 May 2012 18:08:11 -0000

> I wonder whether you could provide some specific examples of where
> the IETF provided too strong security solutions for a protocol.

Where a protocol was standardized with more security than appropriate?
No specific examples come to mind.  But, upthread, I cited three (four,
I think) examples of protocols which are useful in their current form,
but that current form could not be standardized under 3365's
restrictions: whois, SMTP, DHCP, and (I think - see below) NFS.

>> 3365 appears to be trying to do it in a way that avoids needing to
>> involve humans; [...]
> Could you point to specific parts in RFC 3365 since it mentions users
> a couple of times (with different meaning) and I did not see an
> obvious problem with it.

No, the humans I was talking about are not users of protocols, not the
users 3365 speaks of.  The sense in which I see 3365 as trying to avoid
involving humans is that it appears to be trying to lay out a policy
that can be applied by anyone without requiring any judgement calls.

>> I suspect it will [...] result in IETF process being ignored and
>> protocols defined by rough consensus and running code _without_ IETF
>> oversight, [...]
> Are you saying that people ignore IETF security recommendations or
> that the entire protocols are being ignored or what?

What I suspect will happen - and this is just a guess - is that people
designing new protocols will look at 3365 (or 3365bis) and effectively
say "if the IETF requires that we put strong security in this protocol
then we'll just build it the way we want it and the IETF can go hang".

If I'm right, and such a protocol becomes popular, this will put the
IETF in the uncomfortable position of having to either (a) ignore a
popular protocol because it doesn't fit the IETF's policy dogma or (b)
ignore its own process and standardize a protocol that doesn't fit the
dogma.

I could be wrong.  But I've seen protocols developed independent of the
IETF adopted into the IETF framework (NFS is an example) often enough
that I think it's reasonably likely.  (Note that, unless I missed
something in my skim of the spec, NFS is also an example of a protocol
that violates 3365 - even in v4, it has m-t-i security infrastructure
but I didn't see any m-t-i use of it.)

And it probably bears repeating that:

>> Of course, this is all my opinions and guesses.  I could be wrong.
>> Wouldn't be the first time, nor the last....

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B