Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

"Dang, Quynh (Fed)" <> Tue, 12 July 2016 13:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A54EF12DA0B for <>; Tue, 12 Jul 2016 06:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 nDx1bCuzTUCh for <>; Tue, 12 Jul 2016 06:22:58 -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 E844612DA0C for <>; Tue, 12 Jul 2016 06:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J9e7OKO6xdNnDPh8B3uc5mU4XsQjgrajFa++8qB0U+E=; b=O1nUPv0rVuHxuMtS5j0nDBi2XCwdhi/OPjiAgkdH2Dc889InAZfWE6lz0k5ir1qt4GX1oHMHJujS0aFDuxpaC5tbeLkz/XnFCCMkfw6UhOkk/IWr60pJ0mlkqEJUooIXxHF+4wujRnhDz+5MC+CW8+aXeeE3MJgZVm4+kvLnAQk=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 13:04:11 +0000
Received: from ([]) by ([]) with mapi id 15.01.0534.023; Tue, 12 Jul 2016 13:04:11 +0000
From: "Dang, Quynh (Fed)" <>
To: Eric Rescorla <>, "" <>
Thread-Topic: [TLS] New draft: draft-ietf-tls-tls13-14.txt
Thread-Index: AQHR26erSXFdspEwbEKLZA1rqxpGgqAUgWIA
Date: Tue, 12 Jul 2016 13:04:11 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 37322e57-210d-4a77-b3ba-08d3aa550485
x-microsoft-exchange-diagnostics: 1; BN1PR09MB0172; 6:uD86Wc27yVLJ0oj+AnqKCxplgnvRhGMDfl9VRfN5Mwht7c30CJbpwC1shFFY6fD+NspWLcagWWNYzNg6a2cdyrMKLwpVeUaLeY0hLDBcfJWIV8ZyiHQZdGMggYivgHpyDqQhNWCWA3gziDfzMoWrBJ6nbTpyfnkF3IBJ3kNtnoNtHn3J1UAqTefYFfX+NDdSmY2u4MjsbWsPiCRlCF7Ac3F9+GhEYuUzCNb+O/4prj5wv/6X6GiVHRXaZa4wSDA53jhj6RwNQaR/OZ+KlO7Han61/N7gx5H5c21hS1WWOxYZUmyGYhqbRl/q6/99g3RZcEHMswIqlT9UfJkOowxL7w==; 5:+/7tFuF9WKZmuyxWdSd5eqD5rRu3RbiXI5INnADT6w27i+p8zhc2hjC847B5pC7rRCc/6PyFidb+X2U4A/V0GfAftNucXyuSEmyxJe4ILrda7wDjWMah1LuE/w+naFrJkZbx8LafaI/WJXgY8vNQ/A==; 24:kzK+aTCChVZE7WghEFIOyTmkNoawfOFnULVcLhH+RZugyXD9Yf9uudCaldZDh2AcWzEQzWaKxdOA+Iu8Ps0C6feWKndcD1Gi9roIXLRw1iw=; 7:Gd8oScVwliMR+S+6+K7z1ML74rSJE7cgAyVZ1/MDZtSnyRNS/4hKyS4Qvgr8NwLhFjzZOtLjgKK0Gq5xqnwWUFICEKCoaNIzrKghUpQWyDvdwx7hYN4wyRBcFLOZMWVz9XqxEbWn84NPSBrJ+BYgoHH+8mz8LbdPYaJngS5vUO6vPg+qabLzdBtunqoRS0LAP3/B46J+dqd7iaRy4WFF0r7EXu5H0uSoYHRf1QGpdYVfbMBKSycfv+dIKTmIzHnn
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB0172;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:BN1PR09MB0172; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB0172;
x-forefront-prvs: 0001227049
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(55674003)(199003)(377454003)(189002)(83506001)(36756003)(7736002)(7846002)(11100500001)(7906003)(5001770100001)(2950100001)(105586002)(66066001)(5002640100001)(68736007)(4001350100001)(97736004)(106356001)(101416001)(77096005)(122556002)(50986999)(76176999)(107886002)(92566002)(2501003)(19617315012)(54356999)(189998001)(8676002)(81156014)(99286002)(3846002)(586003)(87936001)(6116002)(8936002)(102836003)(3280700002)(81166006)(16236675004)(2900100001)(10400500002)(86362001)(15975445007)(19580395003)(19580405001)(106116001)(2906002)(230783001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0172;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D3AA5BD627AC0qdangnistgov_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 13:04:11.0544 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB0172
Archived-At: <>
Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
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, 12 Jul 2016 13:23:04 -0000

Hi Eric and all,

In my opinion, we should give better information about data limit for AES_GCM in TLS 1.3 instead of what is current in the draft 14.

In this paper:,  what is called confidentiality attack is the known plaintext differentiality attack where the attacker has/chooses two plaintexts, send them to the AES-encryption oracle.  The oracle encrypts one of them, then sends the ciphertext to the attacker.  After seeing the ciphertext, the attacker has some success probability of telling which plaintext was encrypted and this success probability is in the column called "Attack Success Probability" in Table 1.  This attack does not break confidentiality.

If the attack above breaks one of security goal(s) of your individual system, then making success probability of that attack at 2^(-32) max is enough. In that case, the Max number of records is around 2^38.


Date: Monday, July 11, 2016 at 3:08 PM
To: "<>" <<>>
Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt


I've just submitted draft-ietf-tls-tls13-14.txt and it should
show up on the draft repository shortly. In the meantime you
can find the editor's copy in the usual location at:

The major changes in this document are:

* A big restructure to make it read better. I moved the Overview
  to the beginning and then put the document in a more logical
  order starting with the handshake and then the record and

* Totally rewrote the section which used to be called "Security
  Analysis" and is now called "Overview of Security Properties".
  This section is still kind of a hard hat area, so PRs welcome.
  In particular, I know I need to beef up the citations for the
  record layer section.

* Removed the 0-RTT EncryptedExtensions and moved ticket_age
  into the ClientHello. This quasi-reverts a change in -13 that
  made implementation of 0-RTT kind of a pain.

As usual, comments welcome.

* Allow cookies to be longer (*)

* Remove the "context" from EarlyDataIndication as it was undefined
  and nobody used it (*)

* Remove 0-RTT EncryptedExtensions and replace the ticket_age extension
  with an obfuscated version. Also necessitates a change to
  NewSessionTicket (*).

* Move the downgrade sentinel to the end of ServerHello.Random
  to accomodate tlsdate (*).

* Define ecdsa_sha1 (*).

* Allow resumption even after fatal alerts. This matches current

* Remove non-closure warning alerts. Require treating unknown alerts as

* Make the rules for accepting 0-RTT less restrictive.

* Clarify 0-RTT backward-compatibility rules.

* Clarify how 0-RTT and PSK identities interact.

* Add a section describing the data limits for each cipher.

* Major editorial restructuring.

* Replace the Security Analysis section with a WIP draft.

(*) indicates changes to the wire protocol which may require implementations
    to update.