Re: [TLS] Comments on nonce construction and cipher text size restriction.

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 24 May 2016 16:58 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 087A312D8F6 for <tls@ietfa.amsl.com>; Tue, 24 May 2016 09:58:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 NP_SwZrmv8gB for <tls@ietfa.amsl.com>; Tue, 24 May 2016 09:58:51 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 47C6D12D147 for <tls@ietf.org>; Tue, 24 May 2016 09:58:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C876D86AA; Tue, 24 May 2016 19:58:48 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id qXDDLEVg6i4H; Tue, 24 May 2016 19:58:48 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-155-121.bb.dnainternet.fi [87.100.155.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 7BBCA2310; Tue, 24 May 2016 19:58:48 +0300 (EEST)
Date: Tue, 24 May 2016 19:58:45 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "Dang, Quynh (Fed)" <quynh.dang@nist.gov>
Message-ID: <20160524165845.GB23887@LK-Perkele-V2.elisa-laajakaista.fi>
References: <D369E95C.267A5%qdang@nist.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <D369E95C.267A5%qdang@nist.gov>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/XKlHQl8wQWVn8nvs1q_MinV7IUE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 24 May 2016 16:58:55 -0000

On Tue, May 24, 2016 at 03:20:17PM +0000, Dang, Quynh (Fed) wrote:
> Hi Eric,
> 
> 1. For this text:  "plus the length of the output of the signing
> algorithm. " in the last paragraph of Section 4.8.1, did you mean
> "plus the output of the signing algorithm." ?

The paragraph seems to talk about the length, so plus length of seems
correct.

> 2. "The length (in bytes) of the following TLSCiphertext.fragment.
> The length MUST NOT exceed 2^14 + 256. An endpoint that receives a
> record that exceeds this length MUST generate a fatal "record_overflow"
> alert. " . There could be a cipher that generates ciphertext longer
> than plaintext in some cases plus the tag. If the tag was 256 bits,
> then this requirement would disallow that cipher unnecessarily when
> a record size is 2^14.

It is not in bits, it is in bytes. So to blow the limit, you would need
cipher that expands the plaintext by 256 bytes (remember the typebyte
counts as plaintext input here).

And what algorithm would have >2040 bits of expansion?

Variable-tau MRAEs could have larger expansions, but practical
parameters limit expansion much below that value.

> 3. "The padded sequence number is XORed with the static client_write_iv
> or server_write_iv, depending on the role." I think the ivs are not
> needed.

Oh, they are needed (as in, security will be degraded if IVs are
removed).
 
> 4. The current way nonce is specified would disallow ciphers that
> use any other ways of generating the nonce such as random nonces.

None of the present algorithms is able to handle a random nonce,
you would need much longer nonces.

And also, it is much easier to just count than try to randomly
generate "nonces" (and as far as it is known, more secure,
due to random "nonces" having tendency to repeat).

And TLS breaks in truly catastrophic way if GCM nonce ever
repeats (and wasn't there just such problem in multiple TLS
implmenentations)?


-Ilari