Re: [TLS] Consensus for AEAD IV

Yoav Nir <ynir.ietf@gmail.com> Sun, 26 April 2015 22:26 UTC

Return-Path: <ynir.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 3C6BC1A1B28 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 15:26:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 dDhjIgjRpM3V for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 15:26:11 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 D3C5A1A1A82 for <tls@ietf.org>; Sun, 26 Apr 2015 15:26:10 -0700 (PDT)
Received: by wicmx19 with SMTP id mx19so71254470wic.1 for <tls@ietf.org>; Sun, 26 Apr 2015 15:26:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UntRRlmPf1LdKpzJJMn1f4WTKdPeJmQkElOhyT/YbRw=; b=z6B24uSj5yTlU+SqjhoFTo/jC6sI84H969n5cdX5JUPRNmbU+PnaQcL0KbwNQNasWu kxYsmmRiP/9jWifRN2rI8iHnBAKllra6Q7cqQFZPLz9sZPOlMQdrINUhiHxA7YwcDpOI P/tVoTBj2BBngQo0W3XCM3PflJb/9c2nr4iNL0S4ICBQO0TfKKzhkIlGhU/J4mtSM/N4 fBiqkr7uwLTzhbyDanwg0AIja+YsSopgNOV1jv9mGU0pklddDKBSkKasu14xpVojE8kn Y9nK1fscFib5QKW2X9PTKBU8ZgUhikwcABsO5u9bxFPpKl09z98cAQXnglE5Dip0X6Pf Gpgg==
X-Received: by 10.180.105.233 with SMTP id gp9mr15483138wib.83.1430087169587; Sun, 26 Apr 2015 15:26:09 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id g11sm316005wjr.25.2015.04.26.15.26.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Apr 2015 15:26:08 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <553D5898.3090902@nthpermutation.com>
Date: Mon, 27 Apr 2015 01:26:06 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E5464E9-80BF-4D2E-A6C1-EF4E47A99268@gmail.com>
References: <CAOgPGoC14uhjrZAQvDHFQrJoyoVNELpNNd4+Hh==zwf9ipyY5g@mail.gmail.com> <CABkgnnU50pvH+LFsN3BL9LfvYhZOxmJV1JYzODeC=-JpZSh8Lw@mail.gmail.com> <CAOgPGoDNuhmnNpZ7ELCfBHS4rKuj+3j1+YiuxLkST+z1J+tOKQ@mail.gmail.com> <553C59B2.6050000@nthpermutation.com> <7E7D3069-2021-4691-AEA6-70DD1AB4476C@gmail.com> <553D27D0.7040209@nthpermutation.com> <20150426182025.GA3549@LK-Perkele-VII> <553D5898.3090902@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/HQmj4VRES45v9euBtaYLQv7SB98>
Cc: tls@ietf.org
Subject: Re: [TLS] Consensus for AEAD 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: Sun, 26 Apr 2015 22:26:13 -0000

Both CCM and GCM use a concatenation of the explicit IV (which is obviously not secret and allowed to be predictable) with a salt that is derived from the keying material. This concatenation forms the nonce which is input to the AEAD.

RFC 4309 (CCM) says "The salt value need not be secret, but it MUST NOT be predictable prior to the beginning of the security association.”
RFC 4106 (GCM) says "The salt SHOULD be unpredictable (i.e., chosen at random) before it is selected, but need not be secret.”

The ChaCha20-Poly1305 for IPsec draft does the same thing, and in fact so does RFC 5288 (AES-GCM for TLS 1.2)

So no, that salt (and by extension, the proposed 96-bit value) need not be secret, but it’s never transmitted. This also shows that there is good precedent for generating such a doesn’t-really-need-to-be-secret value from the key_block or KEYMAT.

Yoav

> On Apr 27, 2015, at 12:28 AM, Michael StJohns <msj@nthpermutation.com> wrote:
> 
> On 4/26/2015 2:20 PM, Ilari Liusvaara wrote:
>>> There is no reason to treat the 96 bit quantity as secret and no one else
>>> >does.
>> (To lesser extent, IPSEC, there the session nonce is 32 bits and secret).
>> 
> 
> This is directly from section 2.3 of the IPSec ESP RFC 4303
> 
> 
>> With regard to ensuring the alignment of the (real) ciphertext in the
>>    presence of an IV, note the following:
>> 
>>          o For some IV-based modes of operation, the receiver treats
>>            the IV as the start of the ciphertext, feeding it into the
>>            algorithm directly.  In these modes, alignment of the start
>>            of the (real) ciphertext is not an issue at the receiver.
>> 
>> 
>>          o In some cases, the receiver reads the IV in separately from
>>            the ciphertext.  In these cases, the algorithm specification
>>            MUST address how alignment of the (real) ciphertext is to be
>>            achieved.
> 
> And RFC4309 - CCM mode has this:
> 
>> ESP Payload
>> 
>>   The ESP payload is composed of the IV followed by the ciphertext.
>>   The payload field, as defined in [ESP], is structured as shown in
>>   Figure 1.
>> 
>>       0                   1                   2 3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>      |                     Initialization Vector                     |
>>      |                            (8 octets)                         |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                                                               |
>>      ~                  Encrypted Payload (variable)                 ~
>> |                                                               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> |                                                               |
>>      ~                 Authentication Data (variable)                ~
>> |                                                               |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> Again, newer modes may have done something else, but the above is strong indication that IVs were not generated as secrets as a general matter.
> 
> Later, Mike
>