Re: [TLS] Setting Policy for Extensions

Nikos Mavrogiannopoulos <> Wed, 27 July 2011 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4E5511E80DA for <>; Wed, 27 Jul 2011 09:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P8VTdQ57Td+E for <>; Wed, 27 Jul 2011 09:03:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C007211E80B1 for <>; Wed, 27 Jul 2011 09:03:30 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1042900wwe.13 for <>; Wed, 27 Jul 2011 09:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=xUkMfw2wwrbyNtWNzb2FsAP+hEP8l30Y3wV2zops3X8=; b=b4D+NlQ8sQenRMUt8uUoEiIlWLInJuswG3EsMLflQ0rvLHVBqu52zQB8tK4YyS6Ojs 8JAs7XeC9LmM5PdUl8QmXeLvP6XkQXep0Mep09u8O9k2olyJSmP1MiyCQe16jwML4uYr Qwg+GkHhAYy6n2hP0X7EInb96ddltfkqRycF4=
Received: by with SMTP id bw9mr3580654wbb.38.1311782609822; Wed, 27 Jul 2011 09:03:29 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id 20sm20578wbw.2.2011. (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 09:03:28 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Wed, 27 Jul 2011 18:03:26 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Eric Rescorla <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Setting Policy for Extensions
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, 27 Jul 2011 16:03:31 -0000

On 07/27/2011 04:33 PM, Eric Rescorla wrote:


> 1. All extensions to TLS (including AD sponsored extensions) must 
> minimally be sent explicitly to the TLS WG prior to or during IETF 
> LC. If that process surfaces significant objections, then these 
> objections should be resolved prior to publication. For trivial 
> extensions, this process is sufficient. An example of a trivial 
> extension would be signaling for a new TLS Exporter (RFC 5705), as 
> this has no impact on TLS proper.

How can that be enforced? In general I see little point of TLS-relevant
documents being processed outside the TLS WG.

> 3. Extensions which which involve significant changes to the TLS 
> model/state machine, adds new messages, etc. must be TLS WG work 
> items, or, if primarily designed for some other WG, must be work 
> items of that WG and developed in collaboration with the TLS WG and 
> subject to the WG consensus process. Extensions in this category will
> generally need to show significant amounts of non-author support in
> order to proceed.  Particular attention will be paid to the impact of
> such extensions on the TLS architecture and the impact on potential
> future extensions. An example of such an extension would be TLS
> Tickets (RFC 4507), because it involved redoing the resumption state
> machine and adding a new TLS message.

This is a significant barrier to publish a TLS WG draft. Even the
current ones do not fulfill this requirement. Questions:
1. How to show significant amount of non-author support?
2. Who will pay attention to the impact of those extensions?

In general it is not clear what the requirements of (3) are. Requiring
significant amount of non-author support sounds like an author has to
convince 30 reviewers to read and agree with his document. This is not
going to happen. I think having a concrete requirement, such as review
and positive opinion by 1-2 wg members set by the chair should be enough
to be adopted as WG draft (not that a WG draft does not imply
publication as RFC).