X.509v3 Transport Layer Security (TLS) Feature Extension
RFC 7633

[Ballot comment]
I believe that version -10 resolves the issue for which I was holding a DISCUSS
on IANA's behalf and I'll send the approval announcement shortly. If that's
wrong then we can address that during RFC editor processing.

[Ballot comment]
I shared Barry's confusion about the term "TLS Feature Extension" in the context of section 1.2. I had to spin on this a bit to realize we were talking about an X509 extension that advertised TLS features rather than an "extension" of TLS "features".

[Ballot comment]
General comment: in a number of places you add an explanation of WHY.  I appreciate that, and I think it helps a lot -- especially when you're explaining a SHOULD.  Thanks.

-- Section 1.2 --

  In order to avoid the confusion that would occur in attempting to
  describe an X.509 extension describing the use of TLS extensions, in
  this document the term 'extension' is reserved to refer to X.509v3
  extensions and the term 'feature' is used to refer to a TLS
  extension.

I applaud the attempt to avoid confusion.  Yet this sentence itself confuses me.  What, then, is a "TLS feature extension"?  From the above, because it's an "extension", it's an X.509v3 extension.  But it sure sounds like it ought to be a TLS extension, and maybe it kinda is, because it has "feature" in it... but that's all very confusing and unclear, despite the attempt at clarity.

-- Section 2 --

  A Certification Authority SHOULD NOT issue certificates that specify
  a TLS feature extension advertising features that the server does not
  support.

How does the CA avoid it?  The next sentence basically says that the server self-declares what it supporte.  How does the CA know for sure?  Do you mean that the CA SHOULD NOT issue certs that specify features that the server does not CLAIM to support (you seem to say exactly that in 3.3.1)?  Or is there a way the CA can check, and it should do that?

-- Section 3.1 --

  If these
  features are requested by the client in its ClientHello message, then
  they MUST be present in the server's ServerHello.

I don't understand the MUST there.  Isn't the ClientHello making requests and the ServerHello responding with those the server agrees to offer?  Can you explain what you're trying to say with that MUST?

-- Section 3.2.2 --

  Specifically, a certificate that is signed by a Certificate
  Signing Certificate that contains a TLS feature extension MUST
  contain a TLS feature extension which MUST offer the same set or a
  superset of the features advertised in the signing certificate.

A small point, but the double MUST is unnecessary and awkward. I would change "which MUST offer" to "that offers" -- the first MUST has the requirement covered.

-- Section 5.2 --
I agree that this is probably not a big deal, but I posit that issuing a cert that clients will reject is likely a much more disruptive attack than refusing to issue the cert in the first place.  With a refusal to issue, the server admins know up front that there's an issue and can deal with it directly.  With the other, it may take some time to find out that something is amiss, and many customers might be angered in the process (because they couldn't get access to their accounts, or some such).  Sure, servers should test their new certs with strict clients before they roll them out... but I'm sure many don't.

[Ballot discuss]
Thanks for your work on this draft.  I just have one question that should be quick to clear up.

The extension defined in this draft and how to process it makes sense, but I'm left with the question of how to list the specific the TLS feature desired in the X.509 extension consistently when using it.  The examples were good, but what goes in the defined X.509 extension to identify the TLS feature extension?  Is there a registry of terms for TLS extensions that should be referenced or a consistent way to identify them from the various RFCs where they have been published?

If I missed it or exact details are not necessary, understanding why or pointing out where the text is would be helpful.

(Via drafts-lastcall@iana.org): IESG/Author:

IANA has reviewed draft-hallambaker-tlsfeature-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has one comment about the action requested by this draft.

IANA understands that, upon approval of this document, there is a single action which needs to be completed.

In the SMI Security for PKIX Certificate Extension subregistry [PKIX (1.3.6.1.5.5.7.1)] under
the SMI Security for PKIX sub-registry (PKIX (1.3.6.1.5.5.7)) of the Structure of
Management Information (SMI) Numbers (MIB Module Registrations) registry located at:

https://www.iana.org/assignments/smi-numbers/

a single, new assignment will be made as follows:

Decimal: [ TBD-AT-REGISTRATION ]
Description: id-pe-tlsfeature
Reference: [ RFC-TO-BE ]

IANA notes that the author suggests a value of 24 for this registration.

Comment:  As this document requests registrations in a Specification Required registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA understands that this action is the only one required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. 

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (X.509v3 TLS Feature Extension) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'X.509v3 TLS Feature Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-05-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The purpose of the TLS feature extension is to prevent downgrade
  attacks that are not otherwise prevented by the TLS protocol. In
  particular, the TLS feature extension may be used to mandate support
  for revocation checking features in the TLS protocol such as OCSP
  stapling.  Informing clients that an OCSP status response will always
  be stapled permits an immediate failure in the case that the response
  is not stapled. This in turn prevents a denial of service attack that
  might otherwise be possible.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ballot/

No IPR declarations have been submitted directly on this I-D.

This draft has previously been (briefly) discussed on the TLS WG list
but is not a working group item. The WG seemed fine with progressing
an earlier version at that time.