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

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

Hello Sean,

Thanks for these comments.

Adopted most. Comments inline on the rest

On Mon, 09 Apr 2012 23:37:09 +0200, Sean Turner <[e-mail]> wrote:

> <no hat>
>
> Yngve,
>
> Here are some comments on the draft (hopefully this will encourage  
> others to also read it):
<snip>
> 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.

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.

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

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

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

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  
> references from 5246.

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

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

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  
> of RFC 2560?

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.

> 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

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?

> 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: [e-mail]
>> To: [e-mail]
>> 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
>>
>>


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************