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

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
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 
> <[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.

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.

True.

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

Thanks!

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRZYhwAAoJEOoGpJErxa2pcvoP/Rl6n9dx9PnTrcp9u7Eji/pB
zeiiz8zMpUjC/Y5nyRoqZ5crXJqoJfRBzV7AClHUrtUW3anDZpCQSPiAh8fBPDQN
s3MmTlo5B5r2eaYCIGFQzfGlPPiKt2SrBOwlXICZG+hoPgQTPTCrrHdmi0g3fVpj
K7JzOsyOezNbOLQE37jw7yvbDvTk//Js/aJEjzzxLzgtB+hR9IzEynqfVlj4E4J7
wv9E73zuH5BpA7ckEstasMD0kYpuwh+lw5LtVYKzAmwdyVhcYPb/atUO04W+6+qc
+xZ8B6lye1Q8JDK50qQcgnbmC+hbLd46tSQnhwbkeN3RgfWvgGVRI59znD5IGrAE
mWLf6yjarqUADzo6s1tzYGItGFj/CASrOZUe9T/136/pdrXhIRmWhyfF1IhykXNb
0biDpBlxokW6WonLFHxnqnJi/Otm+BlQx7AyEWNlwNf29YrkpofrtVRnjfEmMKOJ
h+wj9Tb8Mk9Xzm5We2GZIwClJp8kLVwQ0h+YDejYLYwE1yDlLS7O76btp1fgzvYZ
km78rFh+1i54cPXnd6JzzlLJJxmjDVqonQsFCD6+I6iwYRw8bK3F1AHT6Wne/NJw
q3a9jLzSxYtJM2/lmwTDDRK0AcanmIOPQpi/NzzWF3Z9+clhUi/E08DzGMcB5xnc
qGdCKHN+axpzC6JK3xOZ
=+2Rt
-----END PGP SIGNATURE-----