IETF Logo Mail Archive

Re: [TLS] proposal to encrypt ContentType for TLS 1.3

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 14 July 2014 14:30 UTC

Return-Path: <dkg@fifthhorseman.net>
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 1358C1A063A for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 07:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 M0iUmiDfUVN5 for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 07:30:23 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id B4DCC1A05C0 for <tls@ietf.org>; Mon, 14 Jul 2014 07:30:23 -0700 (PDT)
Received: from [10.70.10.130] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id BC32CF984; Mon, 14 Jul 2014 10:30:20 -0400 (EDT)
Message-ID: <53C3E973.4070504@fifthhorseman.net>
Date: Mon, 14 Jul 2014 10:30:11 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
To: mrex@sap.com
References: <20140714141257.9C2441ADA7@ld9781.wdf.sap.corp>
In-Reply-To: <20140714141257.9C2441ADA7@ld9781.wdf.sap.corp>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="Kqw0CEelS4gpooNWft35bPEm9VHARL6fQ"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lBkpyr05EtEjxF6SWawUmcTeC5g
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
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: <http://www.ietf.org/mail-archive/web/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 Jul 2014 14:30:28 -0000

On 07/14/2014 10:12 AM, Martin Rex wrote:
> Daniel Kahn Gillmor wrote:
 [...]
>> The fact that network-facing code won't know with certainty when a
>> handshake completes and when application data starts flowing seems like
>> a feature, not a bug, if we want to protect the communication.
> 
> I definitely see it as a feature.

I'm glad to hear it :)

> The bug here would be an unnecessary difference to existing TLS protocol versions.
 [...]
> Drop-in replacement of only the TLS stack will be impossible.

Yes, I'm suggesting that for people in the unusual situation of having
moved their network i/o state machine entirely outside of their TLS
stack, they'll want to update their network i/o state machines first (to
understand the new traffic patterns), before upgrading their TLS stacks
to support TLS 1.3.

It seems entirely possible that this will be the case anyway, given the
new handshake flows proposed for TLS 1.3.

I don't think this is a good reason to avoid the improvement.

Regards,

	--dkg

v2.23.0 | Report a Bug | By Email