Re: [TLS] Consensus for AEAD IV

Michael StJohns <msj@nthpermutation.com> Sun, 26 April 2015 21:28 UTC

Return-Path: <msj@nthpermutation.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 BFE9E1A6EF1 for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 14:28:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KleLRNSl_ubq for <tls@ietfa.amsl.com>; Sun, 26 Apr 2015 14:28:58 -0700 (PDT)
Received: from mail-vn0-f52.google.com (mail-vn0-f52.google.com [209.85.216.52]) (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 86F4A1A1A4B for <tls@ietf.org>; Sun, 26 Apr 2015 14:28:58 -0700 (PDT)
Received: by vnbf62 with SMTP id f62so9740433vnb.13 for <tls@ietf.org>; Sun, 26 Apr 2015 14:28:57 -0700 (PDT)
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=3Hze+ue6C2nWWzbzsOrUQcBIe7fscRYz3/QqoQPuDPw=; b=DTp5HIqE9kXM/anirilfZCCQc61aoPkpmjNl1CykAl1lTEAdFUxraXqpNQVi0ySOlc g0j85G3gR7AiZetnlMHPBliT54TI4YHfWGicNgY6ewco1iOC0596XLQNcrzpSifvz83P 9iWPvfwdht0L6HBT5iT4BdAboZTjSyTBqqLO2+T/d2h89bwgXDsGG4X04IaOUn6yPUz0 iTTG04oUM7HXpLFLvN/wQvU7eN1D+vm7Gc7Xrw81DIZcGe3X7DZHcyO/foOaldHCqPEh 7CeUVNdIEFH5SEjnJ4zneLfF7VDE/GsVdgZsPEN/Yv3qviGB+ucCKn4ugvHXpNZvy52q tEwA==
X-Gm-Message-State: ALoCoQnps3VqybcGF395L3YmXLdJksQouRg3GjcqrxXm9xED+ML3hmghIyCwQ7LDC5gpalUBbFWQ
X-Received: by 10.52.252.74 with SMTP id zq10mr20667158vdc.18.1430083737764; Sun, 26 Apr 2015 14:28:57 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by mx.google.com with ESMTPSA id hq1sm20593845vdb.24.2015.04.26.14.28.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 14:28:57 -0700 (PDT)
Message-ID: <553D5898.3090902@nthpermutation.com>
Date: Sun, 26 Apr 2015 17:28:56 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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>
In-Reply-To: <20150426182025.GA3549@LK-Perkele-VII>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vXKLZTe22h8B0DfM4u7ztJEQvXI>
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 21:28:59 -0000

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