Re: [Cfrg] Help with the use of contexts

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 17 January 2017 11:48 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D469C129418 for <cfrg@ietfa.amsl.com>; Tue, 17 Jan 2017 03:48:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level:
X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 kXdezB-6SAo2 for <cfrg@ietfa.amsl.com>; Tue, 17 Jan 2017 03:48:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE867129455 for <cfrg@irtf.org>; Tue, 17 Jan 2017 03:48:42 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 51923BE7B for <cfrg@irtf.org>; Tue, 17 Jan 2017 11:48:40 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XD_RQtkq9Mr for <cfrg@irtf.org>; Tue, 17 Jan 2017 11:48:39 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9B897BE79 for <cfrg@irtf.org>; Tue, 17 Jan 2017 11:48:38 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1484653719; bh=fAm/tA3MLNk5JTgTfPO3zVCrJ6VlYohMmIWsZjmInEo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=rAHL6EeCjldvRTKuAmttpGtcbPRU9o3El41BvfEpz/lAPkZoHFkHh9ssJIJ1T5yG5 9c2HqWkRKxdLXIS0BWHvfBcOhCOrxPxQkPI4p3Cpi7K3BWmNFgCTg6Mh6n+HN+2a27 coW1gSTcq9LXF3f5jmmYby2oNCLd7F1cX2pUEk58=
To: cfrg@irtf.org
References: <20170116200948.6535.qmail@cr.yp.to>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie>
Date: Tue, 17 Jan 2017 11:48:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <20170116200948.6535.qmail@cr.yp.to>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040503020209030907020508"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/QDsBgz7Zn2G0Kbb6ZbHebdTzggY>
Subject: Re: [Cfrg] Help with the use of contexts
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2017 11:48:45 -0000


On 16/01/17 20:09, D. J. Bernstein wrote:
> I would really like to see this unnecessary complexity eliminated from
> CFRG's signature specifications.

I'm relatively neutral on the use or non-use of contexts,
but lean more towards Dan's position that the API changes
involved mean that practically, it's better to not demand
contexts.

However, I really do wish that CFRG specs would not offer
both choices - that will simply lead to repeating this
discussion each time an IETF protocol wants to use the CFRG
spec. And of course, different decisions will be made over
time, leading to slightly more mess than would otherwise
exist. That's not a showstopper thing, but life will be
better if the choice is not offered.

So, I'd support eliminating contexts from CFRG specs and
saying something like "if you want that, and it's not a
bad idea for avoiding cross-protocol attacks, then do it
at a layer above the crypto API."

Cheers,
S.

PS: random idea - I wonder if analysis of wireshark
dissector source code, or some application calling
such code, might be a fine way to spot potential
cross-protocol attacks - anyone know if that's been
tried?