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