Re: [Cfrg] Help with the use of contexts

Watson Ladd <> Tue, 17 January 2017 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51383129471 for <>; Tue, 17 Jan 2017 07:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 XvWULDz_Nhj6 for <>; Tue, 17 Jan 2017 07:06:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 71C54126B6D for <>; Tue, 17 Jan 2017 07:06:47 -0800 (PST)
Received: by with SMTP id 123so44044857ybe.3 for <>; Tue, 17 Jan 2017 07:06:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N1RmgmRuTE66IToZwjqeSwv3qCm6Wby4mI/eDARjnsA=; b=pdFQZDziCxghMRdyOQ9/OS7IPF9I276XYgQ25NBVf9C3fW4a/SnCd5in+DyO60ot4m g1bdj6RU0jDiTfVYb9SSUMyRoEj1Zfm4IvRDXsY4yCaVZenFcrEjVc7FRnbcUvZ5Biak AOuLN9hZka29Qx2mb0R1Hyzzx7tyUC+yCLGe8Kbcg2tU6BUC60iycrUj9yMqoAQdro9j 2pDCcIolELqUlAfkMNKgYenkqI0AvB4dSicNJdTdX5ICxpRcy5lOW9xMeg7+fuBEtqTI fQyF4eDAFJ3JxVilW7f/qv8KN8zRtFSQy8wbwe2JxTIB/bMoOf3AU06qq+Kyt5DPJB4F qFYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N1RmgmRuTE66IToZwjqeSwv3qCm6Wby4mI/eDARjnsA=; b=Z+fJwXvoWCKNMYZDQZJ8k33T9ynkGzsfECPzAXgK0YV3l0ZKH1rpMGjmRHe59922RT B5evRa/yJkxGJQN81zQbC5aXiJ7kZSJT36qOgHJ6faWpw9q5IJXzEP/zLX6fvS12sp9N otpYkc+w4MdxHoCASRy9k/s3XRXlcLPzoJAI8TEEDeSDVZ8JlUSPLuDxTJz1Ei5ByRCW t0n6/qRhCUf3TBd3L6nVFIpvSMcgxvHCKKmgyGITUN46XzLTJtyr5NyYCKaS0AXp4cAE oUh7nZP7zhAEwdPP3cm8S7wQwbgh9W0TJTlMLyMyRsNtmB13FaIq4HjR15oj47MGobpq knqQ==
X-Gm-Message-State: AIkVDXIeseFa/Iv9LUvT0HqRZ5Sv170xJPfmTT/FzlEuQKZvyyk4X/A7/ZLMaz460CJ8SYdZAINOjuEcHUMLQQ==
X-Received: by with SMTP id h39mr3882505ybi.132.1484665606577; Tue, 17 Jan 2017 07:06:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 17 Jan 2017 07:06:45 -0800 (PST)
Received: by with HTTP; Tue, 17 Jan 2017 07:06:45 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Tue, 17 Jan 2017 07:06:45 -0800
Message-ID: <>
To: Stephen Farrell <>
Content-Type: multipart/alternative; boundary="94eb2c1a03d61722ab05464ba64d"
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: Tue, 17 Jan 2017 15:06:50 -0000

On Jan 17, 2017 3:48 AM, "Stephen Farrell" <>

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

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."


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

What we want is to determine if the intersection of two badly specified
possibly context sensitive languages is empty. This is tricky. If protocols
stuck to regular languages it would be decideable.

Cfrg mailing list