Subject: Re: [TLS] Fwd: New Version Notification for draft-pettersen-tls-ext-multiple-ocsp-03.txt

From: Sean Turner <[email-masked]>
Date: Mon, 09 Apr 2012 17:37:09 -0400

<no hat>

Yngve,

Here are some comments on the draft (hopefully this will encourage 
others to also read it):

1. The Abstract contains the following:

  This document introduces a replacement of the TLS Certificate Status
  Extension to allow clients to specify and support multiple
  certificate status methods.

I know somebody will get to the word "replacement" and start asking 
whether this draft should update 6066.  I don't think that's the intent 
you're just defining a new extension so it should just say that:

  This document defines the TLS Certificate Status Version 2
  Extension to allow clients to specify and support multiple
  certificate status methods.

2. Abstract: Expand OCSP and TLS.

3. Abstract: r/Also being introduced/Also defined

4. The RFC editor will move the "requirements language" paragraph to the 
main body so you might as well do it now.  Move it to s1.1.

5. The copy right notice section contains the pre-5378 paragraph, but 
the draft first appeared after 5378 was published.  Is there some bits 
in here that are copied from 5246 or somewhere else?  If not, then you 
can delete that para.

6. s1: r/Transport Layer Security/Transport Layer Security (TLS)

7. s1: I don't think you need to try to slip in the comparison to other 
methods.  I think it's implied.

OLD:

  The benefits of this extension include a reduced number
  of roundtrips and network delays for the client to verify the status
  of the server's certificate using other retrieval methods and a
  reduced load on the certificate issuer's status response servers,
  thus solving a problem that can become significant when the issued
  certificate is presented by a frequently visited server.

NEW:

  The benefits of this extension include a reduced number
  of roundtrips and network delays for the client to verify the status
  of the server's certificate and a
  reduced load on the certificate issuer's status response servers,
  thus solving a problem that can become significant when the issued
  certificate is presented by a frequently visited server.

8. s1: wordy ;)

OLD:

  There are two problems with the existing Certificate Status extension
  as it is currently defined.

NEW:

  There are two problems with the existing Certificate Status extension.

9. s1: Just some tweaking (two whichs read a little odd):

OLD:

  First, it does not provide functionality
  to request the status information about intermediate CA certificates,
  which means the client has to request this through other retrieval
  methods, such as CRLs, which can cause significant delays when the
  revocation list has to be refreshed.

NEW:

  First, it does not provide functionality
  to request the status information about intermediate Certification
  Authority (CA) certificates,
  which means the client has to request status information through other
  methods, such as CRLs, thus adding additional delay.

10. s1: r/Certificate Authorities/Certification Authorities X2

11. s1: r/Point[RFC5280]/Point [RFC5280]

12. s1: In the following I think the point is just for client-cached 
CRLS because most that responders I know about are fed by a CRL.

OLD:

  Given
  that CRLs, particularly those cached by the client, are frequently
  less up to date than is possible for an OCSP responder, using OCSP to
  access up-to-date status information about intermediate CA
  certificates will be of great benefit to clients.

NEW:

  Given
  that client-cached CRLs are frequently out of date, using OCSP to
  access up-to-date status information about intermediate CA
  certificates will be of great benefit to clients.

13. s1: I guess I'd tweak the following a bit:

OLD:

  The author is aware that the cost of providing this bandwidth
  just for site certificates has been a concern to some CAs,
  particularly the smaller ones, and it follows naturally that doubling
  or tripling this cost could be problematic for the CAs.  The author
  is also aware of at least one case when OCSP requests for a single
  high-traffic site caused significant network problems for the issuing
  CA.

NEW:

  CAs should be aware that there is a cost associated with providing
  bandwidth to support OCSP.  There are cases where OCSP requests for a
  single
  high-traffic site caused significant network problems for the issuing
  CA.

14. s1: r/multiple, OCSP mode/multiple-OCSP method

15. s2.1: r/The extension added by this/The extension defined by this

16.: s2.1: Just trying to avoid the questions about whether this draft 
updates 6066: r/which is updated with this value/which uses the 
following value

17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is the 
other status protocol.  Should we just add it now?

18. s2.2: Need a normative reference for DER.  Use the x680/x690 
references from 5246.

19. s2.2: The nonce extension encoding is being fixed.  I sure hope 
it'll get done sooner rather than later.  Note that the bis draft does 
define the encoding as an OCTET STRING so it's aligned.

20. Hmmm should this draft reference draft-ietf-pkix-rfc2560bis instead 
of RFC 2560?

21. s2.2: r/[RFC2560]) ./[RFC2560]).

22. s2.2: r/that is,/That is,

23. s.2.2: Why the MUST NOT here:

  The list MAY
  contain fewer OCSP responses than there were certificates in the
  Certificate handshake message, but there MUST NOT be more responses
  than there were certificates in the list

spt

</no hat>

On 3/6/12 8:01 AM, Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>
> FYI
>
> <http://www.ietf.org/id/draft-pettersen-tls-ext-multiple-ocsp-03.txt>
>
> ------- Forwarded message -------
> From: [email-masked]
> To: [email-masked]
> Cc:
> Subject: New Version Notification for
> draft-pettersen-tls-ext-multiple-ocsp-03.txt
> Date: Tue, 06 Mar 2012 13:49:50 +0100
>
> A new version of I-D, draft-pettersen-tls-ext-multiple-ocsp-03.txt has
> been successfully submitted by Yngve N. Pettersen and posted to the IETF
> repository.
>
> Filename: draft-pettersen-tls-ext-multiple-ocsp
> Revision: 03
> Title: Adding Multiple TLS Certificate Status Extension requests
> Creation date: 2012-03-06
> WG ID: Individual Submission
> Number of pages: 9
>
> Abstract:
> This document introduces a replacement of the TLS Certificate Status
> Extension to allow clients to specify and support multiple
> certificate status methods. Also being introduced is a new OCSP-
> based method that servers can use to provide status information not
> just about the server&#39;s own certificate, but also the status of
> intermediate certificates in the chain.
>
>
>
>
>
> The IETF Secretariat
>
>

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 11 Apr 2012 16:20:14 +0200

Hello Sean,

Thanks for these comments.

Adopted most. Comments inline on the rest

> Here are some comments on the draft (hopefully this will encourage  
<snip>
> main body so you might as well do it now.  Move it to s1.1.

The placement of that section is the default used by the xml2rfc template  
implemented by the XMLmind extension, as part of the "front matter"  
section of the file. This means that the initial location is determined by  
the template, and is that way for everyone using that template.

non-WG: It might be that the xml2rfc extension developers and the RFC  
Editor should coordinate?  Since the "empty" template already adds several  
sections, such as the Introduction and IANA sections, moving the note into  
the introduction section of the template might solve the issue.

At present I'll leave it where it is.

> in here that are copied from 5246 or somewhere else?  If not, then you  

The text is based on the relevant RFC 6066 text (taken from the draft),  
but that RFC is again based on RFC 4366, with only a few differences in  
that section. RFC 6066 also contain the same pre-5378 licensing language,  
so I therefore think it is necessary to include it, unless I am told  
otherwise by those better versed in the licensing rules.

<snip>
>   high-traffic site caused significant network problems for the issuing

My intention here was to make it clear who the source is.

In talks with CAs the bandwidth cost have been a concern for several CAs,  
particularly the smaller ones.

I forgot to mention this during my presentation to the WG, but recent  
numbers from CAs indicate that about 30% of the OCSP traffic is for  
intermediate CA cert status requests. There are currently two clients  
AFAIK, FF and Chrome, that request OCSP for intermediates. Those two make  
up about 40% of the browser market, so there is at least some caching  
benefit.

I changed the text from

    The benefit to the
    issuing CA is less clear, as providing the bandwidth for the OCSP
    responder can be costly, especially for CAs with many subscriber
    sites.  The author is aware that the cost of providing this bandwidth
    just for site certificates has been a concern to some CAs,
    particularly the smaller ones, and it follows naturally that doubling
    or tripling this cost could be problematic for the CAs.  The author
    is also aware of at least one case when OCSP requests for a single
    high-traffic site caused significant network problems for the issuing
    CA.

to

   The benefit to the issuing CA is less clear, as providing the bandwidth
   for the OCSP responder can be costly, especially for CAs with many high
   traffic subscriber sites, and this cost is a concern for many CAs. There
   are cases where OCSP requests for a single high-traffic site caused
   significant network problems for the issuing CA.

How does that look?

<snip>
> other status protocol.  Should we just add it now?

Could be; I am, however, unfamiliar with SCVP, but if the WG wants it  
added, and I am provided additional text as a starting point, then I can  
include it. Adding SCVP will probably require some editorial  
reorganization of section 2, splitting it into an overall format, an OCSP,  
and a SVCP subsection.

> 18. s2.2: Need a normative reference for DER.  Use the x680/x690  

Added. The "misc" citation entry had rather long names, though:  
CCITT.X680.2002

> define the encoding as an OCTET STRING so it's aligned.

Given performance issues, as a nonce require signing of each response,  
most responders do not AFAIK enable support for nonces, and while Opera  
supported it at one time, we have since removed it. In relation to  
stapling using nonces would almost certainly remove most of the  
performance benefit.

> 20. Hmmm should this draft reference draft-ietf-pkix-rfc2560bis instead  

Depends on which get finished first. At present I think we should keep  
them separate, just to be on the safe side. If 2560bis is completed first  
we can update the reference then.

>   than there were certificates in the list

Strictly speaking it does not need to be MUST NOT, but I suspect that in  
such a case there would be something wrong about the server configuration.

AT the very least, the document should define handling of such a case

It could be changed to a requirement that the response must only be used  
to check the corresponding certificate list element, and ignore responses  
that does not have a corresponding certificate in the list. Requiring the  
sequence of the lists to match means that if certificate lists that are  
non-compliant, containing extra or unordered certificates, the client does  
not have to try to match responses to certificates (an n^2 operation).

Thoughts?

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

---

From: Rob Stradling <[email-masked]>
Date: Wed, 11 Apr 2012 15:41:06 +0100

On 11/04/12 15:20, Yngve N. Pettersen (Developer Opera Software ASA) wrote:
<snip>
> <snip>
>> 17. s2.2: So OCSP is definitely used a lot more than SCVP, but it is
>> the other status protocol. Should we just add it now?
>
> reorganization of section 2, splitting it into an overall format, an
> OCSP, and a SVCP subsection.

Hi Yngve.  Would an implementer be permitted to implement the OCSP 
option but not the SCVP option (or vice versa)?

My suggestion: Implementations MUST support the OCSP option, and MAY 
also support the SCVP option.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Wed, 11 Apr 2012 17:40:16 +0200

> option but not the SCVP option (or vice versa)?

In the spec? It should be optional to implement it, so it should be  
prented as an additional method that may be sent.

AFAICT, OpenSSL 1.0.0 does not currently have any support for SCVP.

Adding the possibility would, however, improve testing of the  
extensibility of the extension.

> also support the SCVP option.

Agree.