Subject: [TLS] Process for TLS Extensions

From: Joe Salowey <[email-masked]>
Date: Wed, 16 Nov 2011 01:28:04 -0800

Below is a statement on the process for TLS extensions that we worked on with Sean Turner with helpful input from Paul Hoffman.    We will have some discussion on this in the Taipei meeting and on the TLS list.  

RFC 5246 defines an extensibility mechanism for TLS based on
extensions signaled in the ClientHello and ServerHello. With TLS 1.2
and DTLS 1.2 being relatively stable, we are starting to see more
proposed extensions, some of which, if used, represent significant
changes to the TLS processing model or state machine.  RFC 5246
requires IETF consensus for any extension, either through individual
submission to an Area Director or to the TLS Working Group (for as
long as the WG exists).

Any proposed extension can be brought to the Security Area Director
as an individual submission for IETF consensus; it can also be brought 
directly to the TLS WG. In the former case, the Area
Director will decide whether he/she believes the extension needs to be
processed through the TLS WG or just to process it through IETF Last
Call. This decision will be made based on the level of impact the
extension would have on TLS. Specifically, any extension which would
cause a significant change to the TLS processing model or state
machine will be referred to the TLS WG. The Security Area Director
may also ask the WG chairs and other active TLS participants ahead of
time about whether or not a particular proposal should be processed
(if at all) in the TLS WG. The AD may decide not to allow an extension
to progress based on feedback from the working group and other
sources.

In the case of drafts going through IETF Last Call, the TLS WG mailing
list will be informed of the IETF Last Call ahead of or concurrently
with the Last Call.

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 17 Nov 2011 21:14:54 +0100

On 2011-11-16 10:28, Joe Salowey wrote:
> Below is a statement on the process for TLS extensions that we worked 
> on with Sean Turner with helpful input from Paul Hoffman.
> We will have some discussion on this in the Taipei meeting and on the TLS list.

It is sort of a cute proposal but it is fairly useless.

Google have already implemented their OBC extension so this
process will only stop people who already have problems getting
through with their stuff.

IMO, Google did the right thing.  Standards must be tested
before they are indeed made "standard" otherwise we only get
bad stuff like S/MIME.

Anders

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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Nov 2011 01:12:50 +0200

> before they are indeed made "standard" otherwise we only get

The flip side of this is that when those things are brought to an IETF working group, there is tremendous pressure not to break compatibility with implementations already deployed in the field. All that remains for the IETF to do is to dot the i's, cross the t's and bless the standard with an RFC number.

---

From: Wan-Teh Chang <[email-masked]>
Date: Thu, 17 Nov 2011 16:00:02 -0800

On Thu, Nov 17, 2011 at 3:12 PM, Yoav Nir <[email-masked]> wrote:
>
> The flip side of this is that when those things are brought to an IETF working group,
> there is tremendous pressure not to break compatibility with implementations already
> deployed in the field. All that remains for the IETF to do is to dot the i's, cross the t's
> and bless the standard with an RFC number.

This is not always true.  A counterexample is TLS itself.  TLS 1.0 is more than
dotting the i's, crossing the t's, and blessing SSL 3.0 with an RFC number.

Wan-Teh