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

Martin Thomson <> Tue, 01 July 2014 22:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86C061A03FD for <>; Tue, 1 Jul 2014 15:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PC-1RdXGcpuD for <>; Tue, 1 Jul 2014 15:31:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 752331A0ABA for <>; Tue, 1 Jul 2014 15:31:26 -0700 (PDT)
Received: by with SMTP id hi2so8601945wib.7 for <>; Tue, 01 Jul 2014 15:31:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rST06LKp5ghXjpmmjpEExD1pWFHH5EafbnhvdxnLtMY=; b=nwFfF0Dff5ylzGcEb3MfFg44an14T7EuqnuBoFjWuUJg+aY2yof2/tQ8AIcJ0+YXw8 NwsXMdIJ27XFQWwwl0py/Fm01dNJF57ATxleD9ZajkitYaHD8SJ8oAN2Bzj4OpYYtjCN gEvrOkCUsY+ouAAzLL7KkLDDEabVGRrDMblRUmI/tvbUIOuMEuDi2VXq2Vm8fqV+FoqN lG8W+C6DDpNSysjXP3eHtQHhF4GFNuNzmACcE9fuVEWa81ICzA9hwMJ4jm5Q03fpk2aS 7OGzSfhNHvozyp19qh0syBWUFSqHQtLNHAat9z531v6ZFyRMv6YigxEMzL3sEgkena6N EXQA==
MIME-Version: 1.0
X-Received: by with SMTP id hc10mr15554694wib.47.1404253884993; Tue, 01 Jul 2014 15:31:24 -0700 (PDT)
Received: by with HTTP; Tue, 1 Jul 2014 15:31:24 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 1 Jul 2014 15:31:24 -0700
Message-ID: <>
From: Martin Thomson <>
To: Daniel Kahn Gillmor <>
Content-Type: text/plain; charset=UTF-8
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: Tue, 01 Jul 2014 22:31:27 -0000

On 1 July 2014 15:09, Daniel Kahn Gillmor <> wrote:
> If this change is made, it's also relatively easy to just drop the TLS
> version field for each encrypted TLS record layer fragment.

I'd like to see that happen.

I think that the bit that causes me a little concern is that content
type shifts around, with a special case.  If you have a special case
like that, then there isn't much of a difference between moving it
while under encryption to moving it always (other than the need to
keep ClientHello clean.  But that doesn't seem like the right answer

It's more disruptive, but if the definition of the AEAD cipher were to
encompass the entire struct, then you could define NULL_NULL in a way
that placed content type in the old location.  I don't know if that is
any better, though it would probably be the way I'd structure software
that processed the record layer.

Then you have a different structure in place of TLSCipherText on which
the construction depends on the cipher.  NULL_NULL can define
something that looks like legacy TLS: ContentType, Version,
Payload.length,  Ciphersuite constructions can define
something like this: Payload.length, Nonce, Encrypted { ContentType, }; with variance discouraged, but possible.