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

Dave Garrett <> Mon, 08 February 2016 06:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 332F01A92BC; Sun, 7 Feb 2016 22:18:05 -0800 (PST)
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_84=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id a10kWDWn2_xo; Sun, 7 Feb 2016 22:18:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 431D41A92BA; Sun, 7 Feb 2016 22:18:00 -0800 (PST)
Received: by with SMTP id z7so83246361yka.3; Sun, 07 Feb 2016 22:18:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=4AvcBTULt73lUC/NFqzjYOUBBgtiLHRZMQtgqH8v72o=; b=EwH8ix9AC9qJn0QwDlE5Y78vvOH2CsHEwzgrTFMP0JIlmK80SIJwWRH8jU/vskbszv VnaUBL8ulaIovxdkmTdB9hCCrhcT4u7b3pM1od4Ns6SIhmsrpPaItG5vnenincUqAL4y w27Gbk6Pj7WhikIVsUm0byfwp+or6vr/qP3WGqjkV7eahpMjCDFIl0A1gnG2uHD9hAJJ X7mXRvkGmUJgMrcysgoZjGlj+cioKZLirW7NC4TcF84kJe5xczzHmR0njseB9f7KlyS2 VQzBm0D/iXnCzyKk7INHY7KPQvcdPbP61F9x5O+C369OObyXAjMglaSL+tHc2aAf9WDW 5HJQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=4AvcBTULt73lUC/NFqzjYOUBBgtiLHRZMQtgqH8v72o=; b=cGqDazvy/f1+RtX7j0BL1YuI0zACPTSb+FOGAvLD9ha6iIUd9q2v5oKkWmT710sAcT f66K0oOFSBBb/vjAgaMC4nnxuTDNjW4VLdIWWSvwlzBfNqJ8okJzbYIJCq3O8l4yz3ar 24rC7mA/938MwEf98fIjVmZMG3jyKcHnLZSWevGZQiYXg3D6PwH/qBao7cf2zdWw2O5s EY+zknoRrv2FK/zzBIL2u/6jjrGxbhA181fLVNBvSqPaqO3SoZkJi7Ocyvb4wJb/4cMH jllF7Q8d5nEjd6tysLTwgqwwMYCGgtYJnOcve+5ZFjLBhCmQ9eb/whrTlnJv8/8joKhV lRAg==
X-Gm-Message-State: AG10YORWNTZNAIhIDg75PFdby9+QQDDezmkrXXMdFWOC+Yf7ez5A5lS3wnjyRYR3KHYByw==
X-Received: by with SMTP id 5mr13406796ybv.22.1454912279604; Sun, 07 Feb 2016 22:17:59 -0800 (PST)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id a7sm20035824ywf.55.2016. (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 07 Feb 2016 22:17:59 -0800 (PST)
From: Dave Garrett <>
Date: Mon, 08 Feb 2016 01:17:57 -0500
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
X-Mailman-Approved-At: Mon, 08 Feb 2016 01:59:08 -0800
Cc: Joseph Salowey <>,
Subject: Re: [AVTCORE] [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Feb 2016 06:18:05 -0000

Permanently gobbling up the majority of the codespace feels like excessive force here. For TLS 1.3, the first byte will always be one of alert(21), handshake(22), or application_data(23), even for custom types. The stated type for TLSCiphertext has been frozen to application_data(23) with the actual type for the payload now in the encrypted fragment. (this is of course assuming we don't eventually drop the frozen type & version here, which now sounds unlikely if we're having to deal with design flaws like this) Even handshake records after the hellos will have an opaque_type of application_data(23), with the encrypted fragment.type containing the actual handshake(22) designation. All TLS 1.3+ packets will be detected with the RFC 5764 Section 5.1.2 algorithm even if new types are allocated in the proposed reserved ranges.

Locking down the <1.2 registry seems fine, however 1.3+ should be able to do whatever it needs as its encrypted type is not going to get accidentally read & misinterpreted by anything.


On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote:
> This document is relevant to the TLS working because it reserves a large
> portion of the TLS content type space.  The values 0-19 and 64-255 cannot
> be used without checking for conflicts with SRTP-DTLS's wacky
> demultiplexing scheme.   In TLS 1.3 we will move more encrypted content
> types which should limit the impact this unfortunate design on TLS
> evolution, but the working group should be aware of this.
> On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund
> <> wrote:
> > AVTCORE and TLS,
> >
> > TLS WG, you are included in this WG last call, as this document affects
> > the TLS ContentType IANA registry.
> >
> > This email starts a two week WG last call, that ends on the 10th of
> > February. The intended status of this document is standards track (Proposed
> > Standard).
> >
> > The document can be retrieved here:
> >