Subject: [TLS] Setting Policy for Extensions

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jul 2011 10:33:15 -0400

TLS WG members,

The WG is starting to see an increasing number of proposals for new
extensions, and it seems like it would be good to have a consistent
policy for how to handle these. The chairs have gotten together with
our AD and converged on the following draft policy, which we plan
to discuss in the " Working Group Handling for Extensions to TLS"
slot.

Comments?
-Ekr

[For Joe and Eric]

RFC 5246 defines an extensibility mechanism for TLS based on
extensions signaled in the ClientHello and ServerHello. With TLS 1.2
and DTLS 1.2 being relatively stable, we are starting to see more
proposed extensions, some of which, if used, represent significant
changes to the TLS state machine.  RFC 5246 requires IETF consensus
for any extension. As there is an active TLS WG, this implies that
extensions must be vetted with that WG. The following policy
describes the level of review necessary for various types of
proposed extension:

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.

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. They need not be WG items.  Extensions
in this category can proceed without widespread WG support, but must
either have no significant objections or achieve WG consensus to
proceed.  An example of a non-trivial extension would be one that
defined a new form of MAC truncation. This alters TLS processing but
not the state machine.

3. Extensions which which involve significant changes to the TLS
model/state machine, adds new messages, etc. must be TLS WG work
items, or, if primarily designed for some other WG, must be work items
of that WG and developed in collaboration with the TLS WG and subject
to the WG consensus process. Extensions in this category will
generally need to show significant amounts of non-author support in
order to proceed.  Particular attention will be paid to the impact of
such extensions on the TLS architecture and the impact on potential
future extensions. An example of such an extension would be TLS
Tickets (RFC 4507), because it involved redoing the resumption state
machine and adding a new TLS message.

The WG considers it an important objective to to provide timely,
clear dispositions of new efforts. Work will be taken on when there is
consensus and based on the WG's estimate of the level of interest and
the size and priority of the current workload. Reconsideration of
proposals which have failed to gather consensus will be prioritized
behind proposals for new work which have not yet been considered.
In general, requests for reconsideration should only be made once a
proposal has been significantly revised and there is evidence of
substantial level of community support.

Best,
-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 27 Jul 2011 18:03:26 +0200

On 07/27/2011 04:33 PM, Eric Rescorla wrote:

Hello,

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

How can that be enforced? In general I see little point of TLS-relevant
documents being processed outside the TLS WG.

> items, or, if primarily designed for some other WG, must be work 
> items of that WG and developed in collaboration with the TLS WG and 
> subject to the WG consensus process. Extensions in this category will

This is a significant barrier to publish a TLS WG draft. Even the
current ones do not fulfill this requirement. Questions:
1. How to show significant amount of non-author support?
2. Who will pay attention to the impact of those extensions?

In general it is not clear what the requirements of (3) are. Requiring
significant amount of non-author support sounds like an author has to
convince 30 reviewers to read and agree with his document. This is not
going to happen. I think having a concrete requirement, such as review
and positive opinion by 1-2 wg members set by the chair should be enough
to be adopted as WG draft (not that a WG draft does not imply
publication as RFC).

regards,
Nikos

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Jul 2011 15:23:45 -0400 (EDT)

> to discuss in the " Working Group Handling for Extensions to TLS"

Overal I agree with the document, though I'd like to point out that
someones important use case can be totally irrelevant to someone elses set
of use cases, and the TLS group should try to be accomodating, providing
the proper security considerations are complied with. It is very easy to
say "I do not see a use for this new extension" which does run the risk
of stiffling new technologies. Though I also understand the need for
being conservative with a security protocol. I do think this document
balances the two properly. So I agree with the document as proposed.

But I do have some questions, partially based on my own recent submission
of a TLS extension draft.

> be considered unobjectionable. They need not be WG items.

I was under the impression that any standards document should have
TLS WG consensus and that extensions could not be an Informational?
In which case they can only be WG items. (note: this is one of the
reasons I brought my draft to the TLS WG instead of continuing for
an Individual / Informational RFC)

Would this document change that? I am not sure how relevant this
really is. When I started looking at TLS in more detail in the last
six months, I was pretty disappointed at the implementation of certain
TLS extensions. It seemed even a TLS 1.2 specification was not really
deployed anywhere, and neither were for example parts of RFC 6066.
(based on checking various apache and openssl code/sites)

>  Extensions

I am not entirely sure if my draft would fall under this category, but
I think it does?

> to the WG consensus process.

If it is really so intrusive to the TLS protocol, I would say it has to
be more then an item for another WG.

It is also a bit of a catch22. In my case, DANE awaits me to go to TLS,
and this paragraph would have TLS sent me back to DANE.

> substantial level of community support.

+1

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Jul 2011 20:49:03 -0400

> signaling for a new TLS Exporter (RFC 5705), as this has no impact on

The person who gets to define "significant" and "resolved" controls all extensions, then. It would be better if they were defined more fully here.

> be considered unobjectionable.

OK, add "unobjectionable" to the list above.

> They need not be WG items.  Extensions

Why is adding a message so important here? Who defines what changes the "TLS model" or "TLS state machine?

> Extensions in this category will
> the size and priority of the current workload.

Who defines "level of interest"? If there is a document that is fairly trivial and also gets little interest, is it prohibited from progressing by this rule?

> Reconsideration of

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.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 27 Jul 2011 21:18:22 -0500

The TLS WG need not be around forever, so this
WG-consensus-on-non-objectionability concept has at least that problem.
Beyond that, do we have precedent for requiring that there be WG consensus
that a proposal is not objectionable?  (As opposed to WG consensus that the
proposal should progress.)

I would rather say that the IESG can require review in a then-appropriate
WG  (i.e., WG LC) in addition to IETF LC.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2011 04:48:34 +0200 (MEST)

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

> 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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 28 Jul 2011 07:35:12 -0400

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

> I believe "unobjectionable" (should) refer to a clean issue resolution and

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

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

> but more likely to summarize customs in writing,

Unfortunately, I fully agree.

> in face of the

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Jul 2011 09:27:24 -0400

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

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.

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Jul 2011 09:29:28 -0400

> proposal should progress.)

I was thinking of "not objectionable" as a lower bar than "should
progress", so this
may be a writing issue. The idea here is to contrast it to category
(3) which needs
active support, whereas "not objectionable" was intended to mean "some people
(perhaps only a few) want it and other people don't care".

> WG  (i.e., WG LC) in addition to IETF LC.

Yes, I think that once the TLS WG has closed, the IESG can do what it wants.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Thu, 28 Jul 2011 18:09:06 +0200 (MEST)

Paul Hoffman wrote:
> Martin Rex wrote:
> 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.

A decent level of "review" may involve discussion among WG participants,
and it might be more appropriate to have those discussions on the WG
mailing list rather than on [email-masked], use semi-formal sync-points
when the discussion shifts to the WG mailing list and back, at the end
have a WG summary posted back to [email-masked]

-Martin

---

From: Nico Williams <[email-masked]>
Date: Thu, 28 Jul 2011 11:33:59 -0500

A better way to word this might be to say that all TLS extensions I-Ds
must be announced at an IETF mailing list that is appropriate for
discussion of TLS (for now, the TLS WG's list), and that upon request
by any appropriate WG's chairs or by any IESG members, any such TLS
extension proposal would have to require WG review -- the outcome of
which must be consensus on the question of whether the proposal may or
may not progress and/or whether it should be adopted as a WG work item
(thus requiring WG LC, not merely WG review).  I think this would
result in a high likelihood that folks who might object to a given
proposal would have a chance to have their objections heard, and then
for consensus to be reached.

Of course, there might be situations where objections will be ignored
(because WG chairs and IESG members are unwilling to request WG
review).  An appeal path to the IAB might be desirable, but I
seriously doubt we'd ever need it.

Nico
--