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

[Nico Williams <[e-mail]>]

On Mon, Nov 4, 2013 at 8:03 PM, Ralf Skyper Kaiser <[e-mail]> wrote:
> 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.

What are you talking about?  Of course the client and server (and CAs,
and...) can all cheat on *themselves*.  But the whole point of
verifying some other party's certificate is to protect yourself.  The
client (unless it's a dumb, dumb client) is going to do check the
server's cert.

> 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.

Yes, it'd be nice if XMPP clients had a
leap-of-faith/trust-on-first-use option.  That has nothing to do with
this thread unless you're proposing a different method of
authenticating servers.

> A securely configured TLS client would verify the certificate chain.

I know right?  So that's a bug in the client.  Nothing wrong with TLS
itself.  (Well, the PKIX bits are not trivial, and that has to do with
why some clients get things wrong, but surely you're not proposing
replacing the PKIX bits.)

> The server has no way to check if the TLS client is configured securely. The

And vice-versa.  Of course.

> 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.

Ah!  You want a secure bit.  Like RFC3514 (note the publication date).
 It doesn't work.

Nico
--