Subject: [TLS] RFC 5878 - why?

From: Trevor Perrin <[email-masked]>
Date: Mon, 16 Sep 2013 21:16:24 -0700

Hi,

Does anyone know of a reason to use RFC 5878?  Extension data can
already be sent in TLS handshakes:

Client -> Server : ClientHello Extension
Client <- Server : ServerHello Extension
Client -> Server : SupplementalData (RFC 4680)

5878 just adds another extension structure inside existing ones:

Client -> Server : ClientHello Extension signalling AuthorizationData
Client <- Server : ServerHello Extension signalling AuthorizationData,
                            SupplementalData containing AuthorizationData
Client -> Server : SupplementalData containing AuthorizationData

Seems like a bunch of added parsing for nothing?  What is this for?

Trevor

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Sep 2013 06:53:36 +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:
> 

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

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Sep 2013 00:12:00 -0700

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

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

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Sep 2013 07:30:57 +0000

> From: Trevor Perrin [mailto:[email-masked]]
> 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.

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.

> (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! :-)

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 17 Sep 2013 07:33:58 +0000

>Still not seeing the point...

It does seem like a pretty clunky way to do a kitchen-sink extension.  OTOH
since it's marked as Experimental, does anyone care?

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Sep 2013 08:12:51 +0000

> 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 t…

s/WG/Authors/ - This was not a product of the TLS working group. It also has some interesting history, and was the cause for some quite heated debate on the IETF list:
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html

Yoav

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Sep 2013 15:00:50 +0200 (CEST)

Marsh Ray wrote:
> 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.

I hope that, rather than crashing, the most widespread behaviour among
servers will be to simply abort the handshake with a fatal Handshake
failure alert when the ClientHello handshake message exceeds some
reasonable size (maybe 16 KByte).  Ours does.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Sep 2013 15:08:30 +0200 (CEST)

> reasonable size (maybe 16 KByte).  Ours does.

Actually, another reason that comes to mind when looking at the
handshake message flowchart here:

  http://tools.ietf.org/html/rfc5878#page-4

taking into account the last sentence before that chart:

   Successful session resumption uses the same authorization information
   as the original session.

and compare it with the handshake message flowchart for the
abbreviated TLS handshake (aka session resume):

  http://tools.ietf.org/html/rfc2246#page-32

For a potentially large TLS extension that carries fairly static data,
you might not want to have to send it on every proposed TLS session resume.

-Martin

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Sep 2013 08:21:20 -0700

> you might not want to have to send it on every proposed TLS session resume.

Like I said to Marsh, see the flowchart in my first message.

It's trivial to exchange "authorization data" - or any sort of
extension data - in the ServerHello extension, and also in a 4680
SupplementalData message sent by the client after receiving
ServerHelloDone.

5878 is not needed to avoid sending large items in ClientHello.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Sep 2013 08:32:09 -0700

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

> 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

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Sep 2013 21:27:59 +0000

> Sent: Tuesday, September 17, 2013 8:32 AM
> 

Now, now, be nice.

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.

> Or, we could just ignore it and use TLS Extensions and 4680 directly.

We could. But at least now the RFC 5878 authors and implementers have their own little kitchen sink to experiment in.

> Does anyone care?  Has anyone written independent, interoperating

You must be new here ...  :-)

- Marsh

P.s. I'm glad you're here

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Sep 2013 17:37:23 -0700

>> Which is why I'm bringing this up.

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.

> 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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Sep 2013 03:55:04 +0000

> "officially-condoned", IETF way to exchange new data through TLS.

RFC 5878 is an experimental RFC. If you've looked at its history, it was approved by the IESG in 2006, and an IPR issue surfaced, so approval was withdrawn, and the draft lay dormant for 3 years. If during those three years anyone had come up with some other draft describing an authorization extension, I think that would have been approved instead. But nobody did. 

I took that to mean that there was very little interest in passing authorization information in the TLS handshake. So after three years, the IESG agreed to publish it anyway, and as the errata show, it received very little review.

In any case, it's an experimental RFC and if the DTCP want to send information (whether authorization-related or not) in an extension, they can use it or not use it as they see fit.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Sep 2013 21:25:07 -0700

On Tue, Sep 17, 2013 at 8:55 PM, Yoav Nir <[email-masked]> wrote:
>
> RFC 5878 is an experimental RFC. If you've looked at its history, it was approved by the IESG in 2006, and an IPR issue surfaced, so approval was withdrawn, and the draft lay dormant for 3 years. If during those three years anyone had come up with some other draft describing an authorization extension, I think that would have been approved instead.

Why is there need of an "authorization extension"?

TLS already has well-designed, standards-track ways of passing
extension data back and forth:

Why is that not sufficient?

Trevor

---

From: Darshak Thakore <[email-masked]>
Date: Wed, 18 Sep 2013 05:04:19 +0000

I'm trying to understand if the primary issue being pointed out here is
about the errata in RFC5878 or the extension model that RFC5878 provides.
This thread started off with the primary question being what does RFC5878
provide and seems to be turning into a bashing of how bad it is. While i
agree that RFC5878 needs to be "fixed" in order to be usable, if we go
back to the original question of:

why this:

instead of this:

then:

1. You seem to be assuming that data is always flowing from the Client to
the Server and that anything that a server may want to send can always be
carried in the extension. That's not the only case. While it is possible
(and in most scenarios sufficient) to carry data in the extension itself,
certain extensions may require that actual data be passed in a specific
MessageType (based on certain aspects of the handshake being
accomplished). In such situations, the extension and the data in the
extension serves as triggers/extension code points to indicate what type
of data is to be expected in the subsequent messages. In order to achieve
that, if you do not define an extension code point, then your
extensionType registry starts exploding (with corner case extensions
littered around). While it is possible that way, IMHO, having a separate
code point and having a separate registry that provides a
categorization/registration of specific data types seems cleaner and
provides better management.

RFC4681 also does the same thing. It defines an extension and establishes
a registry to allow registering new UserMappings.

Going back to the problems of RFC5878 itself, the lack of length field
definitely needs to be fixed but the AuthorizationDataEntry being 1 byte
(while weird as you put it) is not really an issue.

Also as Yoav pointed out, due to lack of interest or whatever historic
reasons, there wasn't any other alternative/interest so RFC5878 was
published. When I actually had the need to pass DTCP data as authorization
data, RFC5878 provided the closest option (for better or for worse).

So my (very biased :) counter question is if RFC5878 is fixable, why not
fix it and leverage the registry already defined. If it is obsoleted,
wouldn't an alternative still be needed?

Darshak

On 9/17/13 6:37 PM, "Trevor Perrin" <[email-masked]> wrote:

>>>suppose we
>> 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.
>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tls

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 17 Sep 2013 22:52:33 -0700

> about the errata in RFC5878 or the extension model that RFC5878 provides.

My primary question is what value (if any) 5878 provides.

> accomplished).

I don't see your point.

A TLS ServerHello Extension can carry ~64 KB, same as the 5878
AuthorizationDataEntry.

If that's not sufficient and you need to modify the TLS Handshake
somehow based on signalling in the ClientHello and ServerHello, I
still don't see how 5878 makes any difference.

 In such situations, the extension and the data in the
> littered around).

You're worried about excess consumption of code points?  Switching
from a 16-bit space to an 8-bit space *exacerbates* that problem, it
doesn't solve it.

> wouldn't an alternative still be needed?

The alternative is to pass data via the standards-track mechanisms of
Hello Extensions and RFC 4680

Trevor

---

From: [email-masked] (Martin Rex)
Date: Wed, 18 Sep 2013 19:51:18 +0200 (CEST)

Trevor Perrin wrote:
>
> Yoav Nir <[email-masked]> wrote:
> >
> > RFC 5878 is an experimental RFC. If you've looked at its history,
> > it was approved by the IESG in 2006, and an IPR issue surfaced,
> > so approval was withdrawn, and the draft lay dormant for 3 years.
> > If during those three years anyone had come up with some other
> > draft describing an authorization extension, I think that would
> > have been approved instead.
> 

The rfc5878 seemed to have a use case, might have documented what they
had implemented, and just wanted to get this published.

Quoting from the Title page of rfc5878:

  http://tools.ietf.org/html/rfc5878

   Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

If a document is published by the IETF, "Experimental" is the biggest
warning sign that we have to caution consumers, except for refusing
to publish.

housley-tls-authz-extns specifically had an IPR issue, which by itself
caused active _disinterest_ in the document, I assume:

  http://www.ietf.org/mail-archive/web/tls/current/msg01523.html

Btw. there was an announcement of an implementation of both
rfc4680 and housley-tls-authz-extns in GnuTLS in 2007:
  http://www.ietf.org/mail-archive/web/tls/current/msg01518.html

> Why is that not sufficient?

It would be sufficient.

If the stuff described in rfc5878 would have been proposed after
rfc4680 existed, it probably would have used it.  But the history
of both documents suggests that housley-tls-authz-00 is actually older
than the initial draft for rfc4680:

  https://datatracker.ietf.org/doc/rfc5878/history/
  https://datatracker.ietf.org/doc/rfc4680/history/

If you combine this kind of history with a combination of
"lack of interest" and "active disinterest because of IPR issue",
then rfc5878@Experimental is what might happen.  I naively assume that
tls-authz-extns would have died silently if Russ had not been a coauthor.

If you want to create an alternative to rfc5878 that makes proper use
of rfc4680 -- go ahead.  But such an alternative might subject to the same
IPR claims as rfc5878, so it might be the same hard sell as tls-authz-extns.

-Martin

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 18 Sep 2013 11:37:00 -0700

> warning sign that we have to caution consumers, except for refusing

The "Experimental" marking wasn't enough to prevent people like CT,
TACK, DTCP, and OpenSSL wasting a lot of time evaluating this and
trying to use it in the last couple of years.

A bunch of code was submitted into OpenSSL for this, then had to be
ripped out, CT specs were written for it, then rewritten,  and DTCP is
still grappling with this (see Darshak's email in this thread).

If 5878 is truly redundant with RFC 5246 and 4680 then I think this
group should consider marking it "obsoleted" to steer people away from
these mistakes.

>   http://www.ietf.org/mail-archive/web/tls/current/msg01523.html

Sure, I assume that's why no-one reviewed it carefully.

>   http://www.ietf.org/mail-archive/web/tls/current/msg01518.html

GnuTLS support of authz-extns was removed several months later, and
the implementor opposed publication as an RFC:

http://www.ietf.org/mail-archive/web/ietf/current/msg48545.html

> rfc4680 existed, it probably would have used it.

5878 *DOES* use 4680, that's why it's so pointless.  It's a (bad)
extension mechanism nested inside of better ones.

> IPR claims as rfc5878, so it might be the same hard sell as tls-authz-extns.

There's no need for an alternative.

TLS already has well-designed, standards-track extension mechanisms,
in the form of Hello Extensions and 4680 SupplementalData.

Trevor

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 24 Sep 2013 12:39:01 +0200

> currently present in any libraries, I believe), and adapting new

No.

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

+1

/Simon

---

From: Russ Housley <[email-masked]>
Date: Tue, 24 Sep 2013 10:04:49 -0400

> Seems like a bunch of added parsing for nothing?  What is this for?

As far as I know, my co-author is the only one that implemented the specification.  It worked.  However, he has changed jobs, and I do not think he is working on it any more.

Over the years, we have answered several queries from other people that were looking for an authorization mechanism.  I do not know if they used this approach or not.

As to the complexity, you should take a look at the TLS mail list discussion about TLS User Mapping Extension, which became RFC 4681.  Both user mapping and authorization were forced into the SupplementalData structure.  Both had more straightforward approaches in the beginning.

Russ