Re: [TLS] ChaCha and IVs

Andy Lutomirski <luto@amacapital.net> Thu, 06 March 2014 01:19 UTC

Return-Path: <luto@amacapital.net>
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 B4F9E1A0007 for <tls@ietfa.amsl.com>; Wed, 5 Mar 2014 17:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 LZKeWi7d0k4t for <tls@ietfa.amsl.com>; Wed, 5 Mar 2014 17:19:31 -0800 (PST)
Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id EB0641A0011 for <tls@ietf.org>; Wed, 5 Mar 2014 17:19:30 -0800 (PST)
Received: by mail-pb0-f46.google.com with SMTP id rq2so1856632pbb.33 for <tls@ietf.org>; Wed, 05 Mar 2014 17:19:27 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0b65O49I4xjWhtrMYPCEKGZjm488jO1XufH1C9vmykg=; b=FoicjC9pgk+P7PhtyDCdy7PG95ThJJvB+eyFM8coosWQQNjyS+5fVxigDamf9aBK8h PHrbEyalheHeHDXhrG63LJx5HwDAzwNT0gGKHgfFTh9Lhjx5dwtyFSUT39T5E7wUpJMD bpOI7CfyofqVZ0AKKwn+aqrFi8x5KKNqHIxPGpUFCKtWLYvnpTwSm4UMrAWlFyJ8zpJy f5P8Yr4VjUJ3Ebk3cK1R8n2DP2TVhGQxkTmyw0/DrblC7OelOkdOEQPhV2w9rjfgGIAe Vh7yGdjai81ZSIX54sPxMuMTr0kTFLFI6R2Vmez82rXDupeEj73C7icKvitglu1deFH5 wWRA==
X-Gm-Message-State: ALoCoQkzfzB0B1Bm/rFgaOCy2bXQ3RTH4rCVrmZHIJj3t0yD52qUB7z7OqHolEZmk5iEAa84qY7M
X-Received: by 10.68.215.68 with SMTP id og4mr10850706pbc.112.1394068767097; Wed, 05 Mar 2014 17:19:27 -0800 (PST)
Received: from amaluto.corp.amacapital.net (50-76-60-73-ip-static.hfc.comcastbusiness.net. [50.76.60.73]) by mx.google.com with ESMTPSA id un5sm25250887pab.3.2014.03.05.17.19.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 17:19:25 -0800 (PST)
Message-ID: <5317CD1B.5010800@mit.edu>
Date: Wed, 05 Mar 2014 17:19:23 -0800
From: Andy Lutomirski <luto@amacapital.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>, Bodo Moeller <bmoeller@acm.org>
References: <53160513.20703@bbn.com> <1393955839.20861.20.camel@dhcp-2-127.brq.redhat.com> <53161825.7060409@bbn.com> <CADMpkcLqWOr6kq4VjTatpDGW8Ryf73V+YziOf3Op3waciG9o4w@mail.gmail.com> <CAK3OfOg5pqF_sEmKYJVxqmiekkPrycqbA1sbK8H7=EAtWFQMrw@mail.gmail.com>
In-Reply-To: <CAK3OfOg5pqF_sEmKYJVxqmiekkPrycqbA1sbK8H7=EAtWFQMrw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eJE_aIc6hXFuSuPRtimMX_HWJM0
Cc: Stephen Kent <kent@bbn.com>, "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 01:19:33 -0000

On 03/05/2014 04:59 PM, Nico Williams wrote:
> On Wed, Mar 5, 2014 at 6:35 PM, Bodo Moeller <bmoeller@acm.org> wrote:
>> 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.)
> 
> This.
> 
> However in the DTLS case there's no way to make the sequence numbers
> be monotonic.  What the module could do is keep its own IV sequence
> number window and reject the use of sequence numbers that are too old
> or reused...

DTLS is fine with strictly monotonic *encryption* sequence numbers,
right?  And I don't think it's a problem if an AEAD is asked to
*decrypt* repeated sequence numbers.  (It's certainly a problem if an
attacker can access the decryption of two different messages with the
same sequence if they don't both verify, but this is solvable by having
the crypto implementation refuse to supply the supposed plaintext if the
tag is bad.)

--Andy