Subject: [TLS] SPDY / NPN

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Apr 2012 13:00:20 -0700

A lot of people are pushing Google's SPDY protocol to improve web performance;
however, it seems to rely on the Next Protocol Negotiation (NPN) extension,
which does not appear to have been officially published as an RFC (the -02
draft expired in October 2011).

RFC 5246 explains that all TLS extensions have to obtain IETF Consensus to be
used on the Internet:

    This document also uses a registry originally created in [RFC4366].
    IANA has updated it to reference this document.  The registry and its
    allocation policy (unchanged from [RFC4366]) is listed below:

    -  TLS ExtensionType Registry: Future values are allocated via IETF
       Consensus [RFC2434].  [...]

NPN also adds a new handshake message to the TLS protocol, completely bypassing
the required Standards Action to do so:

    -  TLS HandshakeType Registry: Future values are allocated via
       Standards Action [RFC2434].

Speeding up the web is certainly not evil, but a large player like Google
shouldn't be setting such a bad precedent w.r.t. the IETF process.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Apr 2012 22:51:31 +0200

> draft expired in October 2011).

I'd also note that the text in the draft isn't sufficient to implement
the protocol described. There are no numbers assigned by IANA and
fields like padding are not even defined.

> NPN also adds a new handshake message to the TLS protocol, completely
> bypassing the required Standards Action to do so:

Also there is no rationale on why a new handshake message is needed.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Tue, 17 Apr 2012 23:20:40 -0500

> shouldn't be setting such a bad precedent w.r.t. the IETF process.

I suspect they'd hardly be the first.  In fact, it's happened in the
context of Kerberos, where we've had some number camping happen.

A few things worth pointing out:

 - There's no IETF standards compliance police.  This isn't to
   say "go ahead and do what you like", rather, that the golden
   rule applies, and making nice matters, but we're also flexible,
   and if there's no other way to achieve something than by
   bending the rules, well, we don't have a police force to make
   sure you don't, so it does happen.  I'm describing reality here.

   We can minimize camping by having liberal registration rules
   and protocols that allow for liberal registration rules.  E.g., by
   not creating scarcity artificially; just say no to 8- and 16-bit
   fields!

 - The IETF is a volunteer organization, and it's also
   a sort of gatekeeping organization.  If participants don't act in
   timely ways then they can't gatekeep effectively either.

 - I can't fault participants for working around the IETF in
   some cases.  In this particular case I think the facts on the
   ground require some experimenting with real world
   deployment in order to gain the necessary experience.
   Specifically it's very hard to tell what will and what won't
   work as far TLS extensions go without actually trying to
   deploy them.  For a good example see the post-mortem
   on False Start.  Would it have been possible to obtain the
   necessary experience with TLS concentrators to know
   whether False Start was feasible *before* progressing
   the specification to the Standards Track?  Almost
   certainly not.  Would it have been possible to publish on
   the Experimental track first, then promoted to the Standards
   Track if it proved workable?  Not if a registration were
   needed that required Standards Action!  (Sure, the allocation
   could have been done separately from placing the extension
   on the Experimental track, but that means more time...)

 - TLS is extra special.  It goes back a long time, it's got a
   colorful history.  TLS (SSL!) specs lacked sufficient
   detail and review early on.  TLS has been deployed in ways
   that leave the end-to-end model in tatters, specifically: with
   proxies on both ends, and potentially with more than one
   proxy on the client side.  This makes interop testing harder
   than for most other protocols.

   Extending TLS is extra hard.  Harder than TCP.

 - I think one lesson is that the most important protocols we
   have need detailed, sufficient specifications, and we need
   regular interop testing and implementors who are willing to
   fix their implementations.  The latter can can be impossible
   to get in some cases (e.g., in the False Start case, where
   one implementor no longer has the staff on hand to fix a
   specific problem).  The former can be addressed with
   review, more process, more timely updates.  But the latter?
   No clue how to address the latter except by having had
   sufficiently detailed specs and enough interop testing from
   the get-go.

Nico
--

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 17 Apr 2012 23:38:40 -0700

I discovered the lack of specs because I went looking for information
about how to implement SPDY.  At this point there is wide deployment,
so we can't do much beyond rubber-stamping what implementations are
actually doing[*].  But having the existing behavior documented is very
important to make sure implementations are interoperable, as you know.

Sure I can sympathize with the need for Google to have experimented
and chosen some private values, but now that they're pushing for wider
adoption, it is their obligation to get those IANA assignments.

Mike

* which is a shame since there were valid objections to the way NPN
was designed, and it could have been improved with a little effort....

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Apr 2012 06:27:57 -0500

On 04/18/2012 01:38 AM, Michael D'Errico wrote:
> actually doing[*]. But having the existing behavior documented is
> very important to make sure implementations are interoperable, as you
> know.
>
> and chosen some private values, but now that they're pushing for
> wider adoption, it is their obligation to get those IANA
> assignments.

May 14, 2011
http://tools.ietf.org/id/draft-agl-tls-nextproto-00.txt
> 5.  IANA Considerations
>
> This document requires IANA to update its registry of TLS extensions
>  to assign an entry, referred herein as "next_protocol".
>
> This document also requires IANA to update its registry of TLS
> handshake types to assign an entry, referred herein as
> "next_protocol_ann".

July 2011
https://technotes.googlecode.com/git/nextprotoneg.html
> Implementations
>
> NPN has been implemented in NSS (patch), TLSLite (patch) and OpenSSL
> (included in CVS, patch against 1.0.0d).
>
> A reference implementation server is running on port 443 of
> www.google.com. On the client side, the Chrome web browser enables
> NPN by default. Magic values
>
> For easy reference, this note uses the following magic numbers:
>
> Next protocol negotiation extension number	13172
>
> NextProtocol handshake message number	67

October 3, 2011
https://bugzilla.mozilla.org/show_bug.cgi?id=547312#c9
> NP was an attempt by Paul Hoffman to make NPN more IETF friendly. I
> don't believe that it has gone anywhere at all. As far as I know,
> there are no implementations of it.
>
> If the IETF were to standardise an acceptable variant of NPN we
> would look to transition over to it. That seems extremely unlikely at
> this point.

It reads to me like they were trying to do the right thing and the 
IETF/IANA process failed them.

We had this problem with the RI extension too. As a practical matter, 
developers needed to start interop testing long before the ID was in 
last call status.

It doesn't seem like a good idea to withhold numbers until last call. 
Those with a credible prospect of deploying and documenting a TLS 
extension ought to be able to reserve a number from the IANA for 
development and testing (and possible eventual adoption).

Withholding numbers doesn't actually seem to dissuade anyone from 
developing extensions. It simply results in numbers being de facto 
allocated in an uncoordinated fashion:

 From 
http://hg.mozilla.org/mozilla-central/raw-file/c55ce76c8dac/security/nss/lib/ssl/sslt.h
> typedef enum {
>     ssl_server_name_xtn              = 0,
> #ifdef NSS_ENABLE_ECC
>     ssl_elliptic_curves_xtn          = 10,
>     ssl_ec_point_formats_xtn         = 11,
> #endif
>     ssl_session_ticket_xtn           = 35,
>     ssl_next_proto_nego_xtn          = 13172,
>     ssl_renegotiation_info_xtn       = 0xff01	/* experimental number*/
> } SSLExtensionType;

- Marsh

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 Apr 2012 17:30:18 -0500

On Thu, Apr 19, 2012 at 6:27 AM, Marsh Ray <[email-masked]> wrote:
> It reads to me like they were trying to do the right thing and the IETF/IANA
> process failed them.

Not IANA.  The IETF failed them.

> developers needed to start interop testing long before the ID was in last
> call status.

This has happened quite a bit in other areas too (e.g., the IKEv2
NAT-T extensions, IIIRC).

Part of the problem is that during development the protocol is still
fluid and you don't want code to get deployed that later fails to
interop when the final protocol ends up differing from an earlier
version.

For non-scarce namespaces the solution is to just make allocations
liberally.  And for scarce ones?  I think we could use a standard
policy that requires, say, just WG chair and AD approval -- something
less that IESG Approval, more than FCFS, something akin to Expert
Review but requiring wider consensus yet being light-weight.  The
problem is that we can't require WG consensus or WG chair approval for
allocations because WGs are not stable -- we'd need a method for
updating which WG's chairs (if any applicable WG remains) need to
approve.  Ditto ADs, as it's possible to have the IESG re-organized.
But IESG Approval is a bit heavy-duty, I think (maybe I'm wrong about
that).

> Withholding numbers doesn't actually seem to dissuade anyone from developing
> extensions. It simply results in numbers being de facto allocated in an
> uncoordinated fashion:

Bingo.  But I don't think this is just a matter of the IETF being too
conservative in selecting allocation policies for registries.  That's
only part of it.  The other part is that we need an allocation policy
that is lightweight yet faster/simpler than Expert Review and also
requiring approval by an authority that can confirm the existence of
consensus for the allocation.  The bodies that would provide that
confirmation are ephemeral.

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2012 16:14:38 -0700

On Thu, Apr 19, 2012 at 4:27 AM, Marsh Ray <[email-masked]> wrote:
> It doesn't seem like a good idea to withhold numbers until last call. Those
> with a credible prospect of deploying and documenting a TLS extension ought
> to be able to reserve a number from the IANA for development and testing
> (and possible eventual adoption).

I don't see what "last call" has to do with it. This document has no formal
IETF status of any kind. I don't have a problem with pre-allocating numbers
for WG drafts, but that is not in fact the case here.

Note that one of the code points being used here is a "handshake_type",
which is allocated out of a 8-bit space. There are good reasons not to
have this space FCFS.

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Thu, 19 Apr 2012 09:32:04 -0500

On 04/19/2012 06:14 PM, Eric Rescorla wrote:
> On Thu, Apr 19, 2012 at 4:27 AM, Marsh Ray<[email-masked]>  wrote:
> I don't see what "last call" has to do with it.

My understanding from the RFC 5746 process was that 'In Last Call' 
status was the usual requirement to get an assignment. I think I got 
that impression from someone who was not particularly involved in [TLS] 
though.

> This document has no formal

I'd say that there's no set-in-stone policy against numbers for 
work-in-progress drafts is good news.

I don't know what exactly happened to make them believe that pursuing an 
RFC for False Start was a lost cause.

> which is allocated out of a 8-bit space. There are good reasons not to

Certainly these things need to be managed carefully.

However, in the 2.5 years or so I've been following [TLS] I think I've 
seen maybe 2 or 3 proposals that involved a new handshake record type. 
If by some strange (i.e., poorly coordinated) circumstances we ended up 
running low on free code points, we could easily assign one to indicate 
the presence of additional field at the beginning of the handshake data.

As it stands today a large percentage of web browsers will be using TLS 
extension type 13172 and handshake record type 67 for a specific 
purpose. Somebody ought to write this down somewhere, it might as well 
be the IANA.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Apr 2012 05:47:58 +0200 (MEST)

> work-in-progress drafts is good news.

The RFC that creates the IANA registry (usually the one that creates
the protocol in question) also defines the allocation policy for
registry values.  Often, the available number range is partitioned
into areas with different allocation policies.

  See the TLS registries here (textual):
  [1]   http://www.iana.org/assignments/tls-parameters/tls-parameters.txt

  [2]   http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.txt

and the allocation policies that the creator of the registry can choose from:
  [3]    http://tools.ietf.org/html/bcp26#section-4.1

Handshake messages are defined in [1], allocation policy "Standards Action".
Extension types are defined in [2], allocation policy "IETF Consensus"

The issue with too strict rules is that it may simply get ignored,
and code points be "kidnapped".  So overly strict rules can result
in an near complete loss of control over people&ideas whose time has come.

"It's easier to ask forgiveness than it is to get permission."

-Martin