Re: [TLS] RFC 5878 - why?

Trevor Perrin <> Wed, 18 September 2013 05:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 13BB811E8122 for <>; Tue, 17 Sep 2013 22:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pz4iEAtm2A66 for <>; Tue, 17 Sep 2013 22:52:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 021D911E8116 for <>; Tue, 17 Sep 2013 22:52:34 -0700 (PDT)
Received: by with SMTP id u57so5843889wes.23 for <>; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qLe8ehki7/FfcZMxVnMIIid7umKqreQHsmyZM+nAl04=; b=ediNWcdSNHaMEYUM36i18j2w5BJoBGQ3zVh8Wjl6MriV0lWYGVClTMpMjUALlljFgV glcRlOu7zGB6uqw1DDF5L4K7hzADDCUq4R9ALs/ooruIf76onfBNcz6R+jj4/qHsiqoZ sw/hwylNGV22BdNReRYV/n7GDZvlmUQUjWOXkYn5PY4AlC82XyqiGHSQlnlRURy8Eulg tqvclaeTXntobruqC4DOlf0A/NoCkPSjJFyogdir/5IjTrLbLYrD8pj9re007q7Y0U9z IYcT2L4A1iMFJVESEHnARPyPWRskj3hPWXiPrQ2QSEo57a8iEO2A2QEH5sImq5ShnsQ3 TJFw==
X-Gm-Message-State: ALoCoQnDxI9QgCC9/izzE42St8X9n4RBgLxfX24I+MROIkth8xk+RA7yycBrSAI8TunZ0mZQL0+2
MIME-Version: 1.0
X-Received: by with SMTP id v3mr292788wje.44.1379483553892; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
Received: by with HTTP; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Tue, 17 Sep 2013 22:52:33 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Darshak Thakore <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [TLS] RFC 5878 - why?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Sep 2013 05:52:41 -0000

On Tue, Sep 17, 2013 at 10:04 PM, Darshak Thakore
<> wrote:
> I'm trying to understand if the primary issue being pointed out here is
> about the errata in RFC5878 or the extension model that RFC5878 provides.

My primary question is what value (if any) 5878 provides.

> 1. You seem to be assuming that data is always flowing from the Client to
> the Server and that anything that a server may want to send can always be
> carried in the extension. That's not the only case. While it is possible
> (and in most scenarios sufficient) to carry data in the extension itself,
> certain extensions may require that actual data be passed in a specific
> MessageType (based on certain aspects of the handshake being
> accomplished).

I don't see your point.

A TLS ServerHello Extension can carry ~64 KB, same as the 5878

If that's not sufficient and you need to modify the TLS Handshake
somehow based on signalling in the ClientHello and ServerHello, I
still don't see how 5878 makes any difference.

 In such situations, the extension and the data in the
> extension serves as triggers/extension code points to indicate what type
> of data is to be expected in the subsequent messages. In order to achieve
> that, if you do not define an extension code point, then your
> extensionType registry starts exploding (with corner case extensions
> littered around).

You're worried about excess consumption of code points?  Switching
from a 16-bit space to an 8-bit space *exacerbates* that problem, it
doesn't solve it.

> So my (very biased :) counter question is if RFC5878 is fixable, why not
> fix it and leverage the registry already defined. If it is obsoleted,
> wouldn't an alternative still be needed?

The alternative is to pass data via the standards-track mechanisms of
Hello Extensions and RFC 4680