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

Yoav Nir <ynir.ietf@gmail.com> Wed, 23 July 2014 21:25 UTC

Return-Path: <ynir.ietf@gmail.com>
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 678711A0AF2 for <tls@ietfa.amsl.com>; Wed, 23 Jul 2014 14:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fukukfUQSYxO for <tls@ietfa.amsl.com>; Wed, 23 Jul 2014 14:25:20 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FC41A0AEC for <tls@ietf.org>; Wed, 23 Jul 2014 14:25:19 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id x48so1851264wes.33 for <tls@ietf.org>; Wed, 23 Jul 2014 14:25:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.194.80.7 with SMTP id n7mr5876379wjx.8.1406150718348; Wed, 23 Jul 2014 14:25:18 -0700 (PDT)
Received: from wireless-v6.meeting.ietf.org ([2001:67c:370:160:98aa:ef28:d4ce:23b0]) by mx.google.com with ESMTPSA id p3sm9556273wjw.13.2014.07.23.14.25.17 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 <ynir.ietf@gmail.com>
In-Reply-To: <CABkgnnVHu=n+LnbaKcLkmzK4KwiXxJ5cW6z8FVGyaXaOdV0d4w@mail.gmail.com>
Date: Wed, 23 Jul 2014 17:25:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D265DE8-7157-40C9-933F-DF229D26769F@gmail.com>
References: <CE9DACA8-F719-44E0-B085-7B615FE16C34@cisco.com> <20140723194438.EC4C71ADB9@ld9781.wdf.sap.corp> <CABkgnnVHu=n+LnbaKcLkmzK4KwiXxJ5cW6z8FVGyaXaOdV0d4w@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PIDnab3cpK17JkjGvzWrACnsYSI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-petithuguenin-avtcore-rfc5764-mux-fixes-00
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: Wed, 23 Jul 2014 21:25:21 -0000

On Jul 23, 2014, at 4:41 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 23 July 2014 12:44, Martin Rex <mrex@sap.com> 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.

Yoav