Re: [TLS] Summary of discussion regarding spontaneuous authentication

[Joseph Salowey <[e-mail]>]

On Wed, Oct 22, 2014 at 8:18 AM, Martin Rex <[e-mail]> wrote:

> Martin Thomson wrote:
> >
> > We discussed the removal of the CertificateRequest and we will permit
> > the client to unilaterally send authentication.
> >
> > The theory here is that clients tend to know whether they need to
> > authenticate.
>
> This looks like a bad idea to me.
> The by far most important information in the current CertificateRequest
> handshake message is the "certification_authorities" field, which indicates
> certificate issuers which the server considers acceptable.
> In SSLv3 and TLSv1.0 the certificate_authorities field was required
> to be non-empty and no (server) behaviour was defined for the meaning
> of an empty certification_authorities field in CertificateRequest.
>
> The TLSv1.1 and TLSv1.2 specification contain a defect in that they
> modified the PDU definition to allow an empty certification_authorities
> field in CertificateRequest, but failed to define (require) a server
> behaviour when the server does not send this information.
> Without the requirement, that the serer MUST NOT abort the TLS handshake
> when sending an empty certificate_authorities and receiving a certificate
> which it does not trust, the use of an empty certificate_authorities
> field does not make sense.
>
>
> With recent versions of Lync, Microsoft seems to automatically create a
> Lync-specific "SSL client identity" that works for nothing but Lync, but
> will successfully interfere with SSL client credentials selections when
> browsers are using an SSL client identity for accessing regular Web sites.
>
> To make SSL client certificate authentication work reasonably
> a CertificateRequest that conveys acceptable certificate_authorities
> for the specific handshake is absolutely necessary.
>
> Apple Safari seems to be notoriously broken when it comes to SSL client
> certificate selection, because it fails to process the
> certificate_authorities
> field from a CertificateRequest handshake message and remove obviously
> unacceptable certs from the list of credentials that the user is
> presented to select from.   I've had customers report connection
> failures to our AppServers, and from the server-side error messages
> I could see that the client was trying to connect with some appleid
> certificate that our server didn't trust (and certainly never announced
> in the CertificateRequest.certificate_authorities field.
>
> Microsoft had a similar problem in WinHTTP in 2005
> http://support.microsoft.com/kb/909425/en
>
> After WinHTTP was fixed to provide the necessary information
> to application callers, it is still necessary for application callers
> to actually _use_ that information to select only acceptable certificates,
> and that seems to take years to happen.
> This is the fix for Office/WebDAV:
> http://support.microsoft.com/kb/2647954/en
>
> And Apple Safari 4 Windows also still has this bug today.
>
>
> With the certificate_authorities field in the current CertificateRequest
> handshake message, these are only (fixable) bugs.  With the removal
> of the CertificateRequest handshake message, this problem would be
> promoted to a TLSv1.3 protocol design flaw, and become unfixable.
>
>
[Joe]  I'm also concerned that removing the certificate request in favor of
some application indication will leave behind applications that do not
currently have a mechanism to communicate this.   If we are going to remove
the certificate request I think we will need to communicate this
information in the handshake itself or perhaps have a "reconnection
request".




>
> -Martin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>