Re: [TLS] ChaCha and IVs

Bodo Moeller <bmoeller@acm.org> Thu, 06 March 2014 00:35 UTC

Return-Path: <SRS0=caPd=YH=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78F51A0010 for <tls@ietfa.amsl.com>; Wed, 5 Mar 2014 16:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.476
X-Spam-Level:
X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 bYwtQoll6QXl for <tls@ietfa.amsl.com>; Wed, 5 Mar 2014 16:35:07 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.130]) by ietfa.amsl.com (Postfix) with ESMTP id 635B61A0004 for <tls@ietf.org>; Wed, 5 Mar 2014 16:35:07 -0800 (PST)
Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0MeXgF-1WYnDl2CoZ-00QDmS; Thu, 06 Mar 2014 01:35:02 +0100
Received: by mail-yh0-f42.google.com with SMTP id a41so1990519yho.1 for <tls@ietf.org>; Wed, 05 Mar 2014 16:35:01 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pO1szNZkFLZcEvglMPP8CG+ZaJn9ZvSPCHiFzHBMi00=; b=Od7YOnaacPmuWPTwIalh+gQn5mxvEn2QmNMw2BqQd64XVk1yqp3bp6Ec3Bt3XHy6RI i4EZtgRK3W0GXeSkTZCFVQSAMn5fLSqAI3SSr2KHeFkj9Ta7eFr4pny0CoyZB18FmJWN rFhdQiECw3mHPdFBRfkN7ZbDyR22dQex+yLuNCU/1QbMzoAwAN67u3JBGHbzFKnORU2I yz++uuoq8615qQxyiqro7gG2fTX8/q3amxrdNYQvLLJRq9yP/ZvjN/SPHQLc6f3omOYA riadvPDnPlSxahbpwefF7iCnpU2ujN2G76GPqmUsN6R+Gz1Sior9z0kRHv4DxI5bKal0 NNUw==
MIME-Version: 1.0
X-Received: by 10.236.136.231 with SMTP id w67mr10886414yhi.53.1394066101525; Wed, 05 Mar 2014 16:35:01 -0800 (PST)
Received: by 10.170.78.5 with HTTP; Wed, 5 Mar 2014 16:35:01 -0800 (PST)
In-Reply-To: <53161825.7060409@bbn.com>
References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com>
Date: Wed, 05 Mar 2014 16:35:01 -0800
Message-ID: <CADMpkcLqWOr6kq4VjTatpDGW8Ryf73V+YziOf3Op3waciG9o4w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="20cf303bfb5cc6665e04f3e54e67"
X-Provags-ID: V02:K0:ol2jpISFGGy5J3JZBbT0Ejp/eASvfFkIt/k3xSS0l4I YKDjldwepR/gskDWtPVWgu+WL7FBENKTZLIo4XDbKkGc4cj22m WG9+Whrz5dFnihQxOBeHZcSljvQaBbgDOu81Eys50FqDlu1ppz T61fOWV+edYUrEVq4AnBQfyYLwiTa4kcHtvw5YDLZPvr4J+nPQ Cmuweo9ZdX/IkzthGfaAijXy7pyfEvzb6/CvHU3GBdVHsmdTAv 6tPcVyxya8+457q9wH8QpK90L2qOL2+VYf2DhAfGAP4ewsvdwo 67Co7LTmXTmeBSWzMZIOKU5HHPKnLuPjFDYHZwfiBYwdoJlHvm bD3kQMrueaGuEgBOE5f5yQfqYf85KWB1DDznqCA5cpINik0wji 1tD7oIuhcFTz+dEe76ECW84Wv7H7NOGqpeav6oD0eDR5LVEv9M U5xBT
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rSaWLTp3AYr4QLx7IjEvbQ2hJoA
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] ChaCha and IVs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Mar 2014 00:35:49 -0000

Stephen Kent <kent@bbn.com>:

Anyone who has had a product evaluated will
> tell you that the goal is always to minimize the amount of code that is
> subject
> to review. If one were to use a TLS (or ESP) sequence number for an IV,
> all of
> the protocol code would be part of the evaluation, and that would make the
> evaluation prolonged and very costly.
>

I suppose if this becomes an actual concern for evaluation, you could
create a more easily evaluable module that accepts explicit IVs but checks
that these increase monotonically between invocations.  (Accepting
*explicit* IVs doesn't mean you have to accept *arbitrary* IVs.)

(Implicitly, this would also enforce the TLS requirement that sequence
numbers are not allowed to wrap around once you're beyond 2^64 records.)