Re: [TLS] Prototype of TLS 1.3 records, padding, and optional headerless records
Benjamin Kaduk <bkaduk@akamai.com> Mon, 14 December 2015 17:43 UTC
Return-Path: <bkaduk@akamai.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 439A91ACE8D for <tls@ietfa.amsl.com>; Mon, 14 Dec 2015 09:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.611
X-Spam-Level:
X-Spam-Status: No, score=-0.611 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZYWAdCOSchVK for <tls@ietfa.amsl.com>; Mon, 14 Dec 2015 09:43:32 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id BEA061ACE81 for <TLS@ietf.org>; Mon, 14 Dec 2015 09:43:32 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 18DAD425CBB; Mon, 14 Dec 2015 17:43:32 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 00BA3425C99; Mon, 14 Dec 2015 17:43:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1450115012; bh=L52vw2FjKksvVP/hoIM4QlCrLoE0L5WlCqp9MsMG63A=; l=1302; h=To:References:From:Date:In-Reply-To:From; b=lU+oYy2dSOylPM6mq2TW2K8QrCKyCA6GzsIf3QKXLADQEAauyR6Ruz/ttR6l3YpQk +bPMQuVjobUdoIEOXWIOwW89PtGzUimz5YKX1XiqFrtnJDeUiSP6CPpSgfjwj9Tbd9 b4ld+exU5ew5/l/TapGcyJSOVKK34u74Bn+9hM0I=
Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BFAD42039; Mon, 14 Dec 2015 17:43:31 +0000 (GMT)
To: Bryan A Ford <brynosaurus@gmail.com>, "tls@ietf.org" <TLS@ietf.org>
References: <566BF6F4.7050100@gmail.com>
From: Benjamin Kaduk <bkaduk@akamai.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <566EFFC3.1090400@akamai.com>
Date: Mon, 14 Dec 2015 11:43:31 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <566BF6F4.7050100@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/zm_rmYCzViRZjB6xRr77w2iEEb4>
Subject: Re: [TLS] Prototype of TLS 1.3 records, padding, and optional headerless records
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: <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: Mon, 14 Dec 2015 17:43:35 -0000
On 12/12/2015 04:29 AM, Bryan A Ford wrote: > --- > OK, congratulations and thanks to anyone who persisted through all that. > I hope this will help understand the implementation complexity and > tradeoffs both of the currently-specified TLS 1.3 record layer and the > proposed headerless records features. Comments? > This makes me less uneasy than the previous proposals did. As a general note, a protocol having two (or more) options for how to express a given piece of information leads to more cases to test, and has caused interoperability and/or security problems in the past. No comment from me yet as to whether the tradeoff is acceptable in this case. But, my general sentiment remains one that I did not get to express in the previous thread (I was travelling and it had become somewhat stale): will attempting to add this to TLS 1.3 incur unacceptable delay for wide-scale deployment? TLS 1.3 has a lot of really nice things in it, that we would like to get to users as soon as safely possible. There is the TRON workshop scheduled, etc., indicating that if all goes well, the spec could be final in the next 6 months. Is the added value of this scheme worth another month of delay before TLS 1.3 ships to users while we argue about it? Another six months? -Ben
- [TLS] Prototype of TLS 1.3 records, padding, and … Bryan A Ford
- Re: [TLS] Prototype of TLS 1.3 records, padding, … Benjamin Kaduk
- Re: [TLS] Prototype of TLS 1.3 records, padding, … Bryan Ford