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

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

Thanks Martin. That is really interesting information.
More inline.
> This is the theory.
> 
> In theory, theory and practice are the same, in practice, they differ.
> 
> Although the SSLv3 and *ALL* TLS specs have always been very clear that
the
> correct ording of certificates in the TLS Certificate handshake message is
a
> MUST requirement, as well as that only the self-signed rootCA cert at the
> end of the path may be omitted, a number of TLS implementations are
> notoriously broken in that they will send arbitrary garbled paths that may
> include alien certs and even expired certs in Certificate handshake
messages
> (rather than telling the server admin that the configuration is
incorrect).

[Piyush] Isn't it a tacit assumption for TLS cached objects that
certificate_list will be ordered. The question is if the broken
implementations can make use of these proposed extensions effectively and if
not then should we really care.
> 
> Although this is not even mentioned in the TLS spec, a number of SSL and
TLS
> clients will perform various hacks to accomodate for such broken TLS
server
> implementations, ranging from simple reordering of certificate, to the
> extreme of using only the very first certificate from the servers TLS
> Certificate handshake message, throw the remaining certificates into a
large
> pool of candidate path certificates and perform a full certificate path
> discovery.
[Piyush] So what would be the cached representation of such chains? The
original list that the server sent or the corrected ordered list that the
client created?
If it is the former, the client can still indicate the certificates for
which it needs the status through a list of Boolean values. If it is the
latter then server has no way to resolve the certificate_list cached object
and it will need to resend all the information again.
But a bigger question is how to create a spec without agreeing on a basic
set of assumptions. If the practices that you describe are useful, then they
should make their way to the TLS spec. If not we stop taking them into
account while designing new specs.
> 

> The latter can lead to seemingly non-deterministic behaviour with some TLS
> servers that omit more than the self-signed rootCA cert from the
Certificate
> handshake message, such as intermediate CA certs, and the client behaviour
> changes from handshake failure (untrusted cert) to successful handshake
> when that "large pool" of cached certs coincidentally contains the missing
> intermediate cert from a prior TLS handshake with a correctly configured
TLS
> Server whose server cert was issued by the same (intermediate) CA.
>
[Piyush]  A couple of points here:
1) We were basing this discussion assuming that server follows the TLS spec
correctly and provides all the required certificates in the correct order.
It was limited to client using OCSP responses from different sources and was
not about client using intermediate certificates from other sources.
2) Not relevant to the current discussion but still interesting. Why does it
matter whether the client obtained the intermediate certificate from the
same server, a different server, an ldap or http repository as long as it
can build the chain to a trusted root? I appreciate your point about server
not catching the error of it ways right away in case of handshake failure if
some clients are smart enough to perform certificate discovery.
 In fact allowing the server to just send its certificate without any issuer
certificates can actually optimize the TLS handshake if the client delegates
the path validation and discovery to an external DPV server.

> 
> I remember that in march 2001 "https://www.verisign.com" was sending and
> expired VeriSign rootCA certificate in the server certificate handshake
> message.  When I reported this defect to VeriSign Support, they did (at
least
> initially) not understand that this indicated (a) a defect (or at least
significant
> sloppiness) in their server's SSL/TLS implementation and (b) a server
> configuration errror.
> 
Again, this is very interesting information. Delivering root certificate and
that too expired one in TLS handshake is sloppy. I hope that the clients
were not sloppy enough to start using those as trust anchors. :)
Now that you mention it, it is probably a common practice for many x.509
applications. The assumption is that you are providing a bag of certificates
to the peer so that he can select the right ones to build a trusted path to
a pre-configured trust anchor. 
[Piyush] 
> -Martin