Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 03 March 2016 16:43 UTC

Return-Path: <ilariliusvaara@welho.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 E21E91A8763 for <tls@ietfa.amsl.com>; Thu, 3 Mar 2016 08:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 o_MCmwru6Bji for <tls@ietfa.amsl.com>; Thu, 3 Mar 2016 08:43:17 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AC9291A8750 for <tls@ietf.org>; Thu, 3 Mar 2016 08:43:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 800853268; Thu, 3 Mar 2016 18:43:15 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id y4OwfpkbiDkD; Thu, 3 Mar 2016 18:43:15 +0200 (EET)
Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 40D7F27B; Thu, 3 Mar 2016 18:43:15 +0200 (EET)
Date: Thu, 3 Mar 2016 18:43:09 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20160303164309.GA13882@LK-Perkele-V2.elisa-laajakaista.fi>
References: <56A8904D.10307@ericsson.com> <CAOgPGoBU+h6cA9RDxBX2m1AR-3-GnC7OYcfDLTpDepX00g73dA@mail.gmail.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <CAOgPGoB669zcdqMYXd0yD4Tkqx7yuj6dc0y1byv3bw1ZN_qv6Q@mail.gmail.com> <56D76716.1090506@acm.org> <CABkgnnUxeQbVfaWuGwg=5qk-0Urky5uFA_2GxGkKYFKQu=AZfA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABkgnnUxeQbVfaWuGwg=5qk-0Urky5uFA_2GxGkKYFKQu=AZfA@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/mB6rc1NHKgn_Ru55AJl6EXxUptE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 Mar 2016 16:43:20 -0000

On Thu, Mar 03, 2016 at 09:48:00AM +1100, Martin Thomson wrote:
> 
> [3]  I actually hope that we can change DTLS 1.3 so that it won't mux
> properly.  That will have a size benefit that should outweigh the cost
> of having to rev 5764 for 1.3.

I thought about this a bit...

It occurs to me that a way to compress most headers to 2 bytes (from
present 5) is:

Unencrypted: 16 03 01 xx xx or 15 03 01 xx xx
Encrypted: 80|xx xx

Where xx xx is the length bytes.

The unencrypted headers need to be kept for backward compatiblity.

The ranges don't overlap, since the first xx can be at most 0x41
(which occurs for maximum 16640 byte encrypted record payload),
so the first byte would be 0x80-0xC1, which doesn't overlap with
0x15 and 0x16 (which are used for unencrypted packets).

That would interfere with muxing however (requring at least
changing how muxing is done, e.g. by inserting a marker byte
for DTLS packets).


-Ilari