Re: [Cfrg] Help with the use of contexts

"Paterson, Kenny" <> Mon, 16 January 2017 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE771295F0 for <>; Mon, 16 Jan 2017 10:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.688
X-Spam-Status: No, score=0.688 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=3.599, SPF_HELO_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0N_IBW022y4H for <>; Mon, 16 Jan 2017 10:37:20 -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 048A7129609 for <>; Mon, 16 Jan 2017 10:37:19 -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=o3NzvodDxOcw+hrerI1VdYekwFq74n1rxfkAmzNjU8E=; b=ENFSTGy6WeVjf2NppSMo1TDCMhnDYvwsXu6oyaGKE4Uy6aS7Sfdq4N5y1AqCX8cWJlhslC0+Z2J57k03WGZncEtaMfo7VU0PCtsJgnlP065LYnDmbcnwQ+bVqFk3OcLzvEmpzO3Z19XikTejBhghP5ANdF84utuAvAh1Ss0caAA=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Mon, 16 Jan 2017 18:37:17 +0000
Received: from ([]) by ([]) with mapi id 15.01.0845.014; Mon, 16 Jan 2017 18:37:17 +0000
From: "Paterson, Kenny" <>
To: Sean Turner <>, IRTF CFRG <>
Thread-Topic: [Cfrg] Help with the use of contexts
Thread-Index: AQHSZtVYp5bZtbgyB0+DnJlqd+YrVaE7gamA
Date: Mon, 16 Jan 2017 18:37:17 +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; AM4PR0301MB1906; 7:G+HH4albXK8p+QnrASH9Ib2HySg17dfU7OJ0co5jLevUSCJ8cqM6rFPgiQqTSa1gnnllQgawRhahgmnNzcx0yuElChIIERC/vAMxnV6oNI0qwgj/muURjG4/9qelTsTyEYNSjXhojHwOYgYpaOrmINcRc6/8yA6A0bX52oJzl3sUu2Jjv3OKsEuNjceWpIkG7l7WUPMp6dtl/39uZSswN/WrvaffyE20njphJUE7ftY4VdDUE8kuVecNiI6U6h/f9yOsjH1NyvPj9s+71rW6g80mSKksd35uwZr+faC4AAETFWvb5eyGhRa5n4IydyFS7yj0zURfCvNcvUA4s7gF7vMjQIdi0S2j0d1p0CvBRnOAaN3NwgibP688z1GuH8f+RxVvr3yP8HrLQ39d4CwLcCrXyUFN00qxoqE5X4HyMuRAuoDwjbWAyvEF/8MWJlKVzELccWDIFXqIxfViiIOMow==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(5660300001)(99286003)(66066001)(106116001)(6306002)(101416001)(105586002)(76176999)(36756003)(229853002)(54356999)(50986999)(25786008)(38730400001)(86362001)(77096006)(6486002)(6512007)(6506006)(92566002)(2900100001)(106356001)(6436002)(305945005)(6116002)(122556002)(74482002)(2906002)(7736002)(102836003)(3846002)(81156014)(189998001)(3280700002)(68736007)(8936002)(8676002)(81166006)(97736004)(83506001)(3660700001)(4001350100001)(5001770100001)(107886002)(42882006)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0301MB1906;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 608cc039-bbe4-4080-0212-08d43e3eb299
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM4PR0301MB1906;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM4PR0301MB1906; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0301MB1906;
x-forefront-prvs: 01894AD3B8
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: 16 Jan 2017 18:37:17.1058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0301MB1906
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, 16 Jan 2017 18:37:24 -0000

Dear CFRG,

Please chime in asap if you have a view on the issue of signature contexts
in TLS 1.3, as described by Sean below. Otherwise, chairs will make a
possibly ill-informed decision...



On 04/01/2017 21:55, "Cfrg on behalf of Sean Turner"
< on behalf of> wrote:

>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)
>Cfrg mailing list