Re: [TLS] Consensus for AEAD IV

Michael StJohns <> Sun, 26 April 2015 21:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BF6E71A1B89 for <>; Sun, 26 Apr 2015 14:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wyPII3UKh29e for <>; Sun, 26 Apr 2015 14:18:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1FDB1A1B57 for <>; Sun, 26 Apr 2015 14:18:41 -0700 (PDT)
Received: by vnbg190 with SMTP id g190so9710759vnb.8 for <>; Sun, 26 Apr 2015 14:18:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=myh3mGECi3pzyYR4leyBK7jtGDxDN/poF10BrRTv+a4=; b=Hlpvd4WVMAqsxqUKWzQyRrza4z+nufrqgqTjEYL/awB0VtelUEo/2gjVeMT0GjulgP hHdw5TanRgimjM7djLCPkhQ0BiM7tWoyOVIPhrxfWfA8IDpJs6AZ2L4LOy/g4mTeD06l Hito8Sk+T2DyEROZo2yOXroWUF90tm/xBtD/o/UxqPfTK5pjbziK6873Li13jdaNVswR P2OdwQzUg1RA0KT3i3CmicApdu7VxLh3FL8oDBmscYbexRA6YtHbNyhEcoNobrpK0kUE NJ7Hgur95mn38+jFpSByCcRXX1r7dWx8wahVZHiGXjJuntD4j0jfvqAVFL7YlK0b78pn q9Fw==
X-Gm-Message-State: ALoCoQk6xIIzYJ+dRfGP/LpJQ+yN+RUnhZioNHu67oJx504atGse70jix5Q85BhhmsYvRGzB9EU5
X-Received: by with SMTP id ft16mr20497735vdb.81.1430083120925; Sun, 26 Apr 2015 14:18:40 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:84:cae:d6cf:19b5:13bc? ([2601:a:2a00:84:cae:d6cf:19b5:13bc]) by with ESMTPSA id q9sm20532340vdb.20.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Apr 2015 14:18:40 -0700 (PDT)
Message-ID: <>
Date: Sun, 26 Apr 2015 17:18:39 -0400
From: Michael StJohns <>
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 <>
References: <> <> <> <> <> <> <20150426182025.GA3549@LK-Perkele-VII> <> <20150426203423.GA6935@LK-Perkele-VII>
In-Reply-To: <20150426203423.GA6935@LK-Perkele-VII>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] Consensus for AEAD IV
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 26 Apr 2015 21:18:42 -0000

On 4/26/2015 4:34 PM, Ilari Liusvaara wrote:
> On Sun, Apr 26, 2015 at 04:26:32PM -0400, Michael StJohns 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.
>>> Oh, except SSH. The session nonce is 96 bits and secret.
>> SSH uses CBC exclusively as far as I can tell.

*sigh* I looked at the original SSH rfc and for some reason none of the 
new modes were added to that RFC as "Updates".

>>   The fact that the mixin  of
>> the first block of the first message (AKA the initial IV) is generated via
>> keyed material from the negotiated shared secret is actually a problem
>> (similar to the problems in TLS 1.2 and before) and doesn't actually provide
>> any security.
> SSH can also use:
> - CTR (start from 128-bit secret initial IV, no packet boundaries)
> - AES-GCM (96 bit secret initial IV, increments per packet)
> - Chacha20-Poly1305 (uses message sequence as nonce)
> (In fact, I think the semi-offical recommendation is "don't use CBC in SSH").

The fact that SSH was designed with CBC and that you got no security 
from CBC by doing it this way is the key point.  The fact that new modes 
have come along and just used what they were handed doesn't really add 
to the "the IV must be secret" argument.

In other words, it wasn't done this way originally to increase security 
so using it as an example for good practice is probably somewhat bogus.

> -Ilari