Re: [TLS] Pull Request: Removing the AEAD explicit IV

Eric Rescorla <ekr@rtfm.com> Tue, 17 March 2015 18:22 UTC

Return-Path: <ekr@rtfm.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 266681A1BB9 for <tls@ietfa.amsl.com>; Tue, 17 Mar 2015 11:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 nVGliuvR3-HU for <tls@ietfa.amsl.com>; Tue, 17 Mar 2015 11:22:51 -0700 (PDT)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (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 2A2DA1A1B92 for <tls@ietf.org>; Tue, 17 Mar 2015 11:22:51 -0700 (PDT)
Received: by wibdy8 with SMTP id dy8so70333967wib.0 for <tls@ietf.org>; Tue, 17 Mar 2015 11:22:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bNVB2UExLgO4Cbbplmxmao4y4SNBuudw+C4Vu8HN3OA=; b=JgQafO2Om8hkI32nIy/hGUndokAxLv62VgM1kpq5tpxxj17qXsA5d7NjJP8xDQXzav vSIzW0TNct0AkwhlypeJfjK9GNRsiAgYT4yTuxWyTPSbDlfE2WeHpGZ8bvON04snUJH9 2X9K6m6mLMO2LktshhHAK2Tn5aRHQyhRpIL7kQ19J0ImM0Av7GkVWIRhPCo/6TSqW9LK nPheaHrkTs88qirGIgaXUsnY75x24jpeaMG87XF/Gpxogd/6A0cjePIQccYtVbrrOOw4 HjzmLardfeWGxboPPkpX9s0xUAsoBb/pSDr7L+YtBSVn4FQk9QolrMV+dvb/uVyZVqMq Xa+w==
X-Gm-Message-State: ALoCoQl4tem9Kv9K0yUj4mqoRYb4ftHO4GwAEFVxVkfoNLJFKFOaR5vREeP5meUdpyNw22M7Hk7b
X-Received: by 10.180.19.73 with SMTP id c9mr197064wie.10.1426616569726; Tue, 17 Mar 2015 11:22:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.205.198 with HTTP; Tue, 17 Mar 2015 11:22:09 -0700 (PDT)
In-Reply-To: <55086D3C.5090605@nthpermutation.com>
References: <CABcZeBPfasM5HmJaATLUHQKRgiSGCreJt1T=UoDBGCbcuzyW8Q@mail.gmail.com> <55086D3C.5090605@nthpermutation.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 17 Mar 2015 11:22:09 -0700
Message-ID: <CABcZeBOF-ezdpJcA5W3-Y6548KoG8qu9KSRdpEHic7UZBjLqCQ@mail.gmail.com>
To: Michael StJohns <msj@nthpermutation.com>
Content-Type: multipart/alternative; boundary=bcaec53d546fde9a290511800d4d
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WBGSN6rKe0Xi-FzqEF0tmZdQmhY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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: Tue, 17 Mar 2015 18:22:54 -0000

On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns <msj@nthpermutation.com>;
wrote:

>  Sorry for being pedantic but...
>
> The Nonce is the fixed (per connection) part of the quantity of bits that
> are encrypted to produce one block of cipher text that's XOR'd with the
> plain text to produce the encrypted message block.   The Nonce plus the
> message sequence number is the per-message initialization vector.   The
> Nonce plus the message sequence number plus the block number is the per
> block value to be encrypted.   At least for CCM and GCM.
>
> The Nonce is common across all messages within a session.   (*sigh* the
> more general meaning of nonce is that of a unique per-invocation value but
> given that all per-message/per-block "nonce" usages contain the
> per-connection nonce it would be useful to not overload this too much -
> among other reasons:  an IV is not always a nonce but can be, a nonce is
> not usually an IV but can be, most messages require an IV, most blocks
> don't).  So maybe we call this the "Session Nonce" for clarity?
>

I realize that the terminology is confusing, but I'm using the terms from
RFC 5116
section 2.1 (https://tools.ietf.org/html/rfc5116#section-2.1). In this
context, the
nonce is not per-connection but rather per AEAD function invocation:

      A nonce N.  Each nonce provided to distinct invocations of the
      Authenticated Encryption operation MUST be distinct, for any
      particular value of the key, unless each and every nonce is zero-
      length.

In this context, the AEAD function is invoked once for each TLS record
encryption.



> So what you're proposing is to eliminate the determination of the Nonce as
> part of the session negotiation and make it a fixed value.  E.g., we have
> an explicit nonce which is always zero which produces a per-message IV
> based on the sequence number of '0's | <sequence counter> | <block
> counter>.  As a side effect that also eliminates the per-message IV field
> (which aren't actually used by the currently defined AEAD modes AFAICT).
>

AES-GCM uses this field, which is the motivation for this change.



> That works for the currently defined pure AEAD modes (CCM/GCM at least,
> haven't looked at chacha).   Will that work in all cases for constructed
> AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode
> and an integrity mode and derive the E and I keys from a single key
> internal to the constructed mode - say  AES-CBC with CMAC for example).
> Short answer is probably not.
>
> Basically, this complete eliminates the ability to use CBC (or any cipher
> mode that requires an explicit per message IV) from TLS.  Not arguing for
> or against this at this point, but not clear that everyone understands the
> side effects of this decision.
>

As discussed at the interim, I don't believe that this is correct. See
AGL's message
for a proposed construction.

-Ekr



Mike
>
>
>
> On 3/16/2015 7:54 PM, Eric Rescorla wrote:
>
>  PR: https://github.com/tlswg/tls13-spec/pull/155
>  Target merge date: 3/21
>
>  Currently:
>
>  - AES-GCM uses a partially explicit nonce
> - The ChaCha20 draft uses the sequence number as the nonce.
>
>  As Stephen Kent has observed, the idea behind the explicit IV is to
> allow the
> cryptographic module implementing the AEAD algorithm to ensure non-reuse
> of the nonce. However, for ChaCha I believe we came to the conclusion that
> it
> was acceptable to use the sequence number as the nonce, as the module can
> check for sequential usage. This saves 8 octets on the wire.
>
>  In the interim in Seattle, we came to the conclusion that we should make
> all AEAD algorithms behave this way, which also simplifies the spec some.
> I've formatted this into a PR to verify the consensus on the list. Please
> comment
> here if you object and on the PR if you have editorial comments.
>
>  https://github.com/tlswg/tls13-spec/pull/155
>
>  -Ekr
>
>
>
> _______________________________________________
> TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>