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

["Miller, Timothy J." <[e-mail]>]

See my other message.  The problem here is TLS does not admit of PKIs with more complex pathing requirements or inter-relationships.

-- Tim


>-----Original Message-----
>From: Martin Rex [mailto:[e-mail]]
>Sent: Wednesday, August 04, 2010 2:59 PM
>To: Miller, Timothy J.
>Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
>Subject: Re: [pkix] [TLS] New version of Multiple OCSP mode of
>Certificate
>
>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