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

["Yngve N. Pettersen" <[e-mail]>]

On Wed, 10 Apr 2013 16:21:47 +0200, Rob Stradling  
<[e-mail]> wrote:

> 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

In this case I am talking about the boolean flag proposal and how it would  
indicate to a server which responses it have, and particularly how to  
avoid confusion when/if the certificate chain is updated by the server.

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


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/