Re: [TLS] RFC 5878 - why?

Trevor Perrin <trevp@trevp.net> Wed, 18 September 2013 05:52 UTC

Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB811E8122 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 22:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz4iEAtm2A66 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 22:52:35 -0700 (PDT)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 021D911E8116 for <tls@ietf.org>; Tue, 17 Sep 2013 22:52:34 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u57so5843889wes.23 for <tls@ietf.org>; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.194.21.131 with SMTP id v3mr292788wje.44.1379483553892; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <CE5E822F.14454%d.thakore@cablelabs.com>
References: <CAGZ8ZG2i8jefSMXvqrqseCY3_P3Rqp=WN2a_gRt7K__8Gq20Cg@mail.gmail.com> <CE5E822F.14454%d.thakore@cablelabs.com>
Date: Tue, 17 Sep 2013 22:52:33 -0700
Message-ID: <CAGZ8ZG2M2ejE1sdiSg=p=xsu41QpeXVRij9zio9059gtkB77PQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Darshak Thakore <d.thakore@cablelabs.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 18 Sep 2013 05:52:41 -0000

On Tue, Sep 17, 2013 at 10:04 PM, Darshak Thakore
<d.thakore@cablelabs.com> 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
AuthorizationDataEntry.

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

Trevor