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

Daniel Kahn Gillmor <> Sun, 13 July 2014 16:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5757D1B2AA1 for <>; Sun, 13 Jul 2014 09:42:50 -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 gU_HNpsn7g8p for <>; Sun, 13 Jul 2014 09:42:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA7421B2AA5 for <>; Sun, 13 Jul 2014 09:42:47 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 4D90BF984 for <>; Sun, 13 Jul 2014 12:42:45 -0400 (EDT)
Message-ID: <>
Date: Sun, 13 Jul 2014 12:42:45 -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="vo37eKowKtKIamNPbfE5mf2mdpDXaAIJg"
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
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: Sun, 13 Jul 2014 16:42:50 -0000

On 07/07/2014 12:06 PM, Martin Rex wrote:
> This version field is sometimes helpful for debugging, and
> using the same formatting of the record contents (clear vs. decrypted)
> means less code complexity.

cleartext traffic or the NULL cipher is also helpful for debugging, but
that doesn't mean we should leak it in the TLS protocol.  The code
complexity involved for the endpoints requires no extra state (TLS
engines already know whether they're in NULL_WITH_NULL_NULL or not), and
a amall change to the way the packets are handled in either case.

> There are also going to be problems with implementations where the
> records are read from network in their entirety before being passed to
> and processed by the TLS implementation, and where that network i/o
> state machine is currently using the record type to indicate to
> higher layers whether the handshake is still ongoing.  It's also
> helpful to see in wireshark traces whether a connection was
> terminated by a TLS alert, or whether it may have been interrupted
> by some middlebox or other networking problem.
> What would be the purpose/benefit of this in case that renegotiation
> gets dropped?

It hides TLS alerts from an observer, for one.  If any attack is mounted
which depends on observing which traffic creates a TLS alert, that
attack would be more difficult. it also hides the possibility of an
outside attacker observing a secondary CCS, which could indicate a
change of keying material.  Having the record types encrypted means that
things like re-keying or mid-stream client authentication (both of which
are currently contemplated even if we get rid of renegotiation) then an
encrypted content-type will obscure that activity from a network observer.

> Such a change at the record layer would reliably preculde that we
> ever ship TLSv1.3, because a 2 years ago I've switched to doing
> all network i/o outside of the TLS stack and parsing the records above TLS
> so that we can arbitrarily mix non-blocking I/O with precise application-
> defined network timeouts.

Above you called the engine you were using a "network i/o state machine"
-- if the machinery actually has state, it should still be able to parse
the length of each record, and can keep track of whether a CCS has been
seen or not, so it should be able to continue parsing each record as it
comes in.

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.