Re: [TLS] Setting Policy for Extensions

Martin Rex <mrex@sap.com> Thu, 28 July 2011 02:48 UTC

Return-Path: <mrex@sap.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 D017C11E8173 for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 19:48:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.912
X-Spam-Level:
X-Spam-Status: No, score=-9.912 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 HbeUthbCnrmT for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 19:48:37 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81411E807F for <tls@ietf.org>; Wed, 27 Jul 2011 19:48:36 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6S2mY8W007913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 28 Jul 2011 04:48:34 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107280248.p6S2mY16000185@fs4113.wdf.sap.corp>
To: paul.hoffman@vpnc.org (Paul Hoffman)
Date: Thu, 28 Jul 2011 04:48:34 +0200 (MEST)
In-Reply-To: <6965DB76-72C3-4AC1-92F5-699B8A2E4337@vpnc.org> from "Paul Hoffman" at Jul 27, 11 08:49:03 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Setting Policy for Extensions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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 02:48:37 -0000

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?


> 
> > 2. All non-trivial extensions (i.e., anything which alters TLS
> > processing in some way) must be presented to the TLS WG and at least
> > be considered unobjectionable.
> 
> OK, add "unobjectionable" to the list above.

I believe "unobjectionable" (should) refer to a clean issue resolution and
WG consensus procedure.


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

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


>
> Overall: The proposed rules above seem to be about the same as the
> unspoken rules today, with the difference being that they are stated
> but completely unclear. It doesn't feel like this is an improvement
> over the current situation.


I did not conceive it as an attempt to change the situation,
but more likely to summarize customs in writing, in face of the
recent flood of TLS-related documents, and where at least some
of the authors are not recognized as active TLS WG participants
which could be expected to know how things work around here.

Do you remember the discussion on these two proposals?
  http://tools.ietf.org/html/draft-santesson-tls-gssapi-03
  http://tools.ietf.org/html/draft-housley-evidence-extns-01


-Martin