Subject: [TLS] request for early IANA assignment for ALPN

From: Sean Turner <[email-masked]>
Date: Tue, 26 Mar 2013 20:41:50 -0400

I received a verbal request for an early IANA assignment for ALPN in the 
TLS extension type registry from Adrei P, Stephan F, and Adam L at the 
meeting in Orlando.  I've double checked with them and the WG chairs to 
make sure that's still desired.  Not so shocking the answer was yes.

The TLS extension type registry is eligible for early assignment if 
approved by the IESG (I double checked).  I asked a couple of folks 
whether they thought the format, semantics, processing, etc were 
adequately described and they said they were.  It's a pretty simple 
extension so it's probably not going to change much, and there's 
definitely interest in pre-RFC implementation.

Based on the WG adopting the TLS-based upper-layer protocol negotiation 
mechanism working item in Atlanta, what looks like consensus to me on 
using ALPN, and the fact that we're not exactly running out of code 
points I'm going to request that the IESG approve an early assignment. 
But, there's no guarantee it'll happen Thursday.

spt

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 27 Mar 2013 08:16:30 +0100

> using ALPN, and the fact that we're not exactly running out of code

The advantage of no point registration during draft stage is that
contributors are not limited by arguments like "this is now implemented
and deployed - too difficult to change". The disadvantage is no
interoperability testing.

However, I'd find it nice to easily reserve points for ciphersuites or
other TLS IANA managed points at an early stage of a draft for
interoperability testing. Those points could be reserved for a limited
time and kept if the RFC is identical to the draft. So I think that such
process should be generalized, if possible, rather than applied only for
ALPN.

regards,
Nikos

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 27 Mar 2013 09:43:30 +0100

As Nikos said, there are advantages and disadvantages with an early  
assignment.

In my opinion, the risk of changes to the format should mean that a  
permanent assignment should not be done at this stage.

After all, the format of my multistapling draft did change once I had some  
implementation experience, although that was before it became a WG item.  
If the change had happened after several test implementations had been  
deployed with a reserved number, we might have had a problem, particularly  
if the extension had been deployed in final versions of products.

Instead, I would suggest that a temporary number from a (reusable) range  
that is allocated to testing is used. A permanent number can be assigned  
once development is complete.

The temporary number means that everybody are on notice that the spec is  
still under development and subject to change, and should only be deployed  
in test-versions of products, not final versions.

On Wed, 27 Mar 2013 01:41:50 +0100, Sean Turner <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 27 Mar 2013 10:32:58 -0700

> permanent assignment should not be done at this stage.

I don't believe Nikos was suggesting early "permanent assignment" as a
general process.  I believe he was suggesting that TLS should have a
process for temporarily reserving ExtensionType (and perhaps
CipherSuite?) numbers.

I think this is a great idea.

This would allow new proposals to document what numbers they're using
for interop testing and experiments, avoiding the sorts of collisions
that occurred around the time of TLS-SRP (several proposals were using
the "next" ExtensionType, so software changes were needed after RFC
issuance, solely for the final IANA numbers).

Another example is TACK: we are using an ExtensionType number for
testing, and will be increasingly using it for test and trial
deployments.  It would be great if there was some process for
documenting / deconflicting this with other Internet-Drafts.

> once development is complete.

The boundaries between experimental and actual deployments aren't
always clear-cut.  You're proposing a "flag day" on RFC issuance,
where all existing depoyments of a TLS technology must cut-over to a
new number.

A "temporary reservation" process based on rough WG consensus (which
the WG would periodically review) seems much better to me.

Trevor

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 27 Mar 2013 11:09:51 -0700

> process for temporarily reserving ExtensionType (and perhaps

We could assign a single extension number for experimental use and then
pack it with (a list of) experimental extensions:

     struct {
         opaque extension_name<1..255>;
         opaque extension_data<0..2^16-1>;
     } ExperimentalExtension;

     ExperimentalExtension experimental_extensions<4..65535>;

So then ALPN would look like:

     0x04 'A' 'L' 'P' 'N'

followed by the same extension data that would appear once ALPN becomes
a numbered extension.

The added complexity for parsing this structure only affects code that is
working on experimental extensions; normal clients and servers will simply
ignore the extension.

Mike

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 27 Mar 2013 11:57:58 -0700

>     ExperimentalExtension experimental_extensions<4..65535>;

Hmm.... so we'd have to do all interop testing and trial deployments
based on an "ExperimentalExtension".  Then - once everything is
working and RFCs are assigned - make a major incompatible protocol
change to a different extension format.

I see the costs and risks here, but not the benefit.

What does this solve that is not solved by having someone maintain a
wiki listing temporary ExtensionType assignments (based on, say, WG
rough consensus, re-confirmed at each IETF meeting)?

This is essentially just formalizing / documenting existing practice,
and provides a smooth path between I-D and RFC deployments without
needing a "flag day" protocol change.

Trevor

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 27 Mar 2013 15:23:56 -0700

> change to a different extension format.

The extension_data would not change.  The only difference would be in
locating it.

> I see the costs and risks here, but not the benefit.

The problem with using a range of temporary extension numbers comes when
you run out and have to reuse one.  Somewhere a server that hasn't been
updated in years will be running code like this:

     switch (extension_number) {
        case 0x0000:     process_sni_extension(); break;

        case 0xABCD:     // experimental ALPN extension number - REMOVE!
        case 0x00xx:     // IANA-assigned ALPN extension number
                         process_alpn_extension(); break;
     }

If 0xABCD is ever used for any other experimental extension, it could
cause this server to start acting funny.

Using names for experimental extensions avoids this problem.

> rough consensus, re-confirmed at each IETF meeting)?

The problem outlined above, plus it allows for non-IETF-sanctioned
experiments such as NPN/SPDY.  The wire format of an extension could
change during the experiment - simply add "v2" to the name instead of
requiring a new number assignment via rough consensus at the next IETF
meeting resulting in a wiki update.

Mike

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Mar 2013 17:53:55 -0500

You could put (year-2000) as the top two bytes of the extension number, and promise that no temporary assignment lasts more than two years. That way it could be made obvious when your counter-party is using an outdated temporary identifier. And I wouldn't worry about round-off or encoding the month.

	/r$, who apparently pines for the pre-CIDR days

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 27 Mar 2013 16:29:14 -0700

> The extension_data would not change.  The only difference would be in

Sure.  But it's still a code change *after* all the testing and
deployment that went into the Internet-Draft.

> you run out and have to reuse one.

I wasn't proposing a separate range of temporary extension numbers.

I was seconding Nikos' proposal that there should be an easy way for
implementors of an Internet-Draft to temporarily reserve "real"
numbers while doing testing and trial deployment.

If the Internet-Draft advances to RFC, those numbers can be enshrined
by IANA.  Otherwise, they're recycled.

>  Somewhere a server that hasn't been

We're proposing the opposite of this - instead of having different
code paths for I-D vs RFC, there should be one code path (i.e the IANA
should have assigned 0xABCD, above).

> meeting resulting in a wiki update.

If early implementors of an I-D need to make a wire format change, I
think they should upgrade their implementations and keep using the
same temporarily-reserved extension number.

Trevor