Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00

Yoav Nir <> Wed, 23 July 2014 21:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 678711A0AF2 for <>; Wed, 23 Jul 2014 14:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fukukfUQSYxO for <>; Wed, 23 Jul 2014 14:25:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9FC41A0AEC for <>; Wed, 23 Jul 2014 14:25:19 -0700 (PDT)
Received: by with SMTP id x48so1851264wes.33 for <>; Wed, 23 Jul 2014 14:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HcgMY2KZ9BlHjhkk3OWFa4mAtFDVQuwRoCcDSvqjPKk=; b=VmufvTd7rlg6F4FrXEM2V76q14AZDEpWvt0hBg1z0wDZ43EtPvtN2e/AMj07r3jnAK lqN/A1ViFdGRCQsoy6qykq+LCFF5HdJiOzrmWi6HGHeNkYDA2dMUbYDbTVkL4+LYmEhq GqUz4Ut5PBzEquw78Vc9qsLwFwjbjnRUKEmsXEMawTyWnxRsMpKwMyqDG9DdDSpiaEmU gndkelzAMk4nGqns87UJEn/FZ1co5m1rm/yr0JlZb6ZPWuPTbLSF2O8ocIIEEJs95khV 40fkuARuIRRRUgWBQKHguQ0U3O3LTyHL/P/ACa9LldD9vgI9igBDZv4yq2Ip6JnotAJW O4CA==
X-Received: by with SMTP id n7mr5876379wjx.8.1406150718348; Wed, 23 Jul 2014 14:25:18 -0700 (PDT)
Received: from ([2001:67c:370:160:98aa:ef28:d4ce:23b0]) by with ESMTPSA id p3sm9556273wjw.13.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 14:25:17 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 23 Jul 2014 17:25:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1878.6)
Cc: "" <>
Subject: Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
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: Wed, 23 Jul 2014 21:25:21 -0000

On Jul 23, 2014, at 4:41 PM, Martin Thomson <> wrote:

> On 23 July 2014 12:44, Martin Rex <> wrote:
>> There has been a proposal to hide the ContentType for TLSv1.3
>> and break lots of existing software that relies on being able
>> to parse TLS records:
> We discussed fixing that at the interim meeting where that proposal
> was discussed.  The fix is trivial; we could, for instance, always
> send 23.  Or, we could use Fluffy's proposed new registry to obtain a
> different demux byte value.  I suspect that the former is fine.

We also talked about padding to hinder traffic analysis. I think we can solve both at the same time by doing something like this (sorry for not using TLS curly bracket notation):

Record header remains the same, except the contentType 23 gets renamed to “encrypted”.

When decrypted, the encrypted record has a three-byte header:
  1 byte - ContentType. Either 23 means “application data” here, or we use a new number for it. something else for alert, etc. Zero can be used for a special, all-padding record that can be discarded.
  2 bytes - length. The difference between the decrypted length and this field is the padding.

If we limit ourselves to only 4 types of encrypted record (app data, alert, padding and some yet unspecified fourth type - handshake?) we can use a 2-byte header and use the two free bits from the TLS record length.