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

["Yngve N. Pettersen" <[e-mail]>]

Hi Peter and Bert,

Thanks for the review.

On Wed, 10 Apr 2013 14:54:36 +0200, Peter Saint-Andre <[e-mail]>  
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.

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.

> (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>"?

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.

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

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

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

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

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

Corrected

-- 
Sincerely,
Yngve N. Pettersen

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