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

[Rob Stradling <[e-mail]>]

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