Skip to main content

X.509v3 Transport Layer Security (TLS) Feature Extension
draft-hallambaker-tlsfeature-10

Revision differences

Document history

Date Rev. By Action
2015-10-14
10 (System) Notify list changed from draft-hallambaker-tlsfeature.shepherd@ietf.org, turners@ieca.com, draft-hallambaker-tlsfeature@ietf.org, philliph@comodo.com, draft-hallambaker-tlsfeature.ad@ietf.org to (None)
2015-10-02
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-08-17
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-08-17
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-07-20
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-07-17
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-07-16
10 (System) IANA Action state changed to Waiting on Authors
2015-07-13
10 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-07-13
10 (System) RFC Editor state changed to EDIT
2015-07-13
10 (System) Announcement was received by RFC Editor
2015-07-13
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-07-13
10 Amy Vezza IESG has approved the document
2015-07-13
10 Amy Vezza Closed "Approve" ballot
2015-07-13
10 Amy Vezza Ballot approval text was generated
2015-07-13
10 Amy Vezza Ballot writeup was changed
2015-07-13
10 Amy Vezza IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-07-13
10 Stephen Farrell
[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 …
[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.
2015-07-13
10 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to Yes from Discuss
2015-07-13
10 Stephen Farrell Ballot writeup was changed
2015-07-06
10 Phillip Hallam-Baker IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2015-07-06
10 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-10.txt
2015-07-02
09 Jean Mahoney Closed request for Last Call review by GENART with state 'No Response'
2015-05-26
09 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2015-05-15
09 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2015-05-15
09 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tina Tsou.
2015-05-14
09 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2015-05-14
09 Stephen Farrell [Ballot discuss]
Discuss held on behalf of IANA.
2015-05-14
09 Cindy Morgan [Ballot Position Update] Position for Stephen Farrell has been changed to Discuss from Yes by Cindy Morgan
2015-05-14
09 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-05-14
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2015-05-13
09 Ben Campbell
[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 …
[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".
2015-05-13
09 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-05-13
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-05-13
09 Barry Leiba
[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 …
[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.
2015-05-13
09 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2015-05-13
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-05-11
09 Alvaro Retana [Ballot comment]
Expanding OCSP (and maybe pointing to RFC6960 for further reference) would be nice.
2015-05-11
09 Alvaro Retana Ballot comment text updated for Alvaro Retana
2015-05-11
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-05-10
09 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to Yes from Discuss
2015-05-09
09 Kathleen Moriarty
[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 …
[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.
2015-05-09
09 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2015-05-09
09 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-05-09
09 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-05-06
09 Stephen Farrell Placed on agenda for telechat - 2015-05-14
2015-05-06
09 Stephen Farrell Changed consensus to Yes from Unknown
2015-05-06
09 Stephen Farrell IESG state changed to IESG Evaluation from Waiting for Writeup
2015-05-06
09 Stephen Farrell Ballot has been issued
2015-05-06
09 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded for Stephen Farrell
2015-05-06
09 Stephen Farrell Created "Approve" ballot
2015-05-06
09 Stephen Farrell Ballot writeup was changed
2015-05-05
09 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-04-29
09 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-04-29
09 Pearl Liang
(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 …
(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.
2015-04-09
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Melinda Shore
2015-04-09
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Melinda Shore
2015-04-09
09 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2015-04-09
09 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2015-04-09
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2015-04-09
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Tina Tsou
2015-04-07
09 Amy Vezza IANA Review state changed to IANA - Review Needed
2015-04-07
09 Amy Vezza
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 …
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.


2015-04-07
09 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2015-04-07
09 Stephen Farrell Last call was requested
2015-04-07
09 Stephen Farrell Ballot approval text was generated
2015-04-07
09 Stephen Farrell Ballot writeup was generated
2015-04-07
09 Stephen Farrell IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2015-04-07
09 Stephen Farrell Last call announcement was changed
2015-04-07
09 Stephen Farrell Last call announcement was generated
2015-04-06
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-04-06
09 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-09.txt
2015-03-31
08 Stephen Farrell IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested::Revised I-D Needed
2015-03-31
08 Stephen Farrell IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested::AD Followup
2015-03-23
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-03-23
08 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-08.txt
2015-03-16
07 Stephen Farrell IESG state changed to Publication Requested::Revised I-D Needed from Publication Requested
2015-03-09
07 Stephen Farrell Assigned to Security Area
2015-03-09
07 Stephen Farrell Intended Status changed to Proposed Standard
2015-03-09
07 Stephen Farrell IESG process started in state Publication Requested
2015-03-09
07 Stephen Farrell IETF WG state changed to Submitted to IESG for Publication
2015-03-09
07 Stephen Farrell Changed document writeup
2015-03-09
07 Stephen Farrell Notification list changed to "Sean Turner" <turners@ieca.com>
2015-03-09
07 Stephen Farrell Document shepherd changed to Sean Turner
2015-03-09
07 Stephen Farrell Stream changed to IETF from None
2015-03-09
07 Stephen Farrell Shepherding AD changed to Stephen Farrell
2015-03-09
07 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-07.txt
2014-12-04
06 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-06.txt
2014-09-03
05 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-05.txt
2014-06-11
04 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-04.txt
2014-04-29
03 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-03.txt
2013-04-24
02 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-02.txt
2013-04-01
01 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-01.txt
2013-03-26
00 Phillip Hallam-Baker New version available: draft-hallambaker-tlsfeature-00.txt