Re: [sasl] MOGGIES Proposed Charter

Nicolas Williams <Nicolas.Williams@oracle.com> Mon, 24 May 2010 19:28 UTC

Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: sasl@core3.amsl.com
Delivered-To: sasl@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8053D3A6FF4 for <sasl@core3.amsl.com>; Mon, 24 May 2010 12:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level:
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 dAtTSpnOLkyU for <sasl@core3.amsl.com>; Mon, 24 May 2010 12:28:25 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5894E3A6FE8 for <sasl@ietf.org>; Mon, 24 May 2010 12:28:14 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OJRwkW002043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 May 2010 19:28:00 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4OImtgw027839; Mon, 24 May 2010 19:27:57 GMT
Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 263492051274729275; Mon, 24 May 2010 12:27:55 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 May 2010 12:27:54 -0700
Date: Mon, 24 May 2010 14:27:50 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Message-ID: <20100524192749.GQ9605@oracle.com>
References: <20100520225647.GX9605@oracle.com> <ldvy6fc3mg8.fsf@cathode-dark-space.mit.edu> <20100521230900.GF9605@oracle.com> <aTuL5hseOU458FLQG7pXdg.md5@lochnagar.gulbrandsen.priv.no> <20100524043655.GI9605@oracle.com> <4BFA1DFE.7040406@gulbrandsen.priv.no> <20100524153625.GJ9605@oracle.com> <4BFAA237.3000208@gulbrandsen.priv.no> <5222_1274719543_o4OGjfqB023953_20100524164134.GK9605@oracle.com> <13A2D93BD9B77DEE4929D674@minbar.fac.cs.cmu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <13A2D93BD9B77DEE4929D674@minbar.fac.cs.cmu.edu>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Auth-Type: Internal IP
X-Source-IP: acsinet15.oracle.com [141.146.126.227]
X-CT-RefId: str=0001.0A090201.4BFAD342.003D:SCFMA922111,ss=1,fgs=0
Cc: sasl@ietf.org
Subject: Re: [sasl] MOGGIES Proposed Charter
X-BeenThere: sasl@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SASL Working Group <sasl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sasl>, <mailto:sasl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sasl>
List-Post: <mailto:sasl@ietf.org>
List-Help: <mailto:sasl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sasl>, <mailto:sasl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2010 19:28:26 -0000

On Mon, May 24, 2010 at 03:07:35PM -0400, Jeffrey Hutzelman wrote:
> --On Monday, May 24, 2010 11:41:34 AM -0500 Nicolas Williams
> <Nicolas.Williams@oracle.com> wrote:
> 
> >I'd like to see a strong argument for using absolute cipher suite /
> >mechanism strength numbers.  About the only argument for that that I can
> >think of is that users are used to such measures of strength, therefore
> >we should stick to what users know.  I think that's a fairly strong
> >argument for having numeric strength measures.
> 
> I don't.  [...]

I didn't say it was strong enough...  But since we've seen arguments for
numeric strength measures I'd like to see the rationales, and the above
one is the only one that I could think of.

Perhaps there's another possible rationale: a) there's some strong need
for ordered preference sets and b) we explicitly do not want local
policy.  I can't imagine (b) being true; (a), of course, is, but crypto
strength numbers needn't be the only way to get (a).

>           To the extent that users are used to numeric measures of
> crypto strength, I expect they either (1) have only seen values "0"
> and "56", or (2) are likely to compare them in unmeaningful ways
> (1024 is bigger than 256, so a product advertised as using "1024-bit
> encryption" (1024-bit RSA plus 40-bit DES) is better than a product
> advertised as using "256 bit AES encryption").

I was thinking more of 0, 56, 128 and 256.  But yes, I find this
argument relatively weak, as in weaker than my arguments for symbolic
policies instead :)

> The fact is that the "strength" of a complex authentication
> mechanism using multiple cryptographic algorithms in various ways is
> simply not a linear quantity.

My view exactly.  (Not linear, not constant, not sufficiently useful.
Policy is needed no matter what, therefore I'd like to skip straight to
that answer.)

Nico
--