Re: [Cfrg] Help with the use of contexts

"Paterson, Kenny" <> Mon, 30 January 2017 11:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DD02129454 for <>; Mon, 30 Jan 2017 03:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YLgmXoV1UHMh for <>; Mon, 30 Jan 2017 03:41:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77960128874 for <>; Mon, 30 Jan 2017 03:41:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sn9WRqDW3QxXdcv1RIu8uozDx5eRhJPY184qqa0mcbk=; b=gZ2l8xmKMnzYjJKHs0s1auAN7HRwo/8C8FdYs6limh71V4Al/eaN1b1MFriyoWVBb6u09rP+BwMUHbbQwwKBUhOYzkIy/ElbYUguL+ZJg4UBQrkSwSkL7/5nk94hdDlJ+DJXm2+cTIifR05RFo6+JZoprplHFTD+DQBdchsT1Vg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 30 Jan 2017 11:41:00 +0000
Received: from ([]) by ([]) with mapi id 15.01.0860.026; Mon, 30 Jan 2017 11:40:59 +0000
From: "Paterson, Kenny" <>
To: "" <>
Thread-Topic: [Cfrg] Help with the use of contexts
Date: Mon, 30 Jan 2017 11:40:59 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM4PR0301MB1908; 7:WX8HV54Tlo7B9xrMtvPVXV5WlCUbnQnsGxnf7a/o88BqNbIox/EsvHAYRgqeueX+8a8HBRDrNIEeD1I1ZGp85OnXFQoteP19XVrDP8bpyCSX4G+JbwgcZTYJkuH3ziDGj4jab0niKQI3xOA8Kgg738/hhMcPu2kuQLPmh8z+GegIYttvApZq2M7sCjncWmyGqOniebpqFJApfxV4YOmQmGMHF3+zG2NNRYsNMpcYlQPzyIZ37u5+pkdTh3SYb710IOfmun/1MRfRSZhrStEVJdG8/nILkdJeWplnimxjK6z2m8geT0+o+5WR7h/UD7D1k6qm00HiLVSODuux+6ioNQfM8ZkAoIKYueX/w6kahItblslOZbq9JAJuED88i1ukMs2ZRoCQ+XpOI1WVAATJ8L6ScZbN0QWM8HWWjO2WsxMTJ781+cGgqmaeXSE5Kb199GkvmZysnqlhqdeGmXqB3Q==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(6116002)(102836003)(38730400001)(3660700001)(5640700003)(25786008)(36756003)(6506006)(6436002)(2351001)(2501003)(2900100001)(6306002)(107886002)(106356001)(122556002)(106116001)(1730700003)(105586002)(99286003)(450100001)(8936002)(74482002)(81166006)(8676002)(2906002)(6486002)(3846002)(81156014)(77096006)(3280700002)(229853002)(189998001)(42882006)(2950100002)(6916009)(50986999)(68736007)(76176999)(54356999)(305945005)(53936002)(83506001)(110136003)(7736002)(93886004)(86362001)(4001350100001)(66066001)(97736004)(6512007)(92566002)(101416001)(5660300001)(564094006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1908;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: c115fa4c-4bed-4f17-6b7a-08d44904dcb8
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1908;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:AM4PR0301MB1908; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1908;
x-forefront-prvs: 0203C93D51
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 11:40:59.5501 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1908
Archived-At: <>
Subject: Re: [Cfrg] Help with the use of contexts
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Jan 2017 11:41:05 -0000

Dear CFRG,

Thanks to those who already expressed their views on this. We should close
this one out in the next few days. The current rough consensus seems to
lean towards "no to contexts in this instance". (The wider question of
whether contexts are a good idea or not is, formally, out of scope here,
but I don't think I can expect y'all to resist discussing it!)

So: does anyone else want to offer an opinion on the question of contexts?
The original request for input from Sean Turner can be found below.





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

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

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