Re: [TLS] What would make TLS cryptographically better for TLS 1.3

[Ralf Skyper Kaiser <[e-mail]>]

Hi Martin,

exactly, and that's the problem: "What policy the client applies when
checking the server's certificate chain is at the discretion of the client."

There is no easy way to solve this. The client (and user) can always cheat
if he wants to. But we are not discussing dishonest users. Let's assume a
honest user who wants to connect to a TLS service securely.

The user uses a TLS client (say pidgin for jabber). This client has several
options to configure the TLS connection. These options include if the chain
should be checked at all, if the user is allowed to accept self-signed
certificates and against which CA-bundle to verify the server's certificate.

A securely configured TLS client would verify the certificate chain.

The server has no way to check if the TLS client is configured securely.
The server blindly trusts the client that it is configured securely. That
does not scale. Users make mistakes. Users will connect to a service not
knowing that the connection is not secure (even over TLS) because they did
not configure the TLS correctly.

A flag that would tell the server how the client has verified the
connection would enable the server to block the user from using the service
UNTIL his client is configured securely.

Tata. Better security.

regards,

ralf



On Tue, Nov 5, 2013 at 12:36 AM, Martin Rex <[e-mail]> wrote:

> Ralf Skyper Kaiser wrote:
> >
> > (An example are jabber servers using TLS. Most clients allow the user to
> > accept any server certificate without verification. The jabber server has
> > no way to detect which client performed proper certificate verification
> and
> > CN<>URI match).
>
> Huh?
>
> What policy the client applies when checking the server's certificate
> chain is none of the server's business.  This is entirely at the
> discretion of the client.
>
> -Martin
>