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
- [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Nikos Mavrogiannopoulos
- Re: [TLS] Setting Policy for Extensions Paul Wouters
- Re: [TLS] Setting Policy for Extensions Paul Hoffman
- Re: [TLS] Setting Policy for Extensions Nico Williams
- Re: [TLS] Setting Policy for Extensions Martin Rex
- Re: [TLS] Setting Policy for Extensions Paul Hoffman
- Re: [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Eric Rescorla
- Re: [TLS] Setting Policy for Extensions Martin Rex
- Re: [TLS] Setting Policy for Extensions Nico Williams
- Re: [TLS] Setting Policy for Extensions t.petch