Re: [Cfrg] Help with the use of contexts

Adam Langley <> Mon, 16 January 2017 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A36AB12960C for <>; Mon, 16 Jan 2017 10:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hpr7R0AXtVh5 for <>; Mon, 16 Jan 2017 10:45:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEAE3129609 for <>; Mon, 16 Jan 2017 10:45:35 -0800 (PST)
Received: by with SMTP id l66so98127900ioi.1 for <>; Mon, 16 Jan 2017 10:45:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZtIhfe7O1K5sRrSAM6TGL2pTCcufR5/t3lEyMl40kNc=; b=UIry+Z4zBzlQci9KTskxeG3bQjMQB7XTBtOPDOTKY34YJROVJ4q4+VWVm2+2FvYo2+ 5SLGhyYb0xa5C+cB3KsSJgZcya9OySnTkGlMwUPXyBdO9evYMMZP/S183ReSaVyiNj88 aaiaUWtChRMlzn6kxFw/DeVEfiU0nQo4poay5QFtpwjZzihqQN2taKeVmmSKC65kMoDV myvrmjiXm1wjHJ8ZTyd+2SwA9EF1Bt7CNiZSl7MdKsExlcMoxkLcMh7zAyADI1884S9M eSPutOgSrR2qMEjJQgJyBCjWqI9q0ozRmw+qRt/bGIhdMgcKZ2Fl4B0ozYwgDUDBrVXj pmEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZtIhfe7O1K5sRrSAM6TGL2pTCcufR5/t3lEyMl40kNc=; b=lU/RN6l7fZZqfnf+LOXwMytE09CF6RNjNP9An7K8Nze0Dih9ybmsNTqVDDr7Pxolyt 9rukBmPg1vYW6Tf0xt78mB3hU7AuiQn2xu0XsctqTTZ1c8WRTAppSigwwvbzLwtaTdxf jtThgRBRPIkPWD0BcE5NJloLgPTipE+KO7c9D14XV3RB26AIhMxM/eMPV/evMM3R/TlB TnX2X0uByOP/TcxB4Mcm8FtGpiAMUbEZApvDS5bumIz26pR+PePOfEjKHhYlV4xPjS/e e1PqQyIrD0n/6GF2pB/N+tEardjIj/yRWLppP9n6U9s2RJ3ALPun9K+pW/MrBxpyKfBA gagw==
X-Gm-Message-State: AIkVDXLd4PeLTYXHi9l/ri9Wr/za56onpYBmjSncgManqsKWbaMr1VB2uqg0JOwbgrMlVrugT0e5lP7xt0WR8Q==
X-Received: by with SMTP id p77mr30812670iod.97.1484592335117; Mon, 16 Jan 2017 10:45:35 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 16 Jan 2017 10:45:34 -0800 (PST)
In-Reply-To: <>
References: <>
From: Adam Langley <>
Date: Mon, 16 Jan 2017 10:45:34 -0800
X-Google-Sender-Auth: mitSjflYPWgchKHW6TEEmrz2fnQ
Message-ID: <>
To: Sean Turner <>
Content-Type: multipart/alternative; boundary="94eb2c061a1cc562ab05463a96b4"
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:45:39 -0000

On Wed, Jan 4, 2017 at 1:55 PM, Sean Turner <> 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
> 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?

Domain separation for signed values is important and TLS already defines
context strings for signature operations:

The way that this is constructed (due to me) is generic for any signature
scheme. (Basically just have the context string be NUL-terminated at the
beginning of the signed message.)

So for TLS I believe that the issue is already taken care of. It would also
probably just add pain for implementers if the context string were to be
duplicated as an input to the signature scheme where signature schemes
support it.



Adam Langley