Re: [Cfrg] Help with the use of contexts

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 05 February 2017 12:35 UTC

Return-Path: <ilariliusvaara@welho.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 21DF012954E for <cfrg@ietfa.amsl.com>; Sun, 5 Feb 2017 04:35:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NZKwrbWmhY5L for <cfrg@ietfa.amsl.com>; Sun, 5 Feb 2017 04:35:41 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 753B612706D for <cfrg@irtf.org>; Sun, 5 Feb 2017 04:35:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A0A501DD61; Sun, 5 Feb 2017 14:35:39 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id xQ9DQ01xXHR5; Sun, 5 Feb 2017 14:35:39 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 18C8821C; Sun, 5 Feb 2017 14:35:39 +0200 (EET)
Date: Sun, 5 Feb 2017 14:35:37 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Tibor Jager <tibor.jager@gmail.com>
Message-ID: <20170205123537.GA13710@LK-Perkele-V2.elisa-laajakaista.fi>
References: <5eeb3d4d-1fc0-35ba-6f47-87fa0d808edc@cs.tcd.ie> <AA42E783-43FC-4C9B-A387-623B5B18B4FB@gmail.com> <708C8E8E-37AE-4B8F-9843-B0F8CDB29229@gmail.com> <CACsn0cm22h8_61CEZjKYyHfnd7vvnC39ZMjhusjWcZKu_Z0zhw@mail.gmail.com> <DA141A39-05C2-4B87-92FA-AE8C5421E104@gmail.com> <0435210f-0aa4-1c34-89d6-0f7a2aef0621@cs.tcd.ie> <D4B4D5E4.82A6D%kenny.paterson@rhul.ac.uk> <CA+yVaTxTbqDUBbX2oTgC6BT2LprOz8uqAbhTRukuqfZD124kSA@mail.gmail.com> <20170203125533.GA11515@LK-Perkele-V2.elisa-laajakaista.fi> <CA+yVaTzr+9rFM_GX--6B+M8hyz5O-bWFmjDwEiPKeOyCM17zXQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CA+yVaTzr+9rFM_GX--6B+M8hyz5O-bWFmjDwEiPKeOyCM17zXQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/pJagCxlijLN02Kh-VGpCOdKrlD8>
Cc: cfrg@irtf.org
Subject: Re: [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: Sun, 05 Feb 2017 12:35:44 -0000

On Sun, Feb 05, 2017 at 08:48:01AM +0100, Tibor Jager wrote:
> On 03/02/2017 13:55, Ilari Liusvaara wrote:
> > On Fri, Feb 03, 2017 at 09:16:11AM +0100, Tibor Jager wrote:
> >> On 30 January 2017 at 12:40, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
> >> wrote:
> >>
> >>> So: does anyone else want to offer an opinion on the question of
> contexts?
> >>>
> >>>
> >> Contexts are a clean and relatively simple way to prevent cross-protocol
> >> attacks, in particular when implemented in an as simple way as proposed
> >> by Adam and Dan.
> >
> > Unfortunately, in practice those are anything but clean and simple.
> >
> > Yes, the theoretical notion is pretty simple (where (context,message)
> > tuple replaces the message in standard notion of signature security).
> >
> > The biggest practical problem: Backwards compatiblity, the ever-present
> > nemsis of security.
> 
> We do not have to change old protocols in order to enable domain separation
> via contexts in new protocols:
> 
> - Old protocols: keep signing messages as before: sig = Sign(sk, m)
> - New protocols: sign messages as sig = Sign(sk, ctx||m)

The problem is, that keys need to be separated as well.

If it is just a protocol that stands alone, then one may just declare
its keys to be suitable.

However, if it uses external keys, you are faced with separating these
keys, which means changes to the key format. And if external keys are
critically used in some other way, you need to modify this use as well.

Implication of above for TLS:

- TLS critically relies in practice on X.509 SPKI key format and X.509
  CSRs.
- Reliance on SPKI impiles that new SPKI key type would be needed.
- Reliance on CSR would mean new X.509 signature type would be required.

Yes, the new key type and new signature type are not difficult to
define, but still need to be done for the scheme to give security.

> Here, ctx is a "unique" and sufficiently large context string, which even
> in presence of an attacker is unlikely to occur in the message m of any
> existing protocol. For example, one could use the ASCII string "TLS 1.3 TLS
> 1.3 TLS 1.3 ...", repeating "TLS 1.3" a suitable number of times. The
> symbol || denotes concatenation of bytes, possibly with a NULL-byte as a
> separator.

Fails the basic notion of security of contextualized signatures.

> This is how I understand the solution pointed to by Adam and explained by
> Dan, and it seems similar in spirit to (but simpler than) what Natanael
> described. In particular, it seems not to break backwards compatibility
> with existing protocols, but would allow a smooth transition to the use of
> contexts to achieve domain separation, and thus help to prevent
> cross-protocol attacks.

I don't think they described the catch with this type of construction...


-Ilari