Re: [jose] #8: Direct mode for key agreement needs security analysis

Eric Rescorla <ekr@rtfm.com> Tue, 22 January 2013 23:43 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD5E21F8AF8 for <jose@ietfa.amsl.com>; Tue, 22 Jan 2013 15:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level:
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRknCWXG+E8q for <jose@ietfa.amsl.com>; Tue, 22 Jan 2013 15:43:26 -0800 (PST)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1564B21F8ACE for <jose@ietf.org>; Tue, 22 Jan 2013 15:43:25 -0800 (PST)
Received: by mail-oa0-f44.google.com with SMTP id n5so7934998oag.31 for <jose@ietf.org>; Tue, 22 Jan 2013 15:43:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=cw481SDxi0y41lZuy9XMY7sBsgDg7SScVThdgn1UGUE=; b=B7oyqjOy5dktpc/fGMRq0tp9+rNmO77Aw1Df6Gejrcm8fZkLHjkM8mzkZoEcCujw0J 7KJF05qFiEzdX0CJ7jB1wM/VW7ykNAwtSt+iuFlhjbu/1lhVvZmBRqeygSN7+GlK/5j6 f5LatJP78SadFB+vA8ysJ3EQq5Y1Kr8ZVsWaz5SLorVITtgi42ijn5vKYLJBNtBUaGBi Z1fwS6hPCeS3zgYE79TdHfhI8Wosni3MtPmwZQEvQ8dhdkCaddnxJSDKvTdRZYLyTwnh PaoHCIwqrKLdATI8q8+mltbbqW8jcl1qAJkGvjaPYXaUSt9fCNHNoPHCEvi3rlhqSbbo I5+w==
X-Received: by 10.182.119.6 with SMTP id kq6mr9586663obb.102.1358898204379; Tue, 22 Jan 2013 15:43:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.179.74 with HTTP; Tue, 22 Jan 2013 15:42:44 -0800 (PST)
X-Originating-IP: [74.95.2.173]
In-Reply-To: <054.96c0b71d4934f695a54309d767dbf877@trac.tools.ietf.org>
References: <054.96c0b71d4934f695a54309d767dbf877@trac.tools.ietf.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 22 Jan 2013 15:42:44 -0800
Message-ID: <CABcZeBOP_rjvqypcUem+SOeOi7Y-4y_Zv7y2vSRHWfqXtsXG0Q@mail.gmail.com>
To: jose issue tracker <trac+jose@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary=f46d0444ee23c2092904d3e92446
X-Gm-Message-State: ALoCoQmSvhom6EAKu+5HaelcChYBQtoikcKxPPW1lw5Lmyk337swaZqFMSMkjxjPNt5RWMEfTVCK
Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org, rbarnes@bbn.com
Subject: Re: [jose] #8: Direct mode for key agreement needs security analysis
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2013 23:43:29 -0000

If I am understanding the document correctly, you're talkinbg about the
mechanism in S 5.1, bullet #4, in which the shared symmetric key is
used directly to encrypt the content?

I'm generally not super-excited about modes like this, for a number of
reasons:

1. They place an enormous amount of stress on the IV mechanism.
As a concrete example, if you use GCM with fresh keys for every
message then a low-entropy nonce is safe (thogh bad practive).
However, if you ever reuse a key, then low entropy becomes
a serious issue.

2. As Richard says, it's not standard practice.

Is there a performance or such-like reason to allow this mode?

-Ekr

On Fri, Jan 18, 2013 at 3:24 PM, jose issue tracker <
trac+jose@trac.tools.ietf.org> wrote:

> #8: Direct mode for key agreement needs security analysis
>
>  JWE specifies a "direct encryption" method, in which the output of key
>  agreement is used for content encryption instead of key wrapping.  This
>  scheme is not used in other IETF security protocols that use key
>  agreement, e.g., CMS or IPsec.  CMS uses the agreed key for wrapping.
>  IPsec uses it to key the IKE SA, which covers further key agreement.  The
>  security considerations needs to justify why this scheme is secure, and
>  any relevant constraints (e.g., lifetime of DH keys).
>
> --
> -------------------------+-------------------------------------------------
>  Reporter:               |      Owner:  draft-ietf-jose-json-web-
>   rbarnes@bbn.com        |  encryption@tools.ietf.org
>      Type:  defect       |     Status:  new
>  Priority:  major        |  Milestone:
> Component:  json-web-    |    Version:
>   encryption             |   Keywords:
>  Severity:  Active WG    |
>   Document               |
> -------------------------+-------------------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/8>
> jose <http://tools.ietf.org/jose/>
>
>