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

"Dang, Quynh (Fed)" <> Tue, 24 May 2016 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 378BC12D94D for <>; Tue, 24 May 2016 10:56:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3QR0YRxBivoE for <>; Tue, 24 May 2016 10:56:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5632312D928 for <>; Tue, 24 May 2016 10:56:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oB0nBPJjb0UgS2IBNp12b2w+VwE0GoRU6QFHGfkTTYs=; b=1F1kPEFZ0Vk7lLdBETyfDO9vZ4J2HkynEXOkmjncF0mXRZ8H2q/nAqGwnJLrXB5VsVtB6xQaceF+zIs3eDXCZy2+sNWoeKjpsPpEXWpDRA/P4aCg6l3NZcJoD0EwQwJtmgXQyQPYLoFHAlw3SBo1mvY2MbscROioBGCUboQpXEc=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 17:56:04 +0000
Received: from ([]) by ([]) with mapi id 15.01.0501.012; Tue, 24 May 2016 17:56:04 +0000
From: "Dang, Quynh (Fed)" <>
To: Ilari Liusvaara <>, "Dang, Quynh (Fed)" <>
Thread-Topic: [TLS] Comments on nonce construction and cipher text size restriction.
Thread-Index: AQHRtc/HWUjUunA/c0agQBPElmd3kJ/IT3GA///M8wA=
Date: Tue, 24 May 2016 17:56:04 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 82cc94f9-9511-4d02-4f54-08d383fcacde
x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:H6jpv2DVYF2S9gYPNxHWkxbOWSPV230xyIodvGcPDhFDJYvx93DQu2GSYiz8qCLj8OH1HCyPB9ArSpP0/SPvf8o8my+b6tRHnYqL0z0q/RGFNnFX9rtA8jh3iTmTDWzBX8ZIJ0nmVjETA9qv43SbnA==; 24:GrEWMKpSM1r+9V9KdPS8EGT3Wtmj8f1E4d8sdz1GV/o+sQjIOf00NfimX1DpeRsve+YIq58PHCGrOZaHv8kAxo12TmjgcNMp99Eb6cVIwd8=; 7:YtFXzpeFR6lRg5FzKEcqLbpdA0tbr0brue4Y0+N9K2F2qfRqlZUjOeExRXf5I0nuQUmfS4LKLhVMmFbZy7lhT+Ah74+ThrA9dlzCbl0DuurWFa5SunO281R2cPE2unT829XhNoUQeOoQhOA+9r9iZymHw2NXY+qa6P91d/t0cwHBmzgRWjORSMy/BVFEHlcs
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123;
x-forefront-prvs: 09525C61DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(83506001)(102836003)(6116002)(10400500002)(3280700002)(2900100001)(5001770100001)(3660700001)(3846002)(8676002)(4001450100002)(5004730100002)(5002640100001)(586003)(189998001)(122556002)(54356999)(2950100001)(2906002)(4326007)(4001350100001)(5008740100001)(92566002)(19580405001)(19580395003)(8936002)(81166006)(1220700001)(11100500001)(36756003)(106116001)(99286002)(77096005)(76176999)(86362001)(87936001)(50986999)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 17:56:04.1650 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Comments on nonce construction and cipher text size restriction.
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 May 2016 17:56:08 -0000

On 5/24/16, 12:58 PM, " on behalf of Ilari
Liusvaara" <> wrote:

>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
>> 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

I don¹t think so. 

>> 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).

I did not recommend using short random nonces. If the current construction
of nonces is for GCM, than that would be fine and recommended. But,
currently, it is written as for all ciphers.  If the construction of nonce
is not fixed, then an encryption mode just needs to specify its own way of
generating nonces. 

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

See comment above.