Subject: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Apr 2013 06:54:36 -0600

Bert Greevenbosch and I have been selected as the joint Applications
Area Directorate reviewers for this draft (for background on AppsDir,
please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tls-multiple-cert-status-extension-05
Title: The TLS Multiple Certificate Status Request Extension
Reviewers: Bert Greevenbosch and Peter Saint-Andre
Review Date: 10 April 2013
IESG Telechat Date: 2013-04-11
Summary: This draft is almost ready for publication; comments raised
here are for the WG's consideration.

Major Issues:

none

Minor Issues:

(1) Maybe a server can maintain cached OCSP responses, e.g. until after
the "nextUpdate" time has expired. Then the server would be able to use
these cached responses instead of acquiring a new response from the
OCSP-responders. (This mechanism is e.g. defined in [OCSP-MP]). With the
new extension, multiple OCSP-responses from probably different OCSP
servers could be cached. The client needs to verify that each of the
OCSP response is still valid, e.g. that none of the OCSP-responses are
too old.

[OCSP-MP]: OMA Online Certificate Status Protocol (profile of [OCSP]) V
1.0, Open Mobile Alliance, URL:http://www.openmobilealliance.org/

Would some text about cached OCSP responses be appropriate? (Of course
nonces would make caching impossible, as each OCSP responder would need
to sign the new nonce.)

(2) Section 2.2, p.5:

   A zero-length "request_extensions" value means that there are no
   extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
   valid for the "Extensions" type).

This text was copied from RFC 6066. It seems a bit cryptic, but I
suppose it means that the "request_extensions" field does not exist at
all, e.g. the "OCSPStatusRequest" struct only contains the
"responder_id_list<0..2^16-1>"?

(3) Section 2.2, p.6:

   Note that a server MAY also choose not to send a "CertificateStatus"
   message, even if it has received a "status_request_v2" extension in
   the client hello message and has sent a "status_request_v2" extension
   in the server hello message.

In essence, this says that it is optional for the server to send the
"CertificateStatus" message. What are the types of conditions under
which it is reasonable to not send the "CertificateStatus" message?

(4) Section 2.2, p.7:

   If the client receives a
   "ocsp_response_list" that does not contain a response for one or more
   of the certificates in the completed certificate chain, the client
   SHOULD attempt to validate the certificate using an alternative
   retrieval method, such as downloading the relevant CRL;

Would this allow an attacker to downgrade the security of the
certificate, e.g. by disabling the OCSP response and using a stale CRL?

Maybe a "SHOULD" is not appropriate, but better leave it to the
particular trust model?

(5) Section 3. IANA Considerations. This section mentions a new registry
called "TLS Certificate Status Types", where CertificateStatusType
values should be registered. New values are assigned via IETF Review as
defined in RFC5226.

Should there be specific guidelines/required info for acceptance of new
values for this particular field? If so, state these guidelines/required
info.

Nits:

In Section 2:

   In the OCSPStatusRequest (originally defined by [RFC6066]), the
   "ResponderIDs" provides a list of OCSP responders that the client
   trusts.

- It seems that "ResponderIDs" should be "ResponderID".

Peter & Bert

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 10 Apr 2013 15:53:49 +0200

Hi Peter and Bert,

Thanks for the review.

> nonces would make caching impossible, as each OCSP responder would need

The server would not know if the client have cached the response, and the  
client would not know if there is a newer response held by the server.

The client could leave the request for certificate status out of the  
handshake, but that would mean that 1) it would not get any updated  
responses, and 2) if the serve changed its certificate(s) between the  
previous handshake and the current handshake, it would also not get the  
new responses, since it did not signal the willingness to receive them.

Resolving of that lack of information would require some kind of signaling  
mechanism, which I think is outside the scope of this particular document.

At present, discussion is underway in the TLS WG of adding such a  
mechanism to the draft-ietf-tls-cached-info  
<http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/>. If  
implemented, that would resolve the signaling mechanism problem, and  
combine it with a more general mechanism.

> "responder_id_list<0..2^16-1>"?

The record would still contain two zero bytes to indicate the length of  
the request_extensions vector (the length-field of the vector is not part  
of the content); the zerolength ASN1.1 SEQUENCE would require a  
non-zero-length request_extensions field since the field would contain a  
<SEQUENCE-indication + 0 byte length field> in ASN.1 DER encoding, which  
would likely be one or two bytes long.

> which it is reasonable to not send the "CertificateStatus" message?

The supporting server might not yet have downloaded an OCSP response. That  
is, for example, the case with nginx versions able to use RFC 6066 OCSP  
Stapling. Those servers also have a bug which makes them forward an  
expired OCSP response while they are fetching the new one, rather than  
discarding it.

In such cases the server can either wait until it receive the response  
(which might mean a long wait for the client if the responder is slow), or  
it can leave out the status message in connections it is establishing  
until it have received the OCSP response.

> Maybe a "SHOULD" is not appropriate, but better leave it to the

This would not reduce the security compared to the current environment.

CRLs (and OCSP) still have a validity period, and replay attacks using  
unexpired but out of date CRLs and OCSP responses is very much a  
possibility both via the stapling mechanism and via direct retrieval  
(require MITM).

IMO a malicious server is actually more likely to use an out of date OCSP  
response while it is valid, than to make the client fall back to the older  
methods. As I have mentioned elsewhere, this is why I would have preferred  
the stapled responses to have a freshness requirement of having to be  
generated with the last few hours. It is probably too late to do anything  
about that in the stapling specs, but CAs could reduce the validity  
periods to get the same effect.

Additionally, there are currently at least three different schemes used by  
clients: OCSP(site) + CRL (MSIE, Opera), OCSP (Firefox) and Out of band  
CRLsets (Chrome).

> values for this particular field? If so, state these guidelines/required

The text and requirements for this is similar to what is specified in RFC  
5246 for the ExtensionType registry

I am not sure how much formal guidelines we really need. I am open to  
suggestions.

However, the IETF Review do require quite a bit of checks, including  
AD-shepherding, IESG and WG/expert approval. That ought to reduce the  
possibility for spurious allocations to get through.

> - It seems that "ResponderIDs" should be "ResponderID".

Corrected

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Apr 2013 09:42:40 -0600

Hi Yngve!

On 4/10/13 7:53 AM, Yngve N. Pettersen wrote:
> Hi Peter and Bert,
> 
> Thanks for the review.
> 
> On Wed, 10 Apr 2013 14:54:36 +0200, Peter Saint-Andre 
> <[email-masked]> wrote:
> 
>> Bert Greevenbosch and I have been selected as the joint
>> Applications Area Directorate reviewers for this draft (for
>> background on AppsDir, please see ​ 
>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
>>
>> 
).
>> 
>> Please resolve these comments along with any other Last Call
>> comments you may receive. Please wait for direction from your
>> document shepherd or AD before posting a new version of the
>> draft.
>> 
>> Document: draft-ietf-tls-multiple-cert-status-extension-05 Title:
>> The TLS Multiple Certificate Status Request Extension Reviewers:
>> Bert Greevenbosch and Peter Saint-Andre Review Date: 10 April
>> 2013 IESG Telechat Date: 2013-04-11 Summary: This draft is almost
>> ready for publication; comments raised here are for the WG's
>> consideration.
>> 
>> Major Issues:
>> 
>> none
>> 
>> Minor Issues:
>> 
>> (1) Maybe a server can maintain cached OCSP responses, e.g. until
>> after the "nextUpdate" time has expired. Then the server would be
>> able to use these cached responses instead of acquiring a new
>> response from the OCSP-responders. (This mechanism is e.g.
>> defined in [OCSP-MP]). With the new extension, multiple
>> OCSP-responses from probably different OCSP servers could be
>> cached. The client needs to verify that each of the OCSP response
>> is still valid, e.g. that none of the OCSP-responses are too
>> old.
>> 
>> [OCSP-MP]: OMA Online Certificate Status Protocol (profile of
>> [OCSP]) V 1.0, Open Mobile Alliance,
>> URL:http://www.openmobilealliance.org/
>> 
>> Would some text about cached OCSP responses be appropriate? (Of
>> course nonces would make caching impossible, as each OCSP
>> responder would need to sign the new nonce.)
> 
> The server would not know if the client have cached the response,
> and the client would not know if there is a newer response held by
> the server.
> 
> The client could leave the request for certificate status out of
> the handshake, but that would mean that 1) it would not get any
> updated responses, and 2) if the serve changed its certificate(s)
> between the previous handshake and the current handshake, it would
> also not get the new responses, since it did not signal the
> willingness to receive them.
> 
> Resolving of that lack of information would require some kind of 
> signaling mechanism, which I think is outside the scope of this 
> particular document.
> 
> implemented, that would resolve the signaling mechanism problem,
> and combine it with a more general mechanism.

Thanks for the pointer to draft-ietf-tls-cached-info. I suppose that,
if implemented, it might lead to some changes in several TLS-related
specs, including this one. Correct?

>> extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is
>> not valid for the "Extensions" type).
>> 
>> This text was copied from RFC 6066. It seems a bit cryptic, but
>> I suppose it means that the "request_extensions" field does not
>> exist at all, e.g. the "OCSPStatusRequest" struct only contains
>> the "responder_id_list<0..2^16-1>"?
> 
> The record would still contain two zero bytes to indicate the
> length of the request_extensions vector (the length-field of the
> vector is not part of the content); the zerolength ASN1.1 SEQUENCE
> would require a non-zero-length request_extensions field since the
> field would contain a <SEQUENCE-indication + 0 byte length field>
> in ASN.1 DER encoding, which would likely be one or two bytes
> long.

Thanks for the clarification. Would it make sense to add a small note
to draft-ietf-tls-multiple-cert-status-extension on this point?

>> (3) Section 2.2, p.6:
>> 
>> Note that a server MAY also choose not to send a
>> "CertificateStatus" message, even if it has received a
>> "status_request_v2" extension in the client hello message and has
>> sent a "status_request_v2" extension in the server hello
>> message.
>> 
>> In essence, this says that it is optional for the server to send
>> the "CertificateStatus" message. What are the types of conditions
>> under which it is reasonable to not send the "CertificateStatus"
>> message?
> 
> The supporting server might not yet have downloaded an OCSP
> response. That is, for example, the case with nginx versions able
> to use RFC 6066 OCSP Stapling. Those servers also have a bug which
> makes them forward an expired OCSP response while they are fetching
> the new one, rather than discarding it.
> 
> In such cases the server can either wait until it receive the
> response (which might mean a long wait for the client if the
> responder is slow), or it can leave out the status message in
> connections it is establishing until it have received the OCSP
> response.

That makes sense. Explaining that in the spec might make sense, since
otherwise implementers might think there are other good reasons to not
send the "CertificateStatus" message.

>> (4) Section 2.2, p.7:
>> 
>> If the client receives a "ocsp_response_list" that does not
>> contain a response for one or more of the certificates in the
>> completed certificate chain, the client SHOULD attempt to
>> validate the certificate using an alternative retrieval method,
>> such as downloading the relevant CRL;
>> 
> CRLs (and OCSP) still have a validity period, and replay attacks
> using unexpired but out of date CRLs and OCSP responses is very
> much a possibility both via the stapling mechanism and via direct
> retrieval (require MITM).
> 
> IMO a malicious server is actually more likely to use an out of
> date OCSP response while it is valid, than to make the client fall
> back to the older methods. As I have mentioned elsewhere, this is
> why I would have preferred the stapled responses to have a
> freshness requirement of having to be generated with the last few
> hours. It is probably too late to do anything about that in the
> stapling specs, but CAs could reduce the validity periods to get
> the same effect.

OK by me. Bert, do you have any comments on this item?

> Additionally, there are currently at least three different schemes
> used by clients: OCSP(site) + CRL (MSIE, Opera), OCSP (Firefox) and
> Out of band CRLsets (Chrome).
> 
>> (5) Section 3. IANA Considerations. This section mentions a new
>> registry called "TLS Certificate Status Types", where
>> CertificateStatusType values should be registered. New values are
>> assigned via IETF Review as defined in RFC5226.
>> 
>> Should there be specific guidelines/required info for acceptance
>> of new values for this particular field? If so, state these
>> guidelines/required info.
> 
> The text and requirements for this is similar to what is specified
> in RFC 5246 for the ExtensionType registry
> 
> I am not sure how much formal guidelines we really need. I am open
> to suggestions.
> 
> However, the IETF Review do require quite a bit of checks,
> including AD-shepherding, IESG and WG/expert approval. That ought
> to reduce the possibility for spurious allocations to get through.

True.

>> "ResponderIDs" provides a list of OCSP responders that the
>> client trusts.
>> 

Thanks!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 10 Apr 2013 18:09:42 +0200

Hi,

On Wed, 10 Apr 2013 17:42:40 +0200, Peter Saint-Andre <[email-masked]>  
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Yngve!
>

To the extent that there are changes, those would be documented in the  
cached-info spec, and would depend on the granularity at which data are  
cached.

There would be no change for implementations that does not include  
cached-info, even if the other party does implement it. Any changes would  
only apply when both parties implement cached-info.

> to draft-ietf-tls-multiple-cert-status-extension on this point?

I am inclined to think it is not necessary, as I think the requirements  
are clear from the syntax, particularly the use of the "opaque" type.  
Implementors need to be familiar with both TLS record syntax in order to  
write the code, and the content would have to be generated by some ASN.1  
generator code.

Errors in the first would in particular quickly run into problems with  
other implementations (unless it happens in the first implementation and  
that implementation gains major marketshare before the problem is  
discovered; which have happened in SSL/TLS history at least twice IIRC).  
Given that this record is already used in RFC 6066 which is deployed by  
many clients and servers, and I assume the code for this structure will be  
reused, I don't think we are going to see a problem.

However, I did decide to add "DER-encoded" in front of "zero-length ASN.1  
SEQUENCE" to indicate that we are talking about a payload.

> send the "CertificateStatus" message.

However, a general reason for not sending the actual message is that the  
server might know that it can send the message, but does not discover  
until it is about to set up the message that it cannot send it.

One scenario is that the server does not know that its certificate(s) does  
not specify OCSP until it tries to get it. One could call that bad design,  
but it could also be based on reducing code complexity (e.g., don't  
involve the certificate parsing code when I am building the server hello)

-- 
Sincerely,
Yngve N. Pettersen