Subject: [TLS] draft-ietf-tls-multiple-cert-status-extension-04

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 28 Mar 2013 13:51:03 +0100 (CET)

Hi all,

I have looked at draft-ietf-tls-multiple-cert-status-extension-04 and have a few questions:

1) Shouldn't this document update RFC 6066 (or even obsolete functionality defined in Section 8 of RFC 6066)?

RFC 6066 defines a new extension, OCSPStatusRequest, to request the server to provide an OCSP response for the server certificate in the "CertificateStatus" message immediately after the "Certificate" message.

RFC 6066 defines the CertificateStatusRequest message as:

struct {

CertificateStatusType status_type;

select (status_type) {

case ocsp: OCSPStatusRequest;

} request;

} CertificateStatusRequest;

enum { ocsp(1), (255) } CertificateStatusType;

struct {

ResponderID responder_id_list<0..2^16-1>;

Extensions  request_extensions;

} OCSPStatusRequest;

opaque ResponderID<1..2^16-1>;

opaque Extensions<0..2^16-1>;

and the CertificateStatus message as:

struct {

CertificateStatusType status_type;

select (status_type) {

case ocsp: OCSPResponse;

} response;

} CertificateStatus;

opaque OCSPResponse<1..2^24-1>;

draft-ietf-tls-multiple-cert-status-extension-04 extends this mechanism to allow also OCSP responses for intermediate Certification Authority (CA) certificates.

draft-ietf-tls-multiple-cert-status-extension-04 defines the CertificateStatusRequestList message as an extension of the CertificateStatusRequest message:

struct {

CertificateStatusType status_type;

uint16 request_length; /* Length of request field in bytes */

select (status_type) {

case ocsp: OCSPStatusRequest;

case ocsp_multi: OCSPStatusRequest;

} request;

} CertificateStatusRequestItem;

enum { ocsp(1), ocsp_multi(2), (255) } CertificateStatusType;

struct {

ResponderID responder_id_list<0..2^16-1>;

Extensions request_extensions;

} OCSPStatusRequest;

opaque ResponderID<1..2^16-1>;

opaque Extensions<0..2^16-1>;

struct {

CertificateStatusRequestItem certificate_status_req_list<1..2^16-1>;

} CertificateStatusRequestList;

and the CertificateStatus message is defined as:

struct {

CertificateStatusType status_type;

select (status_type) {

case ocsp: OCSPResponse;

case ocsp_multi: OCSPResponseList;

} response;

} CertificateStatus;

opaque OCSPResponse<0..2^24-1>;

struct {

OCSPResponse ocsp_response_list<1..2^24-1>;

} OCSPResponseList;

Would you expect that someone uses RFC 6066 or would they instead use draft-ietf-tls-multiple-cert-status-extension-04 with respect to the OCSP procedure?

2) OCSP Usage

I have been told that browsers don't use OCSP (or CRLs) because it introduces too much latency. This extension would clearly improve the situation since no separate roundtrips are required. Everything is tunneled within TLS itself. However, browsers have in the meanwhile found other ways to handle revocation, namely by using blacklists shipped as part of the software update.

So, I am curious whether there are plans by anyone to use this OCSP TLS extension?

3) Replay Attacks (in context of TLS Cached Info)

Without the usage of OCSP nonces replays are possible. In particular, the TLS server could easily replay an earlier OSCP response (within the validity interval specified via the thisUpdate and nextUpdate fields). Section 11 of RFC 6066 talks about this issue but the usage of nonces prevent caching. Do I see this wrong?

4) OCSP Response Faking

Since the OCSP response is tunneled through the TLS server (which could potentionally be compromised) it must be ensured that the OCSP response is (a) signed and (b) it is signed by some party other than the TLS server (or a closely associated entity).

Neither RFC 6066 nor draft-ietf-tls-multiple-cert-status-extension-04 talk about this issue. Do I miss something?

Ciao

Hannes

PS: Many people use the term "OCSP stapling" for the functionality defined in RFC 6066 & draft-ietf-tls-multiple-cert-status-extension-04 but the term itself does not show up in these two documents. Wouldn't it be good to at least have it in the abstract of draft-ietf-tls-multiple-cert-status-extension-04?

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 28 Mar 2013 17:51:49 +0100

Hello Hannes

Thanks for the review.

1) Updating RFC 6066

It might be that it can be said to update 6066, but I have leaned towards  
that it is not updating 6066, since, while most of the new structures are  
derived from the 6066 definitions, they are really only defined for the  
new extension.

If RFC 6066 had only defined the OCSP stapling system, I would have been  
inclined to say my draft obsoleted it, but that is not workable since  
there are other extensions defined in it.

It could be that the update of the CertificateStatus message count as such  
an update, even if it is only defined for the new extension.

Do the Chairs or AD have any opinions on this?

> Would you expect that someone uses RFC 6066 or would they instead use  
> draft-ietf-tls-multiple-cert-status-extension-04
> with respect to the OCSP procedure?

In a transition phase I would expect clients to send both the 6066  
CertificateStatus request extension, and the new one defined by my draft.  
Long term I would expect a change to only using the new extension.

Servers supporting both should IMO return the new extension.

2) OCSP vs. Blacklists

The blacklists used by browsers are for emergency revocation, and do not  
scale very well (Updates require the CA to contact each browser, and each  
browser to add and test their updates, then ship the updates). They are  
not used for normal revocation, but for security incidents on the scale of  
the "Comodo" and "DigiNotar" incidents (CA failure), when nothing less  
will work.  In many cases updating the binary executable is needed to  
distribute the updated list, although some browsers use online data  
updates instead.

Most desktop browsers currently use OCSP (and support RFC 6066 stapling);  
I am unsure about mobile browsers (Opera does support it), and it was  
recently pointed out that Java was not checking revocation by default for  
signed applets.

The exception on the desktop side is Chrome, which is instead using  
Google's CRLSets download, built from CRLs, when stapling is not used; if  
the CRLset is too old it will AFAIK use OCSP instead. The reason for this  
change was the delays introduced by checking revocation. Personally I am  
skeptical to this approach, since the CRLsets are only supposed to include  
serious revocations, not general revocations.

Firefox is AFAIK using OCSP (and maybe CRLs) for intermediates when  
defined, but possibly only for EV certificates, although I am aware that  
NSS is in the process of being updated in this area.

CRLs are used by both Opera and (AFAIK) MSIE for intermediates, and at  
least in Opera's case, if OCSP is not defined for the site certificate the  
CRL will be used instead (when defined). (Opera also have special  
requirements for revocation success to be able to indicate the site as  
secure.)

The delay introduced by the online checking of revocation is one of the  
reasons a change to stapling is desirable. It is, however, also desirable  
to be able to check the revocation status of intermediates, since it is  
conceivable that intermediates can be revoked (as happened with the  
Malaysian CA in November 2011), and checking CRLs can introduce just as  
much delay as OCSP, which is why a multi-stapling spec was needed.

3) Replay attacks

There is no difference in the replay risk between CachedInfo and normal  
stapling (or with a MITM atatck on the OCSP server). A malicious server  
can send a valid (unexpired) OCSP response for the entire period it is  
valid, even if it has later been replaced by a newer response indicating  
revoked status.

This problem is why I am of the opinion that stapled OCSP responses should  
have a freshness requirement in the range of hours, even if the response  
is valid for a week. Alternatively, CAs can limit the lifetime of their  
responses to a few hours, which one CA have already done. However, I don't  
think the current draft is the right place for such a policy  
discussion/requirement.

The use of nonces would prevent replays, but almost no responders support  
them (I think the only ones I have heard about are military ones), and no  
current mass-market clients are AFAIK sending nonces or requiring them.

Also, using and requiring nonces would require the server to fetch new  
responses for each full  handshake, eliminating the primary benefits of  
stapling: Removing the latency, and that the number of requests to the  
responder depend on the number of subscribers, not the number of users of  
the subscribers' sites.

4) Faking

The OCSP response is always signed by the issuing CA, or a designated  
signer whose certificate is included in the response, not the server. I  
suspect the only way a site certificate could be able to sign a OCSP  
response for itself would be if it had somehow been issued with OCSP  
signer privileges, which would probably be reason enough to revoke the  
issuing CA certificate.

Therefore, faking the OCSP response is not a problem. The OCSP responses  
still have to follow the rules in RFC 2560.

5) Mentioning "OCSP stapling"

Will think about that. In the case of this draft, the concept is actually  
referred to as "Multi-stapling".

On Thu, 28 Mar 2013 13:51:03 +0100, Hannes Tschofenig  
<[email-masked]> wrote:

> Hi all,
>
> I have looked at draft-ietf-tls-multiple-cert-status-extension-04 and  
> have a few
> questions:
>
> 1) Shouldn't this document update RFC 6066 (or even obsolete  
> functionality
> defined in Section 8 of RFC 6066)?
>
> RFC 6066 defines a new extension, OCSPStatusRequest, to request the  
> server to
> provide an OCSP response for the server certificate in the  
> "CertificateStatus"
> message immediately after the "Certificate" message.
>
> draft-ietf-tls-multiple-cert-status-extension-04 extends this mechanism  
> to allow
> also OCSP responses for intermediate Certification Authority (CA)  
> certificates.
>
> draft-ietf-tls-multiple-cert-status-extension-04 defines the
> CertificateStatusRequestList message as an extension of the
> CertificateStatusRequest message:
>
> struct {
> Would you expect that someone uses RFC 6066 or would they instead use  
> draft-ietf-tls-multiple-cert-status-extension-04
> with respect to the OCSP procedure?
>
> 2) OCSP Usage
>
> I have been told that browsers don't use OCSP (or CRLs) because it  
> introduces
> too much latency. This extension would clearly improve the situation  
> since no
> separate roundtrips are required. Everything is tunneled within TLS  
> itself.
> However, browsers have in the meanwhile found other ways to handle  
> revocation,
> namely by using blacklists shipped as part of the software update.
>
> Without the usage of OCSP nonces replays are possible. In particular,  
> the TLS
> server could easily replay an earlier OSCP response (within the validity
> interval specified via the thisUpdate and nextUpdate fields). Section 11  
> of RFC
> 6066 talks about this issue but the usage of nonces prevent caching. Do  
> I see
> this wrong?
>
> 4) OCSP Response Faking
>
> Since the OCSP response is tunneled through the TLS server (which could
> potentionally be compromised) it must be ensured that the OCSP response  
> is (a)
> signed and (b) it is signed by some party other than the TLS server (or a
> closely associated entity).
>
> Neither RFC 6066 nor draft-ietf-tls-multiple-cert-status-extension-04  
> talk about
> this issue. Do I miss something?
>
> Ciao
> Hannes
>
> PS: Many people use the term "OCSP stapling" for the functionality  
> defined in
> RFC 6066 & draft-ietf-tls-multiple-cert-status-extension-04 but the term  
> itself
> does not show up in these two documents. Wouldn't it be good to at least  
> have it
> in the abstract of draft-ietf-tls-multiple-cert-status-extension-04?

-- 
Sincerely,
Yngve N. Pettersen

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 29 Mar 2013 08:37:22 -0400

On 3/28/13 12:51 PM, Yngve N. Pettersen wrote:
>
> Hello Hannes
>
> Thanks for the review.
>
> 1) Updating RFC 6066
>
> It might be that it can be said to update 6066, but I have leaned
> towards that it is not updating 6066, since, while most of the new
> structures are derived from the 6066 definitions, they are really only
> defined for the new extension.
>
> It could be that the update of the CertificateStatus message count as
> such an update, even if it is only defined for the new extension.
>
> CertificateStatus request extension, and the new one defined by my
> draft. Long term I would expect a change to only using the new extension.

If this is a new standalone extension, then it doesn't update RFC 6066. 
  In the past "updates" has sometimes been used as a "see also" tag, but 
that's now gently being stomped out.

> Servers supporting both should IMO return the new extension.

If you say this in the draft then I'd be leaning towards an update. 
That is if you changing behavior about an extension that's in 6066 it's 
an update.

spt

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Fri, 29 Mar 2013 16:09:45 +0100

> that's now gently being stomped out.

OK

> If you say this in the draft then I'd be leaning towards an update. That  
> is if you changing behavior about an extension that's in 6066 it's an  
> update.

I am not planning such language. I'll leave it up to implementors to make  
such decisions, but I also hope they will see the benefit of using the  
newer extension when it is presented.

-- 
Sincerely,
Yngve N. Pettersen