Re: [TLS] Consensus call on Implicit IV for AEAD

Daniel Migault <mglt.ietf@gmail.com> Mon, 06 April 2015 13:38 UTC

Return-Path: <mglt.ietf@gmail.com>
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 D2F1F1A889D for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 06:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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, 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 3k0p44rLqQTh for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 06:38:22 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949171A875B for <tls@ietf.org>; Mon, 6 Apr 2015 06:38:22 -0700 (PDT)
Received: by wgsk9 with SMTP id k9so4518503wgs.3 for <tls@ietf.org>; Mon, 06 Apr 2015 06:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SVePdxGd0f7rAt5m+oiQVX1DzO0MudFPmV8TIDffU/Y=; b=OiNodaMhEcLxdzbGE2dUuA9bkXtvxMfn1U6q/TolTQi4Pi7OsNT3I/ou2gE/PurXey nb0pAf9M3RCCmCKi7U8U2s0TVnupos0iROV+HzmepCQjeyeK9vnyyvlo5dyxMGdgn0dK 6m+fzA9gEY7v09D7hEuSO57ChXh4cJEuJX5Jo9tj5OGjPum1l0HeHBmecwtgcChJ90NF YorEaet2MPkSsVK2eiROTW64s+YdbaKfUV+3ezhQc3nzIbwxRo4rXAWvVZ2KBpvQD8f5 Ro5CdWIYlLww5ieYMwYRH+CuCdl4o61vt7NIIdkzcizsVOMVWxiTcV4c40BqX6kR1MSp 7KGA==
MIME-Version: 1.0
X-Received: by 10.180.85.130 with SMTP id h2mr59362209wiz.3.1428327501336; Mon, 06 Apr 2015 06:38:21 -0700 (PDT)
Received: by 10.194.5.97 with HTTP; Mon, 6 Apr 2015 06:38:21 -0700 (PDT)
In-Reply-To: <CA+cU71=UE0FTe6L2zuVqejVGYL10yE8pWvdixTWbtHVsDvzhvg@mail.gmail.com>
References: <CAOgPGoCW-znnh5VFobCFjZafxEOcwsaHZ_eByTwpCpmqfgX=6Q@mail.gmail.com> <CA+cU71=AZjGgisDyOyAeRsgh6PZDbiH2YTv3grn-d-4quunmNg@mail.gmail.com> <16A0B45C-5631-4270-9888-7E9FB90481DC@gmail.com> <CA+cU71=UE0FTe6L2zuVqejVGYL10yE8pWvdixTWbtHVsDvzhvg@mail.gmail.com>
Date: Mon, 06 Apr 2015 09:38:21 -0400
Message-ID: <CADZyTknBmFh-=UOtLTr_iW-SUTcwCb1MxK2gGGKGDaRNOcHTug@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: multipart/alternative; boundary="f46d0444e9dd57167405130e69f3"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ry1NOfHH419cDHDQ-ApHVqZHSwE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Consensus call on Implicit IV for AEAD
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: Mon, 06 Apr 2015 13:38:25 -0000

We had similar discussions this in IPsecme WG in Dallas [1].

AES-CBC for example would require an unpredictable IV, which makes the IV
generation more complex. Keys to generate the IV have to be negotiated and
agreed. During the WG session, we agree to limit our scope for the implicit
IV on AES-CCM/GCM/CTR and making AES-CBC out of scope.

There are at least two ways to remove the IV, either you perform a
compression that can be applied to any algorithm or you define specific
protocol suites that have an implicit IV. With compression, you may design
a mechanism that works with any suite and design the IV compression so
highest requirements are fulfilled... hoping no other conditions may be
introduced in the future. By defining specific protocols like
(AES-CCM_IMPLICIT_IV) the protocol is designed specifically to meet IV
properties. The draft presented at IPsecme adopted the second approach.

The remaining discussion point raised was how to position this implicit IV
protocol with FIPS/NIST Cryptographic Module Validation program. I have not
had enough time to check that for now.


[1] https://tools.ietf.org/html/draft-mglt-6lo-aes-implicit-iv-01
BR,
Daniel





On Mon, Apr 6, 2015 at 7:25 AM, Tom Ritter <tom@ritter.vg> wrote:

> On 6 April 2015 at 03:41, Yoav Nir <ynir.ietf@gmail.com> wrote:
> > So either IVs (actually nonces) are compressible only for such
> ciphersuites that support using the record counter as nonce/IV (add a flag
> to the registry), or else we use some method such as AGL's for generating
> unpredictable IVs from predictable nonces.
>
>
> Thanks Yoav, ekr,
>
> I obviously haven't followed all the arguments here (and from skimming
> Brian's reply) - but I prefer defining a construction that makes the
> IV given to the AEAD unpredictable and random. Doing that from a
> predictable nonce seems okay.
>
> -tom
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
Daniel Migault
Ericsson