Re: [TLS] [pkix] New version of Multiple OCSP mode of Certificate

[Martin Rex <[e-mail]>]

Miller, Timothy J. wrote:
> 
> >As far as the AIA vulnerability is concerned, you're 0wnd as soon
> >as your software connects to the crafted URL in the crafted server
> >certificate.  It doesn't matter that whether you discard the reply
> >and abort the original browser connection at that point.  If you're
> >attacked, that URL is often not going to result in a certificate anyway.
> 
> First, real browsers already allow mixed content frames with silent
> renegotiation *and* late-binding of request authentication, and you're
> worried about exploiting AIA retrieval?

There is a significant difference between being vulnerable to a content
from a site one has chosen to access through HTTPS and being vulnerable
to an arbitrary active attacker on every connect.

> 
> Second, having identified a problem behavior, what's the fix?
> Path discovery is critically important in bridged PKIs, so if
> chasing AIAs is a Bad Thing, what do we do instead?

I don't know who invented the concept of automatic AIA retrieval, but
my personal intuition points to the S/Mime camp.  S/Mime is notoriously
broken as far as the inclusion of certificates is concerned (being a
heritage from PKCS#7).

SSL & TLS on the other hand have had the clear requirement to send only
complete certification chains from the beginning.  So there this issue
does not exist unless the server is misconfigured and the server PKI
software is defective because it does not refuse to perform SSL handshakes
with incomplete certificate chains, something that the SSL & TLS specs
have never allowed and which is fairly trivial for the server software,
the credential management part in particular, to verify and report
to the admin upfront when setting up that server.

> 
> >How about warning on first encounter and offer the User to download
> >and memorize the intermediate cert -- or to NOT download?
> 
> I fail to see how this improves the situation, since we already know
> users are ill-equipped to make these decisions anyway.


This is a clear TLS protocol violation, so if anything deserves
a scary page to be presented to a user, this is such a situation.

>
> In addition, components without a UI do what?

Fail unconditionally.  That is the only safe reaction, and since
it is a clear TLS protocol violation, it is quite appropriate.


> 
> >As previously described, the certificate path validation algorithm
> >specified in rfc-5280 works from the trust anchor downwards to
> >the End Entity cert, and will reliably protect you from accessing
> >OCSP or CRL information from untrusted/unverified certificates.
> 
> Only when the pool used by the PVM contains all the certificates
> identified in the path.  When the pool is incomplete, or the protocol
> provides no path (e.g., CMS allows SignedData to elide any and all
> certificates if the relying party can be expected to have *or discover*
> them), what does the PVM do?

S/Mime and CMS are foobar.  An implementation of TLS should not try
to work around design flaws of a non-TLS protocol in such an insecure
and questionable fashion.

The sitation for TLS is clear, the server needs to provide a full
certificate chain and may omit only the self-signed root.

There is more flexibility in the TLS protocol (although not explicitly
written out) for verifying the client certificate.  The CertificateRequest	handshake message includes a list of certification authorities which
the server indicates to trust (i.e. being able to verify certs issued
by these CAs), so the client could build a certificate chain up to
one of the certification authorities announced by the server.


PKIs with bridge CAs are not natively supported by TLS for the server
certificate.  Adding support would be possible through a ClientHello
extension where the client announces the names of those bridge CAs.

> 
> Failing is "safe" from a security standpoint, but I'd contend that
> if you put that into a real system it would simply fail to meet any
> practical definition of the term "functional."

AIA is a pretty dangerous idea designed to work around design flaws
of an installed base of PKCS#7/CMS/SMime.  Ignoring the security
implications of such a hack is a bad idea, in particular for protocols
that originally do not suffer from such a design flaw.  And doing it
in a secretive fashion out of sight from the user of the technology
is a particularly bad idea!


-Martin