Subject: Re: [TLS] comments on draft-ietf-tls-multiple-cert-status-extension-01

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 01 Oct 2012 13:46:33 +0200

Nikos Mavrogiannopoulos a écrit :
>>    A zero-length
>>    "responder_id_list" sequence has the special meaning that the
>>    responders are implicitly known to the server

> This is from RFC6066, but I think this text is only applicable to
> original intent of the ocsp extension, as an extension for constrained
> embedded clients. This is not valid generally, as most (if not all)
> browsers always send a zero-length responder_id_list irrespective of any
> prior arrangement with the server (there is none). The empty
> responder_id_list indicates that the client would accept the preferred
> by the server OCSP responder.

The *true* meaning of the current practice for browsers of sending a 
zero-length responder_id_list irrespective of any prior arrangement is 
that only the certificate of the CA that issued the certificate, or a 
OCSP certificate with a id-ad-ocspSigning extension will be accepted.

It would be best to find a way to remove the ambiguity of the 
zero-length responder_id_list value between "there's a prior 
arrangement, use the one defined by that" and "there's no prior 
arrangement, use a certificate that doesn't require one"
(this unfortunately applies just as well to RFC 6066).

If it can't be done, there should be a warning to implementors that in 
this situation, the responder should only use an OCSP signing 
certificate that requires a prior arrangement only in a closed 
environment/community, in other words if it knows by some out-of-band 
process that this client will accept it. And I think it would be best to 
have an errata for RFC 6066 that stipulates this.

---

From: Sean Turner <[email-masked]>
Date: Mon, 01 Oct 2012 12:34:44 -0400

Curious whether you think SCVP should stay or go?

spt

On 9/30/12 1:29 AM, Nikos Mavrogiannopoulos wrote:
> * Section 2.2:
> The document says:
> "In the OCSPStatusRequest and SCVPStatusRequest structures, the
>     "ResponderIDs" provide a list of OCSP and SCVP responders
>     (respectively) that the client trusts.  A zero-length
>     responders are implicitly known to the server, e.g., by prior
>     arrangement, or are identfied by the certificates used by the server."
>
> * same section:
> '"Extensions" is a DER encoding of OCSP request extensions.'
>
> I cannot understand the intent of the extensions. Is this field really
> required, or the draft could be simplified by removing it? My guess is
> that this is a relic of the original intention of the extension which
> assumed that the server would poll the ocsp server at the moment the
> client connected at his request. Are there any actual clients that use
> this field on the current RFC6066 extension?
>
> * same section:
>       struct {
>         OCSPResponse ocsp_response_list<1..2^24-1>
>       } OCSPResponseList
>
> there is a missing ';'
>
> * same section:
>     "Clients requesting a certificate response and receiving either one or
>     more OCSP responses or a SCVP response in a "CertificateStatus"
>     message MUST check the response(s) and abort the handshake, if the
>     response is a revoked status or is otherwise not satisfactory with a
>     bad_certificate_status_response(113) alert.  This alert is always
>     fatal."
>
> This text doesn't seem to belong in this section. There should be in a
> verification section or so. However my question is whether this text is
> applicable to this document at all. Is this document the proper place to
> define what to do when OCSP verification fails? If there is some TLS
> verification profile later that would like to set some verification
> rules, it risks violating the OCSP extension draft.
>
> I'd suggest, if you want to keep this text, to keep it pure
> informational without MUSTs or SHOULDs.
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 01 Oct 2012 20:24:50 +0200

> Curious whether you think SCVP should stay or go?

If you are asking me, I hardly know the protocol nor plan to implement
it in the near future, so I cannot judge its merits. I'd keep it if
there are people that plan to or already implemented this option, but I
would definitely remove it if there are none (it can be added in the
future anyway).

regards,
Nikos

---

From: Sean Turner <[email-masked]>
Date: Mon, 01 Oct 2012 14:29:26 -0400

> would definitely remove it if there are none (it can be added in the

At this point, I think I'm the only one who asked for it and I don't 
implement it and don't plan to.  I agree that if nobody else jumps up 
and down (and soon) that it ought to be removed.

spt

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 02 Oct 2012 10:51:21 +0200

On Sun, 30 Sep 2012 07:37:16 +0200, Nikos Mavrogiannopoulos  
<[email-masked]> wrote:

> btw. There are no suggested values for XX, YY, and AA. There cannot be
> interoperable implementation without some hint on these values.

That is intentional.

I have noticed that there are several cases of enums and ciphersuite  
values that have been made unallocatable because a draft and/or  
implementation have used them without going through channels first. I  
would rather avoid causing even more such waste.

It may well be that now that the document is a Work Group item that we can  
ask for values to be assigned, but I am not sure who should request them.  
In any case, as the SCVP case is not yet approved by consensus, I would  
not think it proper to assign a final value to its enum at this time.

What limited development and testing I have done have been done using the  
max values in each range as placeholders, rather than grabbing the  
smallest available value in the range.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 96 90 41 51              Fax:    +47 23 69 24 01
********************************************************************

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Tue, 02 Oct 2012 10:51:23 +0200

Hi,

Thanks for reviewing

> by the server OCSP responder.

Yes, it is from RFC 6066.

Having these options here, even if most (WebPKI) clients does not use  
them, allow specialized clients to use these parameters when they connect  
to servers that support them.

Just to be on the safe side: As far as I can tell, SCVP also have the same  
parameters in the protocol.

> this field on the current RFC6066 extension?

At present no, but one can envision customized clients that send a nonce  
extension and require it to be used in the response. (I seem to remember  
somebody at an IETF meeting mentioning that some high security networks  
use nonces in OCSP requests)

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

Thanks, will check that.

> informational without MUSTs or SHOULDs.

Please note that this language is also from RFC 6066 (section 8).

In my opinion, if there is no recommendation about what is good and bad  
responses and what to do in the bad case, then one risk interoperability  
problems and security issues due to the inconsistencies and different  
expectations.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 2 Oct 2012 11:26:33 +0200

On Tue, Oct 2, 2012 at 10:51 AM, Yngve Nysaeter Pettersen
<[email-masked]> wrote:

Hello,

> Having these options here, even if most (WebPKI) clients does not use them,
> allow specialized clients to use these parameters when they connect to
> servers that support them.

Yes, but the question is, are the such specialized clients that
warrant the added complexity in the protocol? Is there any existing or
planned use of this extension where the client will _not_ use the OCSP
server of the CA's certificate? The whole idea of the client
suggesting the OCSP is a bit absurd in the context of TLS since the
client cannot anyway ask a certificate from a particular CA. (I
understand it is not you that you created the RFC6066 status request
extension, my point is that you don't need to replicate the issues

> somebody at an IETF meeting mentioning that some high security networks use
> nonces in OCSP requests)

I'd suggest not to plan so far ahead. A TLS extension should solve a
problem that exists. You never know whether your solution for an
unknown future problem is correct. I'd suggest to allow the draft to
be extended with other (extended) status requests, but not solve
problems that do not yet exist. I don't think  that expecting the
server to contact the OCSP server on the fly on every client request
is practical on the scale of the Internet, not now at least. So we can
avoid this bloat until somebody really needs it.

> Please note that this language is also from RFC 6066 (section 8).

I wouldn't consider RFC6066 a model RFC. My comments apply to this RFC
as well (but it is already published).

> problems and security issues due to the inconsistencies and different

People have different expectations from different clients. There can
be clients that verify certificates and clients that do not. So there
can be clients that verify OCSP responses and clients that do not. Why
say that a client that does not verify an OCSP response not compliant
to the draft-ietf-tls-multiple-cert-status-extension-01?
Note that RFC5246 also doesn't mention how to verify certificates, nor
forces you to.

regards,
Nikos