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

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.

-Piyush

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Yngve N. Pettersen
> Sent: Tuesday, April 09, 2013 2:00 PM
> To: Rob Stradling
> Cc: tls@ietf.org
> Subject: Re: [TLS] draft-ietf-tls-cached-info-14
> 
> On Tue, 09 Apr 2013 21:07:53 +0200, Rob Stradling
> <rob.stradling@comodo.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls