Re: [TLS] Setting Policy for Extensions

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 27 July 2011 16:03 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5511E80DA for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 09:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8VTdQ57Td+E for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 09:03:31 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C007211E80B1 for <tls@ietf.org>; Wed, 27 Jul 2011 09:03:30 -0700 (PDT)
Received: by wwe5 with SMTP id 5so1042900wwe.13 for <tls@ietf.org>; Wed, 27 Jul 2011 09:03:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.227.181.9 with SMTP id bw9mr3580654wbb.38.1311782609822; Wed, 27 Jul 2011 09:03:29 -0700 (PDT)
Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id 20sm20578wbw.2.2011.07.27.09.03.27 (version=SSLv3 cipher=OTHER); Wed, 27 Jul 2011 09:03:28 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4E3036CE.6080901@gnutls.org>
Date: Wed, 27 Jul 2011 18:03:26 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
In-Reply-To: <CABcZeBPRXJ27LVRc3w5pyvi3wVqw=EHeKJt-SBoYHYLOeXwX6w@mail.gmail.com>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Setting Policy for Extensions
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 16:03:31 -0000

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

Hello,

> 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).

regards,
Nikos