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

[Rob Stradling <[e-mail]>]

On 10/04/13 14:53, Yngve N. Pettersen wrote:
> Hi,
>
> Please keep in mind that the certificate chain sequence can be changed
> at any time. Any mechanism used would need to take that into consideration.

It can be changed at any time on the server side, but we're talking 
about the certificate chain sequence that the client received and cached 
at a particular point in time.

> Therefore, such a solution would have to link it to the fingerprint of
> the chain of stapled responses. However, once you provide that
> information you don't need a boolean value to indicate which responses
> you have and that are valid, because the server will already have that
> information.

Isn't this exactly what Hannes proposed a couple of weeks ago?

https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-15.txt

> It might be conceivable to link the information to the fingerprint of
> the certificate chain and then use the bools, but that would actually
> require (a few) more bytes on the wire than indicating the fingerprint
> of the stapled response list (although: one could get past that by
> linking the stapled list with the entry for cached certificates, but I
> think that would complicate matters more than is necessary to save a few
> bytes; particularly if the client for some reason is not caching the
> certificate chain).
>
> On Wed, 10 Apr 2013 15:41:20 +0200, Rob Stradling
> <[e-mail]> wrote:
>
>> On 09/04/13 23:52, Piyush Jain wrote:
>>> I'm having a basic problem understanding OCSPResponse cachedinfo
>>> object and
>>> the need to obtain the latest cert_status from the server.
>>>
>>> Why does a TLS client care if it has the same OCSP responses (for
>>> server and
>>> any intermediate certificate) as the TLS server, as long as it has some
>>> valid OCSP responses for those certificates? IMO, all the client
>>> cares about
>>> is the fact that it can build a valid status checked path to the locally
>>> configured trust anchor.
>>>
>>> So the only thing that the client needs to tell the server is the
>>> list of
>>> certificates for which it needs the status (either because the status
>>> in the
>>> cache expired or because it never got the status from this or other
>>> server).
>>> This can be communicated easily through a list of Boolean values. The
>>> position of the value corresponds to the position of certificate in the
>>> certificate chain and the value indicates if the client wants the
>>> server to
>>> include the status of corresponding cert.
>>> This makes the cached info object for OCSP responses much smaller
>>> compared
>>> to the representation that uses hash and also allows the clients to
>>> make use
>>> of locally cached OCSP responses irrespective of where they came from.
>>
>> Thanks Piyush.  I think that a "list of Boolean values" for requesting
>> cert statuses is a much better idea.  :-)
>>
>> When you say "The position of the value corresponds to the position of
>> certificate in the certificate chain", I presume you're referring to
>> the CachedObject(s) of type "certificate_chain" that the client sends.
>>
>> If a client were to send >1 CachedObjects of type "certificate_chain"
>> and >1 "list of Boolean values" CachedObjects, there could be
>> ambiguity over which "certificate_chain" is paired with which "list of
>> Boolean values".
>>
>> Would we simply say that the CachedObject(s) of these two types must
>> be sent in the same order?
>> Or would we need to squeeze the "list of Boolean values" into the
>> "certificate_chain" CachedObject type somehow?
>>
>>> -Piyush
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>>> Yngve N. Pettersen
>>>> Sent: Tuesday, April 09, 2013 2:00 PM
>>>> To: Rob Stradling
>>>> Cc: [e-mail]
>>>> Subject: Re: [TLS] draft-ietf-tls-cached-info-14
>>>>
>>>> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling
>>>> <[e-mail]> wrote:
>>>>
>>>>> On 08/04/13 21:07, Yngve N. Pettersen wrote:
>>>>> <snip>
>>>>>>> Example:
>>>>>>>     - Client visits https://www.google.com and
>>>>>>> https://mail.google.com, each for the first time ever, and caches
>>>>>>> the certificate chains and OCSP Responses for the End-entity and
>>>>>>> Intermediate certs.  Client observes that the same "Google Internet
>>>>>>> Authority" Intermediate is used in both cases.
>>>>>>>     - A while later, client performs another full handshake to
>>>>>>> https://www.google.com and gets back a different OCSP Response
>>>> (with
>>>>>>> a more recent thisUpdate value) for the same Intermediate cert.
>>>>>>>     - A while later, client performs another full handshake to
>>>>>>> https://mail.google.com.  It sends the CachedObject for the
>>>>>>> Intermediate OCSP Response that https://www.google.com just
>>>>>>> returned, because it knows that this OCSP Response is relevant for
>>>>>>> the Intermediate cert that https://mail.google.com used last time
>>>>>>> the client connected to it, and because this OCSP Response is the
>>>>>>> freshest one that the client has available.
>>>>>>
>>>>>> What about www.co.uk and bank.co.uk?
>>>>>>
>>>>>> Such things get complicated very fast, which is why we had to develop
>>>>>> the public suffix list.
>>>>>>
>>>>>> Please, let us stay way, way, *way* out of that particular thorny
>>>>>> area.
>>>>>
>>>>> If the End-entity certs at https://www.co.uk and https://bank.co.uk
>>>>> are both issued by the same Intermediate, then what's the problem?
>>>>> Why are the domain names even relevant when deciding whether or not
>>>>> it's "safe" for the client to send an Intermediate cert's OCSP
>>>>> Response that a different server provided?
>>>>
>>>> Tip: If domain names are irrelevant, make sure they do not carry
>>>> meaning
>>> in
>>>> the discussion, particularly when combined with the word "safe". Might
>>>> confuse things.
>>>>
>>>>> I agree that my proposal should be rejected _if_ the consensus is that
>>>>> it adds too much extra complexity.  But IMHO the more bytes on the
>>>>> wire we can save, the more chance there is that Multi-Stapling +
>>>>> Cached-Info will actually get deployed widely.
>>>>
>>>> The concept still assumes that server1 and server2 will have same
>>>> binary
>>>> response R for certificate X at time T, even if the client have
>>>> previously
>>> only
>>>> seen R from server1, and instead seen response S from server2.
>>>>
>>>> If, at time T both R and S are valid, but R is valid longer than S,
>>>> which
>>> should
>>>> be indicated to server2? If both, that means more (unnecessary)
>>>> bytes on
>>>> the wire, particularly if you have more than 2 servers (e.g. 200)
>>>> with the
>>> same
>>>> (issuer) certificate, each with binary different valid responses.
>>>>
>>>> What if the client indicates R to server2 and leaves out S, but server2
>>> does
>>>> not have R (and might get response Q if it requested an update)? Most
>>> likely
>>>> server2 would then resend response S. Result: unnecessary bytes on the
>>>> wire.
>>>>
>>>> Personally, I think it is better to assume that the OCSP responses
>>>> kept by
>>> two
>>>> servers are different, even if they are signed by the same issuer. It
>>> might be
>>>> that servers in different geographical areas connect to different OCSP
>>>> responders which have responses generated at different times (or who
>>>> generate on-the-fly responses).
>>>>
>>>> As mentioned above, the potential problems becomes even more
>>>> pronounced if you are dealing with hundreds or thousands of servers
>>>> (as we
>>>> would likely do with servers using Comodo issued certificates, for
>>> example).
>>>>
>>>> My advice: Keep cache lists for each server separate from the lists
>>>> used
>>> for
>>>> other servers. That does not mean that the client cannot optimize
>>>> storage
>>> by
>>>> combining the storage for each entry in the list, though. There is too
>>> much
>>>> chance of guessing wrong about what the server should know based on
>>>> what
>>>> the client knows.
>>>>
>>>> --
>>>> Sincerely,
>>>> Yngve N. Pettersen
>>>>
>>>> Using Opera's mail client: http://www.opera.com/mail/
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>
>
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.