Re: [TLS] Clarification on vectors required

Marsh Ray <marsh@extendedsubset.com> Thu, 01 April 2010 14:25 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 725C13A6959 for <tls@core3.amsl.com>; Thu, 1 Apr 2010 07:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.573
X-Spam-Level:
X-Spam-Status: No, score=0.573 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_45=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhbNWZGacAtn for <tls@core3.amsl.com>; Thu, 1 Apr 2010 07:25:20 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 96E523A6829 for <tls@ietf.org>; Thu, 1 Apr 2010 07:25:19 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NxLL7-000JpU-V5; Thu, 01 Apr 2010 14:25:47 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2F43260B6; Thu, 1 Apr 2010 14:25:43 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/blEHcRinvdFLOru8KB3IeGPcnFeNZCkk=
Message-ID: <4BB4ACEA.5050109@extendedsubset.com>
Date: Thu, 01 Apr 2010 09:25:46 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: neil.young@freenet.de
References: <4BB49475.5060701@Freenet.de> <4BB4A65B.4000403@freenet.de>
In-Reply-To: <4BB4A65B.4000403@freenet.de>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Clarification on vectors required
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Thu, 01 Apr 2010 14:25:25 -0000

On 4/1/2010 8:57 AM, neil.young wrote:
>> Given the following declaration:
>> 
>> opaque             config_data<2^24-1>;

> Is this understanding correct:
> 
> 1) The declaration is slightly incorrect, because the "floor" element
> is missing. I tend to treat it to be 0

Looks like the lower bound is specified everywhere else.

> 2) The number of bytes expressing the length of the vector is 3,
> large enough to count for 2**24-1 bytes

Sounds right to me.

> 3) If e.g. the size of the vector's data is 2 bytes, do I really have
> to add a pad byte in order to meet the "even multiple" demand?

No. The length field does not need to be the same as the size of an
element and it is not included in the "even multiple" requrirement.

> Is this correct? 00 00 02 47 11 0
> 
> Or this? 00 00 02 47 11

Either is correct, you defined it as 'opaque'. The opaque type is for
"single byte entities containing uninterpreted data".

It's only when vectors contain a defined type that this rule applies:
"The length of an encoded vector must be an even multiple of the length
of a single element (for example, a 17 byte vector of uint16 would be
illegal)."

Obviously, if the defined type is itself one byte in size then the even
multiple requirement is always met.

The example in the RFC:
> opaque Datum[3];      /* three uninterpreted bytes */
> Datum Data[9];   /* 3 consecutive 3 byte vectors */

The 9 must be a multiple of 3.

The size of the length field does not need to be the same as the size of
an element of the vector.

There appears to be an unstated exception to the even multiple
requirement for element types that may themselves be of variable length.

This is just my interpretation, however. :-)

- Marsh