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

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

On Wed, 10 Apr 2013 16:45:34 +0200, Piyush Jain <[e-mail]>  
wrote:

>> 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.
> [Piyush] Not sure if I understood it correctly. TLS has strict  
> guidelines on

"Chain sequence" was maybe the wrong expression. The point was that the  
server can change to a completely new set of certificates, including an  
unrelated certificate authority.

However, some server can have certificates incorrectly ordered, and that  
might get fixed after a while (or it could get broken).

> sequence of certificates in the chain. The certificate chain sequence  
> would
> change only when the server certificate changes (or in some rare cases  
> when
> intermediate CA's certificate rolls over). Right? If that happens than
> certificate_list cached object held by the client would become invalid  
> and
> consequently any stapled responses associated with the old certificate  
> chain
> would also become invalid.

My point is that the information sent to the server about which resources  
are cached need to connect the resources to what the server have, in such  
a way that if the server configuration changes the server will know that  
it does not have the necessary information.

Since that require providing at least one hash that the server will know  
if it have that information, it could be that the boolean flags are  
unnecessary, because the server should also know that those entries are  
expired  or were missing, etc. based on its own information, if the  
indicated resource is known to the server.

> Let's make sure that we are on the same page regarding this before I  
> respond
> to your other points below, otherwise we'll get past each other because  
> we
> would be working off different set of assumptions.
>
>>
>> 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.
>> 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/
>


-- 
Sincerely,
Yngve N. Pettersen

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