Re: [TLS] Encryption of TLS 1.3 content type

Daniel Kahn Gillmor <> Mon, 28 July 2014 15:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6D761B2899 for <>; Mon, 28 Jul 2014 08:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1kvXXMCtZwAk for <>; Mon, 28 Jul 2014 08:08:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 740681B2866 for <>; Mon, 28 Jul 2014 08:08:36 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id C9C27F984; Mon, 28 Jul 2014 11:08:33 -0400 (EDT)
Message-ID: <>
Date: Mon, 28 Jul 2014 11:08:20 -0400
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Icedove/30.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="538W7jSUHokVixwoehCpd1SqOsVlUsaIK"
Subject: Re: [TLS] Encryption of TLS 1.3 content type
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jul 2014 15:08:45 -0000

On 07/28/2014 10:39 AM, Martin Rex wrote:
> I also object to the removal of the ContentInfo from the outer
> TLS record protocol.  I'm not aware of the slightest rationale for
> this severe backwards incompatibility, that will not just break
> middle-boxes, but also applications that parse TLS records for the
> purpose of non-blocking operation.

Parsing TLS records is still possible, since the length field will be

I tried to highlight your concern about non-blocking applications to the
TLS WG during the interim meeting last Sunday, but clearly failed to do
it justice because none of those attending the interim (including
myself) appeared to understand what specific toolchain you were trying
to preserve.

Can you provide more details?  Applications that just look at the raw
TLS records will still be able to tell when the communication shifts
from cleartext to non-cleartext, but they should not be able to see more
than that about the ciphertext.

In what case is this a problem?