Re: [Cfrg] how can CFRG improve cryptography in the Internet?

David McGrew <mcgrew@cisco.com> Tue, 11 February 2014 16:16 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC32E1A0609 for <cfrg@ietfa.amsl.com>; Tue, 11 Feb 2014 08:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.049
X-Spam-Level:
X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHBH2vyXSZ0T for <cfrg@ietfa.amsl.com>; Tue, 11 Feb 2014 08:16:53 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id DDB011A054C for <cfrg@irtf.org>; Tue, 11 Feb 2014 08:16:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1896; q=dns/txt; s=iport; t=1392135412; x=1393345012; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=cd099roo7Texda+jfq/h6c3Z+niLAI0vTxbmsASkl6Q=; b=RY3Ml6iwYMghASKnke9bOTYwBoVJjutlhabO7zCCcwlAPdxsku1LThTP /aSIuCxa5TOquU+sYQNdKe801i/FPCqC0K7sPG5UCCnZ5uaCGfb1DcNIH Va34DmjDWUBM1Rv0ABZyIkSECbfU5WrFZUzY8GR2JQl5X2QXnXijVIjff o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAMxM+lKtJV2c/2dsb2JhbABQCoMMvHKDBoESFnSCJQEBAQMBOEEQCxgJJQ8CRgYNAQcCh3kIyBoXjh0LAQFPB4Q4AQOJSIp5g2mGR4tZg0segTU
X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="19579269"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 11 Feb 2014 16:16:44 +0000
Received: from [10.0.2.15] (rtp-mcgrew-8913.cisco.com [10.117.10.228]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1BGGhRD006843; Tue, 11 Feb 2014 16:16:44 GMT
Message-ID: <52FA4CEB.50402@cisco.com>
Date: Tue, 11 Feb 2014 11:16:43 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <CACsn0ckOL8xdp5z7DdB9wyHhFpax0DhVXjsUMuGj39HgKk4YBA@mail.gmail.com> <52f50c59.aa1b8c0a.77c0.4985SMTPIN_ADDED_MISSING@mx.google.com> <CACsn0cnYkDwyAdwdf0+-JtksWu4NhKPr3L2emG2b3kFDe5v6hg@mail.gmail.com> <52F52E2D.8090104@cisco.com> <52F55236.1070800@gmx.net> <52F925FD.4030204@cisco.com> <52F93DA4.1090403@cs.tcd.ie>
In-Reply-To: <52F93DA4.1090403@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "cfrg@irtf.org" <cfrg@irtf.org>, "nmav@gnutls.org" <nmav@gnutls.org>
Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2014 16:16:54 -0000

Hi Stephen,

On 02/10/2014 03:59 PM, Stephen Farrell wrote:
> I think adding energy and appropriate tasking to CFRG is a fine
> idea, but this bit is a bit of a potential rathole...
>
> On 02/10/2014 07:18 PM, David McGrew wrote:
>> Surely we don't need new crypto mechanisms to solve the problems with
>> RADIUS, but analyzing and documenting security issues and helping to
>> socialize them with the IETF and the user base are all in charter and
>> are worth doing.
> I'm not clear on this. I don't think there are non-obvious
> crypto issues with RADIUS or Diameter that CFRG can tackle
> to be honest. Or maybe I'm not missing something?
>
> I don't think CFRG should be collectively "documenting security
> issues" generally, if those that are not cryptographic. Reason
> being that that'd likely generate more heat than light and would
> overlap with secdir and IETF WGs too much probably.

I was being too vague, sorry.  By "documenting security issues" I had in 
mind those cases in which some sort of cryptanalysis needs to be brought 
to bear in order to show that, yes, there is an actual attack that can 
be performed.   Sometimes some applied cryptanalysis needs to be done to 
make the point that some existing algorithm or parameter choice is no 
longer appropriate (or perhaps was never a good idea).    The 
standards-oriented people in CFRG could probably identify some 
low-hanging fruit that the cryptanalysis-oriented people would enjoy 
breaking.

Definitely we need to avoid the overlap that you mention.

David

>
> I could maybe see re-chartering to include theorem-prover style
> analyses or results in CFRG's charter, but I interpret the above
> differently.
>
> If some CFRG folk are interested in e.g. RADIUS security,
> then they are just as free as anyone to send mail to the
> DIME list.
>
> Cheers,
> S.
>
>
> .
>