Re: [TLS] Setting Policy for Extensions

[Martin Rex <[e-mail]>]

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