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

Peter Saint-Andre <> Wed, 10 April 2013 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6137021F9754; Wed, 10 Apr 2013 08:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mE5JGALMFTok; Wed, 10 Apr 2013 08:42:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A59DB21F93D6; Wed, 10 Apr 2013 08:42:46 -0700 (PDT)
Received: from [] (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id C963A40E4B; Wed, 10 Apr 2013 09:52:50 -0600 (MDT)
Message-ID: <>
Date: Wed, 10 Apr 2013 09:42:40 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Yngve N. Pettersen" <>
References: <> <op.wvbvjzd83dfyax@killashandra.invalid.invalid>
In-Reply-To: <op.wvbvjzd83dfyax@killashandra.invalid.invalid>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc:, The IESG <>, "" <>
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Apr 2013 15:42:50 -0000

Hash: SHA1

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 
> <> wrote:
>> Bert Greevenbosch and I have been selected as the joint
>> Applications Area Directorate reviewers for this draft (for
>> background on AppsDir, please see ​ 
>> 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:
>> 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 
> <>. If 
> 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?

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

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

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.


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



- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird -