Re: [TLS] New Cached info draft

Martin Rex <mrex@sap.com> Wed, 31 March 2010 20:39 UTC

Return-Path: <mrex@sap.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 55B063A682C for <tls@core3.amsl.com>; Wed, 31 Mar 2010 13:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.646
X-Spam-Level:
X-Spam-Status: No, score=-8.646 tagged_above=-999 required=5 tests=[AWL=0.473, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 pOQa9RsGfT0d for <tls@core3.amsl.com>; Wed, 31 Mar 2010 13:39:49 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 2A9133A6405 for <tls@ietf.org>; Wed, 31 Mar 2010 13:39:49 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o2VKeGGk024573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 22:40:16 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003312040.o2VKeFpE007970@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Wed, 31 Mar 2010 22:40:15 +0200 (MEST)
In-Reply-To: <4BB3AD23.5040407@extendedsubset.com> from "Marsh Ray" at Mar 31, 10 03:14:27 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] New Cached info draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 31 Mar 2010 20:39:50 -0000

Marsh Ray wrote:
> 
> On 3/31/2010 2:47 PM, Martin Rex wrote:
> > Brian Smith wrote:
> >>
> >> Marsh Ray wrote:
> >>>
> >>> I think in this case it's saying there can be a maximum of 1024
> >>> entries in the list, each of which can take up to 9 bytes
> >>> (with a one byte length). So the receiver of this structure
> >>> is only obligated to store (or ignore) (2 + (1 + 8)*1024)
> >>> bytes of data.
> >>
> >> No, Mike is right and I was wrong; <1024> means "1024 bytes",
> >> not "1024 entries".
> > 
> > While Marsh explanation sounded quite reasonable to me,
> > the implementors have a technical advantage of being more
> > accustomed to the TLS spec syntax for defining a vector size:
> > 
> > http://tools.ietf.org/html/rfc5246#section-4.3
> 
> It says:
> >    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).
> 
> This requirement does not seem to allow a vector to be made up of
> variable-sized elements as in Stefan's suggestion.
> 
> So perhaps some other notation is needed for this class of structure?


Stefan's description looks _very_ similar to the definition of
TLS extensions in (Extended)ClientHello of rfc-5246:

http://tools.ietf.org/html/rfc5246#appendix-A.4.1

   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

so my interpretation would be that this "multiple-of" restriction applies
only to arrays of "scalar" types with a fixed size, but not to
composed types of variable size.

Anyway, reusing the syntax from the Extensions definition in the
TLS spec seems like the correct thing to do.


-Martin