[Cfrg] Help with the use of contexts

Sean Turner <sean@sn3rd.com> Wed, 04 January 2017 21:55 UTC

Return-Path: <sean@sn3rd.com>
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 19988129713 for <cfrg@ietfa.amsl.com>; Wed, 4 Jan 2017 13:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
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 UnHWdN0EQNC1 for <cfrg@ietfa.amsl.com>; Wed, 4 Jan 2017 13:55:47 -0800 (PST)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F15A12966A for <cfrg@irtf.org>; Wed, 4 Jan 2017 13:55:47 -0800 (PST)
Received: by mail-qk0-x232.google.com with SMTP id n21so414952076qka.3 for <cfrg@irtf.org>; Wed, 04 Jan 2017 13:55:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=lUmbzXCeczozERq5bvP2sDwhHiZaP8JVqmARKxFvN2A=; b=cC7Nrw/bEsqL7KAJAvscPsGbnhtVQ6y7iOaBxG7pQMRyyPT7tIZCCwy7Z2m/jMjbLB cOghk3HVe7K/VkOxcqMEaZQ7QGCZ999xWhaqfVQQmqY5/LZ+nqTMrgx22qaboiP4SJBF qIjsvv8codyZl9P24F4ratkimrqAaUdZxvvaQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=lUmbzXCeczozERq5bvP2sDwhHiZaP8JVqmARKxFvN2A=; b=DgdDHsJh9u+3GV0DOZVZFOPhpOTdqCmLJ2CM+aNhdwDfk4sX8FKXsNFE8VC0Bz0QuA VcM2yKqXOJXHSbu+jqNZ5OZlUUSQSC3DmLR0THD/GDbhGXUmMhf9xMadi3kPMGdUyDxh vEN9jUGkrW29o6cyMOXqNamwJb/+aL2TAjuftL0PK4wtIyE9g2hbVXU0IQmQUTFWOcpN v55Qzyx9BfEEsKS0rHp1M0xb5A/EVhHzMbXhn5Dq3VrNVH8jkyhjcX60eyA0FT/tsepy 7qnRLtAniTAW+9PFn0swdAdrnh8eGcHfuH4bdmDd2PKmTv2NzAmHjA8LrwHw/TXR8rty ypdg==
X-Gm-Message-State: AIkVDXKoeANwjdeRXK7v5L0SZCNzcZdERfDT/0m5QNGuVRlisfwwypmwmAUUNfWqWrl4Ng==
X-Received: by 10.55.103.85 with SMTP id b82mr5121253qkc.24.1483566946401; Wed, 04 Jan 2017 13:55:46 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id j9sm25422549qtc.23.2017.01.04.13.55.45 for <cfrg@irtf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 13:55:45 -0800 (PST)
From: Sean Turner <sean@sn3rd.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <E3C4D457-2407-4295-9F45-B3CA0AE715DD@sn3rd.com>
Date: Wed, 4 Jan 2017 16:55:44 -0500
To: IRTF CFRG <cfrg@irtf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/8ggqR4BK4dx9PXIk5xtrIKAzdro>
Subject: [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: Wed, 04 Jan 2017 21:55:49 -0000

Hi CFRG,

The TLS WG is nearing the end of our journey moving EC-based algorithms for TLS 1.2 (and earlier) from Informational to Standards track [0].  While we were doing that we also added in 25519 and x448 as well as EdDSA.

I’d like to get some input from the CFRG on the use of contexts; the "context label" is a way to provide domain separation between signatures made in different contexts, avoiding cross-protocol attacks.  s10.3 of draft-irtf-cfrg-eddsa includes the following:

Contexts SHOULD NOT be used opportunistically, as that kind of use
is very error-prone.  If contexts are used, one SHOULD require all
signature schemes available for use in that purpose support
contexts.

This is great advice for new protocols because it’s easy to make all the schemes the same, but for existing protocols like TLS where there’s zero chance of obsoleting the existing signature schemes and defining new signature schemes with contexts it makes you wonder what “opportunistically” means. I.e., would setting a context parameter for Ed448 and no other already defined signature scheme be considered opportunistic?

spt
(as document Shepherd for draft-ietf-tls-rfc4492bis)

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/