Re: [TLS] RFC 5878 - why?

Trevor Perrin <trevp@trevp.net> Wed, 18 September 2013 00:37 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 87A8C11E8264 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 17:37:31 -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=[AWL=-0.000, 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 ltB89xubJf7i for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 17:37:24 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 85D5B11E8156 for <tls@ietf.org>; Tue, 17 Sep 2013 17:37:24 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id m15so5810742wgh.19 for <tls@ietf.org>; Tue, 17 Sep 2013 17:37:23 -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=Rmj38ha1w/Q+pA9PYVE2zsHP51KYiFiBchUiPsOHRCI=; b=W1726xw3XThQhZ1AmhmMy7E/ngG0818XzBtqQeaoSfp4TnRWm0kDolRyigYKDBozC/ wo/zgZu0+Eah/ZQJ9Yq00t750Y51tkyqUkc33FYJriOVcH9Z6scHfZJKtT9092gsGddD J7aholZ4pNS6m1SVbg9nIx7d8u6j78c8mbt+EZUmp4O1WfjR4HvpeYGZrFeHgnNlSPp8 WCJbdM1+oXuJFOaZkVlCHAJ00A4kZ6ZBHFjC//UpLZVryzfGf3hyGP8f/QmIJe6jnqIv wu3mptZwgXgvwvsim4dWxC92HaE8g08+uIDQ/lG8TNxAOFDpxXIxFtMJ5M2QeIHbwcS+ y4Lg==
X-Gm-Message-State: ALoCoQmM11RJ/1TNrpV+uBZJmRdzlH+bYwRXoLOZjHsd9gIDO7/FleYtOmZvNJdu+3MIZBl8zblh
MIME-Version: 1.0
X-Received: by 10.194.11.38 with SMTP id n6mr30092100wjb.25.1379464643572; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <159a1a51405047e185633d089b110bfa@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> <CAGZ8ZG38x-BEOncUqL3vO9_c15jQU=s-Bkh3cjLvWtdSb8MCCw@mail.gmail.com> <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Tue, 17 Sep 2013 17:37:23 -0700
Message-ID: <CAGZ8ZG2i8jefSMXvqrqseCY3_P3Rqp=WN2a_gRt7K__8Gq20Cg@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Marsh Ray <maray@microsoft.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 00:37:31 -0000

On Tue, Sep 17, 2013 at 2:27 PM, Marsh Ray <maray@microsoft.com> wrote:
>> From: Trevor Perrin [mailto:trevp@trevp.net]
>> Sent: Tuesday, September 17, 2013 8:32 AM
>>
>> 5878 itself is quite ugly, and riddled with errors and design flaws.
>> Which is why I'm bringing this up.
>
> Now, now, be nice.

Did you see the errata?

 * It's a weird extension structure, instead of having the standard
2-byte type / 2-byte length fields, like TLS Extensions and 4680
SupplementalDataEntry, each AuthorizationDataEntry has a (too-small)
1-byte type field, and no length field.

 * Without the length fields it's not generically parseable (Ben
suggests fixing that in the errata, but that breaks compatibility with
the 5878 URLandHash structure).

 * The structure definitions in section 3 are wrong.

 * The submitted errata also argue that the length field for
authz_data_list should be removed.  While I agree its redundant,
that's another compatibility-breaking change, so I'm not sure about
that.

So I'm asking:  Is there a legitimate reason for the community to
spend time fixing this RFC, implementing it in TLS libraries (it's not
currently present in any libraries, I believe), and adapting new
standards to use it?

If not, can we mark it as "obsoleted" or similar?

Projects like TACK, CT, and OpenSSL have wasted a lot of time
evaluating 5878 and doing trial implementations before backing away
from it.  I worry that people (like DTCP) [1] are going to keep making
that mistake, as on the surface this seems like the
"officially-condoned", IETF way to exchange new data through TLS.


> Alternatively, if you know something exploitable please drop it while it's hot.
>
>> 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...
>
> 254 authZ data formats ought to be enough for anyone. But if not, sure, we could indeed use 255 as a value to indicate a multi-byte value follows.

Don't we have some 65000+ unused TLS extensions?

If you really want a few hundred numbers for "Private Use" or
"Specification Required" extensions, why don't we just carve that out
of the existing TLS Extension space?


Trevor

[1] http://tools.ietf.org/html/draft-dthakore-tls-authz-04