Re: [saag] should we revise rfc 3365?

"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com> Tue, 29 May 2012 16:48 UTC

Return-Path: <hannes.tschofenig@nsn.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 AD1D011E80B5 for <saag@ietfa.amsl.com>; Tue, 29 May 2012 09:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level:
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 lvi3+X65+c7q for <saag@ietfa.amsl.com>; Tue, 29 May 2012 09:48:04 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8B11E80B0 for <saag@ietf.org>; Tue, 29 May 2012 09:48:03 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGm2dp032354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 29 May 2012 18:48:02 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q4TGm2uX007138; Tue, 29 May 2012 18:48:02 +0200
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 18:48:02 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 29 May 2012 19:50:00 +0300
Message-ID: <999913AB42CC9341B05A99BBF358718D017FDDE4@FIESEXC035.nsn-intra.net>
In-Reply-To: <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [saag] should we revise rfc 3365?
Thread-Index: Ac09thChqpBpMNPqQ+CfR+UiGOA7pQAA+YHQ
References: <4FBD6A78.2070204@cs.tcd.ie><201205232351.TAA23415@Sparkle.Rodents-Montreal.ORG><4FC4EBA7.9070106@cs.tcd.ie> <201205291613.MAA05874@Sparkle.Rodents-Montreal.ORG>
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
To: ext Mouse <mouse@Rodents-Montreal.ORG>, saag@ietf.org
X-OriginalArrivalTime: 29 May 2012 16:48:02.0357 (UTC) FILETIME=[CFD38650:01CD3DBA]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 2865
X-purgate-ID: 151667::1338310082-00001F01-472233C9/0-0/0-0
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 16:48:04 -0000

I have a few clarifying questions regarding your mail. 

> >>> "MUST implement strong security in all protocols"
> >> I believe this is too dogmatic a position, and will simply lead to
> >> IETF process being ignored in [some cases].
> > So how would you phrase it so that we do get security mechanisms
> > defined in most all cases but not when they're really really not
> > needed (or fictional)?
> 
> I don't think that can be done by drawing a hard line in the sand, as
> 3365 tries to do, regardless of where that line is drawn.  Whether
> strong security is appropriate is a judgement call, as is how much
> security constitutes `strong' for a particular purpose.  And judgement
> calls have this annoying property that they require, well, judgement,
> that they can't be made by unambiguous algorithms.

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

> It's possible I'm just missing something, but I can't see any way to
do
> this that doesn't mean involving real humans.  3365 appears to be
> trying to do it in a way that avoids needing to involve humans; I
> believe that's possible only with a relatively high error rate.  In
the
> case of 3365, the errors take the form of imposing strong security on
> protocols that don't need/want it; drawing the line other places will
> distribute the errors differently, but I doubt it's possible to
> eliminate them.

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.
> 
> If this just resulted in unnecessary security, it wouldn't be so bad.
> But I suspect it will, instead, result in IETF process being ignored
> and protocols defined by rough consensus and running code _without_
> IETF oversight, until/unless the IETF is more or less forced to either
> violate its own process and standardize a protocol in its
> widely-deployed form or blatantly ignore a popular and useful protocol
> because it doesn't wear 3365's (or 3365bis's) straitjacket.

Are you saying that people ignore IETF security recommendations or that
the entire protocols are being ignored or what?

I think we have to pick specific cases to provide enough context. In the
abstract such a discussion quickly becomes meaningless. 

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


Ciao
Hannes


> 
> /~\ 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
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag