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

["Piyush Jain" <[e-mail]>]

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

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/