Re: [TLS] Setting Policy for Extensions

Eric Rescorla <ekr@rtfm.com> Thu, 28 July 2011 13:27 UTC

Return-Path: <ekr@rtfm.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 E7B1421F8C33 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 06:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vap0QkUlBOcR for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 06:27:46 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20B7E21F8877 for <tls@ietf.org>; Thu, 28 Jul 2011 06:27:45 -0700 (PDT)
Received: by wyj26 with SMTP id 26so23398wyj.31 for <tls@ietf.org>; Thu, 28 Jul 2011 06:27:45 -0700 (PDT)
Received: by 10.227.39.154 with SMTP id g26mr30975wbe.37.1311859665210; Thu, 28 Jul 2011 06:27:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.145.209 with HTTP; Thu, 28 Jul 2011 06:27:24 -0700 (PDT)
In-Reply-To: <2D202CBD-BBEC-4257-9431-F69681383192@vpnc.org>
References: <201107280248.p6S2mY16000185@fs4113.wdf.sap.corp> <2D202CBD-BBEC-4257-9431-F69681383192@vpnc.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Jul 2011 09:27:24 -0400
Message-ID: <CABcZeBN3qd83ddC-7VQDj7SOiULy_GCXyvyQ4muiJD==KjzcrA@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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: Thu, 28 Jul 2011 13:27:47 -0000

On Thu, Jul 28, 2011 at 7:35 AM, Paul Hoffman <paul.hoffman@vpnc.org> 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.

-Ekr