IETF Logo Mail Archive

Re: [TLS] RFC 5878 - why?

Marsh Ray <maray@microsoft.com> Tue, 17 September 2013 06:53 UTC

Return-Path: <maray@microsoft.com>
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 C33D911E81C3 for <tls@ietfa.amsl.com>; Mon, 16 Sep 2013 23:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 1ZxtAv0gwftB for <tls@ietfa.amsl.com>; Mon, 16 Sep 2013 23:53:39 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id DFAF911E822C for <tls@ietf.org>; Mon, 16 Sep 2013 23:53:38 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 17 Sep 2013 06:53:36 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Tue, 17 Sep 2013 06:53:36 +0000
From: Marsh Ray <maray@microsoft.com>
To: Trevor Perrin <trevp@trevp.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y6IKGSQTOxB0uEDKlWZcM0bZnJfDCw
Date: Tue, 17 Sep 2013 06:53:36 +0000
Message-ID: <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
References: <CAGZ8ZG3cNi3FSb879yumEt5etXWCoy1LOcxFAgNzrp9zeriJdA@mail.gmail.com>
In-Reply-To: <CAGZ8ZG3cNi3FSb879yumEt5etXWCoy1LOcxFAgNzrp9zeriJdA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 0972DEC1D9
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(377454003)(199002)(51704005)(80976001)(81542001)(81342001)(83072001)(81816001)(81686001)(74876001)(74316001)(79102001)(83322001)(76482001)(56776001)(76796001)(74502001)(56816003)(33646001)(51856001)(80022001)(47446002)(74662001)(46102001)(77982001)(59766001)(76576001)(54316002)(76786001)(31966008)(77096001)(69226001)(47736001)(53806001)(54356001)(4396001)(47976001)(49866001)(74706001)(63696002)(65816001)(50986001)(74366001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB167; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
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 06:53:47 -0000

> 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 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.

- Marsh

v2.23.0 | Report a Bug | By Email