Re: [TLS] Setting Policy for Extensions

Eric Rescorla <> Thu, 28 July 2011 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7B1421F8C33 for <>; Thu, 28 Jul 2011 06:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vap0QkUlBOcR for <>; Thu, 28 Jul 2011 06:27:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 20B7E21F8877 for <>; Thu, 28 Jul 2011 06:27:45 -0700 (PDT)
Received: by wyj26 with SMTP id 26so23398wyj.31 for <>; Thu, 28 Jul 2011 06:27:45 -0700 (PDT)
Received: by with SMTP id g26mr30975wbe.37.1311859665210; Thu, 28 Jul 2011 06:27:45 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 28 Jul 2011 06:27:24 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Eric Rescorla <>
Date: Thu, 28 Jul 2011 09:27:24 -0400
Message-ID: <>
To: Paul Hoffman <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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: Thu, 28 Jul 2011 13:27:47 -0000

On Thu, Jul 28, 2011 at 7:35 AM, Paul Hoffman <> wrote:
> On Jul 27, 2011, at 10:48 PM, Martin Rex wrote:
>> Overall I'm OK with Erics message.
>> I did not notice anything unusual, unexpected or objectionable,
>> but things that I silently assumed or consider a reasonable approach.
>> Paul Hoffman wrote:
>>> On Jul 27, 2011, at 10:33 AM, 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.
>>> The person who gets to define "significant" and "resolved" controls all
>>> extensions, then. It would be better if they were defined more fully here.
>> The description in (1) sound like WG review and WG consensus process
>> in case that objections are raised.  "A person" would probably more
>> apply to "expert review" situations.
>> What exactly are you looking for?  That the TLS WG should come up with
>> a more narrow "consensus" than used in the rest of the IETF?
> Note that #1 is not about WG documents, but documents that start outside the WG. If you feel that every document that starts outside the WG needs to have WG consensus, that's fine; I believe that would be unique in the IETF.

As noted previously, the standard for TLS extensions is IETF Consensus. No,
I don't think it's unusual to think that documents relating to protocol X which
require IETF Consensus also need to have WG X at least give it a no-obj.
I don't think the text above required a WG LC for extensions in category 1.

> A different model, one that is much more common in the IETF, would be that for non-WG documents, the AD reviews the discussion on the WG mailing list and decides.

I don't necessarily have a problem with that, but I don't really think that this
is much different as a standard, just a matter of whether the chairs or the AD
assesses the discussion.

>>> Why is adding a message so important here?
>>> Who defines what changes the "TLS model" or "TLS state machine?
>> Because new TLS handshake messages, and the exact ordering of the handshake
>> messages have a significant impact on the TLS state machine, and the
>> insertion or ommission of messages might have non-obvious consequences
>> for the security properties of the protocol.

In addition, new TLS handshake message require a Standards Track document in
any case, and I don't think it's at all unreasonable to expect that
Standards Track
documents in TLS have active TLS WG involvement.

>> The ordering of TLS extensions in Client and Server Hello handshake
>> messages is well defined (=arbitrary/unordered) -- unless there are
>> competing or conflicting extensions.
>>  competing=diffing preference/ordering about the same characteristic
>>  conflicting=different specificiation of the same characteristic
> This is the kind of specificity that would be very useful in the policy, and should be extended to the definition of the "TLS model" and "TLS state machine".

I have no problem with that.