Re: [TLS] RFC 5878 - why?

Trevor Perrin <> Wed, 18 September 2013 00:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87A8C11E8264 for <>; Tue, 17 Sep 2013 17:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.977
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ltB89xubJf7i for <>; Tue, 17 Sep 2013 17:37:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 85D5B11E8156 for <>; Tue, 17 Sep 2013 17:37:24 -0700 (PDT)
Received: by with SMTP id m15so5810742wgh.19 for <>; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id n6mr30092100wjb.25.1379464643572; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
Received: by with HTTP; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Tue, 17 Sep 2013 17:37:23 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Marsh Ray <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [TLS] RFC 5878 - why?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Sep 2013 00:37:31 -0000

On Tue, Sep 17, 2013 at 2:27 PM, Marsh Ray <> wrote:
>> From: Trevor Perrin []
>> 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

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?