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

Hi,

i mentioned earlier that this would not prevent dishonest clients (I am not
trying to achieve this). The goal is not to solve "the lying endpoint"
problem or re-invent trusted computing.

There are some applications which implement such a notification in the
application layer already. For example a web server can query a web-browser
if the browser is using 'Private Browsing' and if prevent the client from
using the web-site.

The user/browser can lie (but it would be to the disadvantage of the user).

As somebody else mentioned it's a flag that enables the server to prevent
accidental misconfiguration of a client - unless the user is dishonest - in
which case it is to the disadvantage of the user.

Maybe we need a real-life scenario:

You are better off wearing a seat-belt in a car. You might one day forget
to put on the seat belt (honest mistake!). So a mechanism that the car
warns you about it. Yes, you can cheat the car and pretend you put the
seat-belt on when you did not - but that's to your disadvantage.

Equally does it not mean that every time you do not wear a seat-belt  that
you will have an accident ('are attacked'...) (some people suggest this).

regards,

ralf

regards,

ralf

On Tue, Nov 5, 2013 at 2:45 AM, Jeff Jarmoc <jeff@jarmoc.com> wrote:

> And what prevents the client from setting the flag despite not checking?
>
> It's the client's responsibility to validate the server's identity (or
> not) to the extent it chooses to do so.  It's the server's responsibility
> to validate the client's identity (or not) to the extent it chooses to do
> so.
>
> Neither end can take on that responsibility for the other.
>
> On Nov 4, 2013, at 8:03 PM, Ralf Skyper Kaiser <skyper@thc.org> 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.
>
> 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 <mrex@sap.com> 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
>>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>