Re: [TLS] draft-ietf-tls-cached-info-14

[Rob Stradling <[e-mail]>]

On 29/03/13 18:34, Hannes Tschofenig wrote:
> Hi Rob,
>
> I worked on a document update and the current snapshot can be found here:
> https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt
>
> Let me know if that fits your needs.

Hi Hannes.  You propose treating the entire CertificateStatus message as 
a single CachedObject, but I'd like to propose a finer-grained approach: 
treat each OCSP Response as a separate CachedObject.  Here's why...
   - A number of browsers/OSes already implement OCSP Response caches, 
and I think it'd make sense for these caches to be reusable in the 
context of Cached-Info.
   - It's common for OCSP Responses for Intermediate certificates to be 
valid for much longer than OCSP Responses for End-entity certificates. 
Also, it's common for clients to encounter multiple End-entity 
certificates issued by the same Intermediate certificate.  For these 
reasons, it will often be the case that a client has already cached the 
OCSP Response for the Intermediate(s) and will therefore only need the 
server to send the OCSP Response for the End-entity certificate.

Your draft already permits clients to send multiple CachedObject 
attributes of the same CachedInformationType, so I don't see any issues 
with the client->server part of my approach.

For the server->client part, the Multi-Stapling draft [1] already allows 
some of the OCSP Responses to be omitted...
   "Individual elements of the list MAY have a length of 0 (zero) bytes"
...although the rest of that sentence is problematic w.r.t. my approach:
   ", if the server does not have the OCSP response for that particular
    certificate stored, in which case, the client MUST act as if a
    response was not received for that particular certificate."

Also, the following paragraph in the Cached-Info draft is problematic 
w.r.t. my approach:
   "The server MUST NOT include more than one fingerprint for a single
    information element, i.e., at maximum only one CachedObject structure
    per replaced information is provided."

I realize that time is running out to get changes made to the 
Multi-Stapling draft before publication as an RFC, and I realize that my 
approach would make the Cached-Info draft more complicated.  However, I 
think it'd be worth the effort.

What does anybody else think?


[1] 
http://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/

> Ciao
> Hannes
>
> On Mar 28, 2013, at 11:23 PM, Rob Stradling wrote:
>
>> On 28/03/13 18:41, Hannes Tschofenig wrote:
>>> Hi Sean,
>>>
>>> It addresses all open issues we had at the IETF meeting.
>>>
>>> It does not yet contain the text for adding the OCSP response caching, as suggested by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html).
>>> I could propose some text by tomorrow since I believe it is useful functionality.
>>
>> Hannes,
>>
>> For Multi-Stapling, there will be cases where a TLS client has previously seen the OCSP Response(s) for the Intermediate(s) but not yet seen the OCSP Response for the End-entity cert.
>>
>> It would be useful in such cases if Cached-Info would enable the TLS server to only have to send the OCSP Response(s) that the TLS client hasn't previously cached.
>>
>>> Ciao
>>> Hannes
>>>
>>> On Mar 28, 2013, at 7:21 PM, Sean Turner wrote:
>>>
>>>> Does this version address all known outstanding issues?
>>>>
>>>> spt
>>>>
>>>> On 3/28/13 3:29 AM, Hannes Tschofenig wrote:
>>>>> Hi all,
>>>>>
>>>>> I just submitted an updated version of the TLS cached info document to incorporate the suggestions initially raised by Stefan in http://www.ietf.org/mail-archive/web/tls/current/msg09038.html, later discussed on the mailing list at http://www.ietf.org/mail-archive/web/tls/current/msg09253.html and also presented during the IETF#86 meeting.
>>>>>
>>>>> The updated document does not yet include the recently raised issue by Rob (see http://www.ietf.org/mail-archive/web/tls/current/msg09352.html).
>>>>>
>>>>> Ciao
>>>>> Hannes

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