Re: [TLS] RFC 5878 - why?

Trevor Perrin <trevp@trevp.net> Tue, 17 September 2013 07:12 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 6331411E8226 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 00:12:07 -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 XtzmnKQz0vbx for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 00:12:01 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9B21F8F4D for <tls@ietf.org>; Tue, 17 Sep 2013 00:12:00 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id f12so4552884wgh.26 for <tls@ietf.org>; Tue, 17 Sep 2013 00:12:00 -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 :content-transfer-encoding; bh=lOvFS4IM9uJkmzsTFIhH8XcypQ6/OYiFTtPcN8D4WaQ=; b=faaL1Srq6F0/4ZGGFw6WP6kWyAs0m34r4BH7mSh+keU5Q0tyMON8GKnULCCpOcGVDH 2z9wHLocNWBi558TtJ0spdsmCTNhdlXvDBkWcIykDqWuiCMxQ8Zl+O2Sc4cg6akvEzeV KMo+Bw+kii/l7QJlfW/zk1oPitG9ECl0VN8a1fifIm/RAOpBKE7k+9RCcR7LDr6FkS9Q ghayWwsJftce47aZbCcmMeULVfMGgHT5mSNA6/b/7kfNMteZRoaT+tpIvUDBJG7Po5ET 0lIAWkHm4u7xGKD9TbwaOkZ0RnJTpBD0fatf0lDmzEYOXJ+a1oyLqzDJVyerY+W1BN/v ISZw==
X-Gm-Message-State: ALoCoQk5/XofQ8wA/79kDXB5p081WBlfc3CSsgWnIA01UtbDMD7zF3IDYGO/71rTluNIGiTRrwSw
MIME-Version: 1.0
X-Received: by 10.194.10.193 with SMTP id k1mr95170wjb.50.1379401920152; Tue, 17 Sep 2013 00:12:00 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 00:12:00 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
References: <CAGZ8ZG3cNi3FSb879yumEt5etXWCoy1LOcxFAgNzrp9zeriJdA@mail.gmail.com> <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Tue, 17 Sep 2013 00:12:00 -0700
Message-ID: <CAGZ8ZG3R2-Egermz5Vefu18mD2KAvXOXcG++HJut_rLKapeH4Q@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Marsh Ray <maray@microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Tue, 17 Sep 2013 07:12:07 -0000

On Mon, Sep 16, 2013 at 11:53 PM, Marsh Ray <maray@microsoft.com> wrote:
>> Trevor Perrin
>> Sent: Monday, September 16, 2013 9:16 PM
>> Subject: [TLS] RFC 5878 - why?
>>
>> Hi,
>>
>> Does anyone know of a reason to use RFC 5878?  Extension data can already
>> be sent in TLS handshakes:
>>
>> Seems like a bunch of added parsing for nothing?  What is this for?
>
> One useful thing it does is acquires an extension code point from IANA as well as defines a few values for specific types of authZ data.

But those specific types (or any others) could just have been defined
as TLS Extensions.  (Does anyone actually use SAML in TLS??  or X.509
Authorization certs?).

Also, note 5878 only has an 8-bit space for "authZ types", which seems
*much worse* than just using 16-bit TLS extension numbers in terms of
number exhaustion or risk of collision.


> But probably the bigger reason is that some percentage of TLS servers in the wild will crash or (worse) hang when they receive a Client Hello with too much data. Nobody is really sure how much data is safe to send in the Client Hello, so getting preapproved with a small extension is safest.

OK, but see my first diagram:
 - The server can send whatever it wants as a ServerHello extension
 - The client can send whatever it wants in response as RFC 4680
SupplementalData

So that problem is easily avoided without 5878.

Still not seeing the point...


Trevor