IETF Logo Mail Archive

Re: [TLS] RFC 5878 - why?

Trevor Perrin <trevp@trevp.net> Tue, 17 September 2013 15:32 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 372DB11E80F7 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:32:23 -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 CcDUJTvakfl1 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 08:32:18 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 466F121F9AED for <tls@ietf.org>; Tue, 17 Sep 2013 08:32:10 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w62so5368852wes.29 for <tls@ietf.org>; Tue, 17 Sep 2013 08:32:09 -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=k5GXAQTEbcF+y1hkvo3n+xCd1iprAz09yrtsJ/gn72Y=; b=X1ePa2exx7/vU2OI4BSMwrRTZXBjn0r4s2DOJ9DQA17ayYWOUeYAZLs3YEWht1ywqk 6fXmUocOlvN+8/G8M7VTRqLfvQtBrhQFpJFZmcW2LX7A7syjTRO2Q2QnCZwEyd+TmPkM 2gYlQHbKWBvsZ+owUPW6GV8bMy+NRwgZ5NUMVhkwkRbZf1TeD3815W8svF2zODfKrkFq LoaK0MAii8mXFwyXmxYzumSQsrss0t2ue57wC7miswd8AbkA27VBxIGsOSuhG+wlFpMK C8/GTQc/W6nE2b6L3bl1sD+vOimqMaWXFyayow/psxkssq2mXZYk8IVku0E/GBUPgtzu kuCw==
X-Gm-Message-State: ALoCoQlj/7XimwGBUmrPFovNKYYFPIwRHP1lhKAcsG7D9XCNVobL/yLODLFGheU6SjvAqzj+c0XM
MIME-Version: 1.0
X-Received: by 10.180.205.236 with SMTP id lj12mr3077877wic.22.1379431929392; Tue, 17 Sep 2013 08:32:09 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 08:32:09 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
References: <CAGZ8ZG3cNi3FSb879yumEt5etXWCoy1LOcxFAgNzrp9zeriJdA@mail.gmail.com> <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com> <CAGZ8ZG3R2-Egermz5Vefu18mD2KAvXOXcG++HJut_rLKapeH4Q@mail.gmail.com> <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Tue, 17 Sep 2013 08:32:09 -0700
Message-ID: <CAGZ8ZG38x-BEOncUqL3vO9_c15jQU=s-Bkh3cjLvWtdSb8MCCw@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 15:32:23 -0000

On Tue, Sep 17, 2013 at 12:30 AM, Marsh Ray <maray@microsoft.com> wrote:
>> From: Trevor Perrin [mailto:trevp@trevp.net]
>> Sent: Tuesday, September 17, 2013 12:12 AM
>> Subject: Re: [TLS] RFC 5878 - why?
>>
>> But those specific types (or any others) could just have been defined as TLS
>> Extensions.
>> 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.
>
> The WG must have felt that it was worth establishing a separate IANA registry for this specific purpose rather than piling them into the extension registry. An entire protocol could be defined in terms of exchanging sets of (ID, optional scalar value) pairs, but TLS tends to like structures that are nested a little deeper according to their semantics.
>
> I agree, a single octet seems stingy. But if it runs out the code space can be extended with only minor ugly.

5878 itself is quite ugly, and riddled with errors and design flaws.
Which is why I'm bringing this up.

http://www.rfc-editor.org/errata_search.php?rfc=5878

I don't know how you could "extend" it to a larger code space.  I
suppose we could nest another extension structure *inside* the 5878
structure, to see how many parsing layers we can bury extensions
inside...

Or, we could just ignore it and use TLS Extensions and 4680 directly.
Why not that?


>> (Does anyone actually use SAML in TLS??  or X.509 Authorization certs?).
>
> Well, it'd be a lot harder without an interoperable spec for it! :-)

Does anyone care?  Has anyone written independent, interoperating
versions of these?


Trevor

v2.23.0 | Report a Bug | By Email