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

Ralf Skyper Kaiser <> Tue, 05 November 2013 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 45A7D21E80B0 for <>; Tue, 5 Nov 2013 11:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.425
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p4lWDtPv15JR for <>; Tue, 5 Nov 2013 11:50:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c03::22b]) by (Postfix) with ESMTP id 7798011E812B for <>; Tue, 5 Nov 2013 11:49:36 -0800 (PST)
Received: by with SMTP id tp5so16238783ieb.30 for <>; Tue, 05 Nov 2013 11:49:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id mo20mr7869198icb.34.1383680970956; Tue, 05 Nov 2013 11:49:30 -0800 (PST)
Received: by with HTTP; Tue, 5 Nov 2013 11:49:30 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 5 Nov 2013 19:49:30 +0000
Message-ID: <>
From: Ralf Skyper Kaiser <>
To: Jeff Jarmoc <>
Content-Type: multipart/alternative; boundary=20cf300e4e51c2574404ea7354e5
Cc: "" <>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2013 19:51:09 -0000


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





On Tue, Nov 5, 2013 at 2:45 AM, Jeff Jarmoc <> 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 <> 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 <> 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 mailing list