Re: [Cfrg] CFRG and thwarting pervasive montoring

Paul Lambert <paul@marvell.com> Mon, 30 December 2013 19:06 UTC

Return-Path: <paul@marvell.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 536A81AE2D7 for <cfrg@ietfa.amsl.com>; Mon, 30 Dec 2013 11:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
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 FgthZRBfpQZ4 for <cfrg@ietfa.amsl.com>; Mon, 30 Dec 2013 11:06:27 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 370A11AE293 for <cfrg@irtf.org>; Mon, 30 Dec 2013 11:06:26 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id rBUJ6Fjs009929; Mon, 30 Dec 2013 11:06:15 -0800
Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1h0e8whyc2-21 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Dec 2013 11:06:15 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 30 Dec 2013 11:06:13 -0800
From: Paul Lambert <paul@marvell.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Mon, 30 Dec 2013 11:06:11 -0800
Thread-Topic: [Cfrg] CFRG and thwarting pervasive montoring
Thread-Index: Ac8FkjUNmTAqB7QORmGgfT/Vvg3JsQ==
Message-ID: <CEE6FEE3.2B330%paul@marvell.com>
References: <CAGZ8ZG2f9QHX40RcB8aajWvEfG0Gh_uewu2Rq7bQGHYNx6cOmw@mail.gmail.com> <52C07436.2040709@cs.tcd.ie> <04C32948-02A2-44F4-B4C1-CF29D4146715@vpnc.org>
In-Reply-To: <04C32948-02A2-44F4-B4C1-CF29D4146715@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-30_02:2013-12-30, 2013-12-30, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1312300128
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] CFRG and thwarting pervasive montoring
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: Mon, 30 Dec 2013 19:06:28 -0000

On 12/29/13, 1:12 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

>On Dec 29, 2013, at 11:12 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>wrote:
>
>> . . .
>
>> I would love to see ongoing detailed work within
>> CFRG as to how to counter pervasive monitoring.
>
>Wearing your perpass hat, how can CFRG help? I ask this because I have
>seen little on the perpass mailing list that indicated that an even minor
>problem has been lack of crypto, or the use of crypto that is thought to
>be breakable. What type of crypto research or assessment would help
>perpass?

In the past I¹ve never considered CFRG a viable discussion forum for
making an impact by creating or approving new algorithms Š but if it is:

	We need an Œapproved' nonce-insensitive AEAD algorithm.

I¹m designing multicast communications in a mesh topology and CCM and GCM
suffer from N^2 complexity (since they require unique nonce/key).  Yes Š
there are ways that some link proposals like 802.1ae mitigate the issue
using device addresses as part of the key setup.  The best solution is a
nonce-insensitive AEAD.

We already have an RFC for SIV which is deterministic and a decent
solution, but it is not ŒNIST¹ approved, so I have problems introducing it
into consumer equipment.  It¹s also a little slow Š but I¹m not sure that
efficiency should be the primary evaluation criteria.

I¹ve asked NIST in the past and they have expressed no interest in the
problem.  It used to be very important for algorithms to be NIST approved.
 Do we need to find/create a new review and approval process for
algorithms that can be referenced by commercial products?

Paul







>
>Note that deprecating the use of crypto that is widely known to be broken
>is the purview of IETF WGs, not the CFRG. The relevant WGs (particularly
>TLS) seem to already be doing that.
>
>--Paul Hoffman
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg