Re: [TLS] Setting Policy for Extensions

[Paul Hoffman <[e-mail]>]

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.

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.

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

Again, that's one option (and apparently the one we are living with today); another would be like what many other areas use.

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

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

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

Unfortunately, I fully agree.

> 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

--Paul Hoffman