The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
draft-ietf-tls-multiple-cert-status-extension-08

[Ballot comment]

Thanks for quickly handling my discuss points!

I note the 2560/2560bis issue still needs fixing and am ok
that that'll be done. If the answer is that 2560bis becomes
the normative reference then that's fine, but in that case
I do think it'd be good to retain the text that clarifies how
to handle id-pkix-ocsp-nonce if you're coding this based on
a 2560 and not a 2560bis implementation, since that
will be the case for a while yet. And that'd mean keeping
2560 as an informative ref too.

[Ballot comment]
If this document were updated to reference 2560bis instead of 2560, I think this text could simply be removed, since the correction is present in 2560bis:

  In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is       
  unclear about its encoding; for clarification, the nonce MUST be a         
  DER-encoded OCTET STRING, which is encapsulated as another OCTET           
  STRING (note that implementations based on an existing OCSP client         
  will need to be checked for conformance to this requirement).               

If the authors do not want to reference 2560bis for some reason, then the above language seems to me to update 2560.

  The items in the list of CertificateStatusRequestItemV2 entries are
  in order of the client's preference (favorite choice first).

Does the idea of "favorite choice first" really make sense?  Either an OCSP responder is trusted or not, right?  I'm not so clear on the architecture here that I can be sure this question makes sense, but I wonder if randomizing the list doesn't make just as much or more sense than ordering it according to some unspecified notion of favorites.

[Ballot discuss]
Two points that I would like some clarification on:

1. It seems like this document should Update RFC 6066.  It doesn't change anything in the document, but it's effectively a "v2" of the OCSP status request extension.

2. It seems like this document should reference RFC 2560bis instead of RFC 2560.

[Ballot comment]
In the Abstract, this phrase seems unclear: "multiple certificate status methods (commonly referred to as OCSP stapling)".  Suggest: "multiple certificate status methods.  (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".)"

In Section 2.2., it would be helpful if you could clarify which parts are new, and which are restated from RFC 6066.

In Section 2.2., "see also" should be "as defined in"

[Ballot discuss]
Two cleared, two to go:-)

(1) cleared

(2) 2.2, last para: the language here is pretty yukky, for
example the terms "inconclusive," "believes," "might wish" and
(particularly) "engage in activities that require trust" all
seem like things that generic TLS client code will not get
right. If you tell me that this language is the result of a
hard-fought set of WG discussions, I'll clear, but if it
didn't get significant WG discussion, (sorry, can't recall)
then I think it needs to be fixed up so as to be something a
piece of generic TLS client code can implement, with the
higher/application layer issues clearly separated out from
things that generic TLS client code can reasonably do.
Here's a suggested replacement for that paragraph:

"
  If the OCSP response received from the server does not result in
  a "good" or "revoked" status, it is inconclusive.  A TLS client
  in such a case MAY check the validity of the server certificate
  through other means, e.g., by directly querying the certificate
  issuer's CRL or OCSP responders. If such processing still results
  in an inconclusive response this creates a tricky issue for the
  application that includes a TLS client that uses this
  specification - should it fail the connection or not?  Note that
  this is really an issue for the application using TLS and cannot
  be handled by the generic TLS client code without information
  from the application. If the application doesn't provide any such
  information, then the client MUST abort the connection since the
  server certificate has not been sufficiently validated.

  An example of where the application might wish to continue is
  with EAP-TLS, where the application can use another mechanism to
  check the status of a certificate once it obtains network access.
  In this case, the application could have the client continue with
  the handshake, but it MUST NOT disclose a username and password
  until it has fully validated the server certificate.
"

Yngve suggested a tweak to the above which seemed good.

(3) cleared

(4) cleared

[Ballot comment]
- intro, I think you *really* should also note the potential
privacy benefit here too - if the reduced roundtrips mean that
the browser/client doesn't have to tell a CA/OSCP-responder
the certificate serial number of a TLS server with which its
negotiating that's a positive privacy benefit.

Yngve suggested this which is good I think:

  "Additionally, using this extension significantly reduces
  privacy concerns around the clients informing the Certificate
  Issuer about which sites they are visiting."

- 2.2 says 2560 is unclear about encoding a thing - is there
an erratum for that? 6677 updates 2560, does it include the
clarification? Is "checked for conformance" the right term to
use? Maybe "might need to be modified" would be better?

I think that means you need to reference 2560bis as normative.
Maybe add text meaning "2560bis is the way you should do this
but lots of people will be doing 2560 for ages yet" and probably
say that 2560bis fixes this issue too.

- 4.1, given that the client can send the server a possibly
long list of things to do and maybe send the server to a slow
responder, don't you need to note that servers need to
consider accidental or deliberate potential DoS as a result? I
guess just saying to be careful with handling the
client-specified data as usual would be enough.

Maybe say something like:

  "since this extension (like others) allows the client to get the
  server to do work, server implementers need to be aware that
  that could be a DoS vector"

Some more tweaks to the above suggested. I also cleared
discuss point 3 which was:

What does a server do with a request list that contains
stuff the server doesn't understand? I assume the server ought
ignore any such garbage Extensions or unknown ResponderID
fields? (ResponderID can be an X.500 Name, so can also contain
who-knows-what crapology;-)  Don't you need to say that?
(Maybe that's elsewhere in 2560 or 5246 or 6066, which'd be
fine, but I didn't check;-)

Yngve said basically those are passed on to the OSCP
responder but probably not parsed. Be good to say that
in the draft.

[Ballot discuss]

Two cleared, two to go:-)

(1) cleared

(2) 2.2, last para: the language here is pretty yukky, for
example the terms "inconclusive," "believes," "might wish" and
(particularly) "engage in activities that require trust" all
seem like things that generic TLS client code will not get
right. If you tell me that this language is the result of a
hard-fought set of WG discussions, I'll clear, but if it
didn't get significant WG discussion, (sorry, can't recall)
then I think it needs to be fixed up so as to be something a
piece of generic TLS client code can implement, with the
higher/application layer issues clearly separated out from
things that generic TLS client code can reasonably do.
Here's a suggested replacement for that paragraph:

"
  If the OCSP response received from the server does not result in
  a "good" or "revoked" status, it is inconclusive.  A TLS client
  in such a case MAY check the validity of the server certificate
  through other means, e.g., by directly querying the certificate
  issuer's CRL or OCSP responders. If such processing still results
  in an inconclusive response this creates a tricky issue for the
  application that includes a TLS client that uses this
  specification - should it fail the connection or not?  Note that
  this is really an issue for the application using TLS and cannot
  be handled by the generic TLS client code without information
  from the application. If the application doesn't provide any such
  information, then the client MUST abort the connection since the
  server certificate has not been sufficiently validated.

  An example of where the application might wish to continue is
  with EAP-TLS, where the application can use another mechanism to
  check the status of a certificate once it obtains network access.
  In this case, the application could have the client continue with
  the handshake, but it MUST NOT disclose a username and password
  until it has fully validated the server certificate.
"

(3) What does a server do with a request list that contains
stuff the server doesn't understand? I assume the server ought
ignore any such garbage Extensions or unknown ResponderID
fields? (ResponderID can be an X.500 Name, so can also contain
who-knows-what crapology;-)  Don't you need to say that?
(Maybe that's elsewhere in 2560 or 5246 or 6066, which'd be
fine, but I didn't check;-)

(4) cleared

[Ballot comment]

- intro, I think you *really* should also note the potential
privacy benefit here too - if the reduced roundtrips mean that
the browser/client doesn't have to tell a CA/OSCP-responder
the certificate serial number of a TLS server with which its
negotiating that's a positive privacy benefit.

Yngve suggested this which is good I think:

  "Additionally, using this extension significantly reduces
  privacy concerns around the clients informing the Certificate
  Issuer about which sites they are visiting."

- 2.2 says 2560 is unclear about encoding a thing - is there
an erratum for that? 6677 updates 2560, does it include the
clarification? Is "checked for conformance" the right term to
use? Maybe "might need to be modified" would be better?

I think that means you need to reference 2560bis as normative.
Maybe add text meaning "2560bis is the way you should do this
but lots of people will be doing 2560 for ages yet" and probably
say that 2560bis fixes this issue too.

- 4.1, given that the client can send the server a possibly
long list of things to do and maybe send the server to a slow
responder, don't you need to note that servers need to
consider accidental or deliberate potential DoS as a result? I
guess just saying to be careful with handling the
client-specified data as usual would be enough.

Maybe say something like:

  "since this extension (like others) allows the client to get the
  server to do work, server implementers need to be aware that
  that could be a DoS vector"

[Ballot discuss]

I think these discuss points should hopefully go away pretty
quickly, but given that TLS is just getting more important I
figure asking is safer/right.

(1) How does this play with 2560bis? I'm not sure if you ought
say anything here or not, but I wonder how all the 2560bis
discussion about handling mis-issued certs via HTTP errors
might play here. Given both drafts are on the same telechat,
it seems like we should know the answer to this:-)

(2) 2.2, last para: the language here is pretty yukky, for
example the terms "inconclusive," "believes," "might wish" and
(particularly) "engage in activities that require trust" all
seem like things that generic TLS client code will not get
right. If you tell me that this language is the result of a
hard-fought set of WG discussions, I'll clear, but if it
didn't get significant WG discussion, (sorry, can't recall)
then I think it needs to be fixed up so as to be something a
piece of generic TLS client code can implement, with the
higher/application layer issues clearly separated out from
things that generic TLS client code can reasonably do.

(3) What does a server do with a request list that contains
stuff the server doesn't understand? I assume the server ought
ignore any such garbage Extensions or unknown ResponderID
fields? (ResponderID can be an X.500 Name, so can also contain
who-knows-what crapology;-)  Don't you need to say that?
(Maybe that's elsewhere in 2560 or 5246 or 6066, which'd be
fine, but I didn't check;-)

(4) Can the client supply a load of garbage bytes here that'd
feed into the FINISHED message hash calculation in a dodgy way
with e.g. some dodgy ciphersuite? I'm thinking of the way
chosen-prefix collisions were used in the hashclash attack and
whether maybe a bad client could take advantage of that by
including sufficient garbage in the request list. I can't see
an actual attack here right now, so I'll clear this if you
tell me its ok, but I do wonder if 4.1 maybe ought say that
servers SHOULD do some sanity checking and also say how to
barf the session if that checking fails. (If so, the
sanity-checking would of course need to be described a bit at
least.)

[Ballot comment]

- abstract: this says "version 2" which would raise an
expectation that something (6066?) might be UPDATED or
OBSOLETED or whatever. I would think that the intermediate CA
thing might mean that we really would like folks to move away
from the current OCSP extension, and onto this, and the RFC
meta-data might help there maybe.  (I don't care myself, but
just wanna check if that was considered or not since some
people do care:-)

- intro, is this intended only to be used with TLS1.2 or also
with implementations of earlier versions or SSL?

- intro, I think you *really* should also note the potential
privacy benefit here too - if the reduced roundtrips mean that
the browser/client doesn't have to tell a CA/OSCP-responder
the certificate serial number of a TLS server with which its
negotiating that's a positive privacy benefit.

- intro, 3rd para: It'd be great to have a reference for some
of those cases where OCSP caused n/w problems for a CA. I can
understand if folks might prefer not to add that, but if its
already public somewhere that reference could be quite useful.
(As a lesson in what not to do again;-)

- intro, 2nd last para: you could probably add a reference to
CT there as an example of a nascent "alternative PKI
structure." If you do, please do make sure the reader gets the
fact that CT is experimental. In any case, some reference
would be good as this kind of leaves the reader wondering.

- 2.2 says 2560 is unclear about encoding a thing - is there
an erratum for that? 6677 updates 2560, does it include the
clarification? Is "checked for conformance" the right term to
use? Maybe "might need to be modified" would be better?

- 4.1, given that the client can send the server a possibly
long list of things to do and maybe send the server to a slow
responder, don't you need to note that servers need to
consider accidental or deliberate potential DoS as a result? I
guess just saying to be careful with handling the
client-specified data as usual would be enough.

- On my discuss point 4: The closest I can get to an attack
based on this would be if the hash function used for the
Hash(handshake_messages) in the FINISHED calculation were
broken for collisions and if the request list were also used
by the server to pick a responder with which to check the
client cert in mutual authentication cases - that might allow
a chosen-prefix collision attack to get the server to use a
colluding OCSP responder, allowing replay of a TLS session
even after the client public key had been revoked.  That's
not very compelling in at least a few ways, but might suggest
something to someone cleverer than me;-)

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tls-multiple-cert-status-extension-04. 
Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We understand that, upon approval of this document, there are two actions which we must complete.

First in the ExtensionType Values subregistry of the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values

a single new Extension Type will be registered as follows:

Value: [ TBD-at-registration ]
Extension Name: status_request_v2
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the "TLS Certificate Status Types" registry and will be a subregistry of the Transport Layer Security (TLS) Extensions registry located at:

http://www.iana.org/assignments/tls-extensiontype-values

Maintenance of the new subregistry is done through IETF Review as defined in RFC 5226.

There are initial registrations in the new subregistry as follows:

Value Description Reference
1 ocsp [ RFC-to-be ]
2 ocsp_multi [ RFC-to-be ]

We understand these two actions to be the only ones 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.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The TLS Multiple Certificate Status Request Extension) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'The TLS Multiple Certificate Status Request 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 2013-03-29. 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


  This document defines the Transport Layer Security (TLS) Certificate
  Status Version 2 Extension to allow clients to specify and support
  multiple certificate status methods.  Also defined is a new method
  based on the Online Certificate Status Protocol (OCSP) that servers
  can use to provide status information not just about the server's own
  certificate, but also the status of intermediate certificates in the
  chain.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

The type of document is proposed standard. It provides a mechanism useful for the internet and represents working group consensus. The document indicates "Standards Track"

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
This document defines the Transport Layer Security (TLS) Certificate
Status Version 2 Extension to allow clients to specify and support
multiple certificate status methods. Also defined is a new method
based on the Online Certificate Status Protocol (OCSP) that servers
can use to provide status information not just about the server's own
certificate, but also the status of intermediate certificates in the
chain.

Working Group Summary:
In general working group consensus was smooth. There were no major sticking points

Document Quality:
There are a number of implementers who plan to implement this protocol extension.

Personnel:
Shepherd - Joe Salowey; AD - Sean turner

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read the document and run the I-D nits tool.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

THe document has be reviewed by members of the TLS working group that have expertise in TLS and OCSP.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes the author has confirmed this,

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR declaration has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

I would say that there is strong concurrence of a few individuals with a general support for the document

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

No nits

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

The document has a security considerations section

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document does not change the status of existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA Considerations are complete

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

New IANA registry is by IETF consensus

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

This document does not contain such sections.