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

Ralf Skyper Kaiser <skyper@thc.org> Tue, 05 November 2013 19:50 UTC

Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A7D21E80B0 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 11:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level:
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4lWDtPv15JR for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 11:50:27 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7798011E812B for <tls@ietf.org>; Tue, 5 Nov 2013 11:49:36 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id tp5so16238783ieb.30 for <tls@ietf.org>; Tue, 05 Nov 2013 11:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x4wfIvaHj/wLW7B72Y9i/+9yk46jiZMJXzL1BhwR0y8=; b=WT0a/Cp6fQB5ZDekfWX8OPQK+nbfzbWCe1LmEqgudEw0fYHbZypLWItvQoRsCpihtC cFDe2PXDh2NaqbaEtxpGFPgX1MfVsETh2AwPxDrELXof+RSFtQQVVHrVwlRIRFv1vCKo 9QJ2fgWtFU0KXQ7hdr3EyZUS8MkEuSgdwA62g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=x4wfIvaHj/wLW7B72Y9i/+9yk46jiZMJXzL1BhwR0y8=; b=k9ycPfRRm4qI7j9VYyi2tPaI8/h6ZR4wFbiKf+J9j7UQ+xgk0koo638PZ/2weQnvlE ytJcNNr3nt7iaG7vtrhdck1SwVj8HSwNj764RRoveo5yF+2TzbWHKKj4zy99l0AYdCsB Sq1wsXag+ep4HS8aTTHhJldcwX3QYXWGrPhKKzweUraupPF8wjqOeHlXXOgT8UOkm0V5 bEg1eWxHdiQRyo/Tcu23nMREX4kQJPLkB06rKciVyzo8vLO/kdJXvUaMTykVHiwHtJKl H46kmldVsTMWzPBZtKOy8BHwGTKlIHQ5DTtp99pDQlF2WYSko4Siuo6tB2jK+UEvfM5p Jarw==
X-Gm-Message-State: ALoCoQm3kBX/7mlHbBH8GjgdLPllqNw+2AEWce5YkLf/Cdg02KyZ6/QyHVP/l+/Nha+62uDwPHTj
MIME-Version: 1.0
X-Received: by 10.42.250.148 with SMTP id mo20mr7869198icb.34.1383680970956; Tue, 05 Nov 2013 11:49:30 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Tue, 5 Nov 2013 11:49:30 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com> <EF5EE024-DBDE-4D7E-B4DC-8A9E6C603E2F@jarmoc.com>
Date: Tue, 5 Nov 2013 19:49:30 +0000
Message-ID: <CA+BZK2qgqAA7=7_aTw6A=ounnkK9pvRyNA0FoJmd51U+qTrLKQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Jeff Jarmoc <jeff@jarmoc.com>
Content-Type: multipart/alternative; boundary=20cf300e4e51c2574404ea7354e5
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 19:51:09 -0000

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