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

Johannes Merkle <> Tue, 05 November 2013 13:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18C6211E81F3 for <>; Tue, 5 Nov 2013 05:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.538
X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p+rQZZ6iNfdn for <>; Tue, 5 Nov 2013 05:18:52 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0C29311E8167 for <>; Tue, 5 Nov 2013 05:18:50 -0800 (PST)
Received: from localhost (alg1 []) by (Postfix) with ESMTP id CAE9A1A0075; Tue, 5 Nov 2013 14:18:47 +0100 (CET)
X-Virus-Scanned: by secunet
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id 7ofSroQi8qqy; Tue, 5 Nov 2013 14:18:46 +0100 (CET)
Received: from (unknown []) by (Postfix) with ESMTP id B2A271A0071; Tue, 5 Nov 2013 14:18:44 +0100 (CET)
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Nov 2013 14:18:44 +0100
Message-ID: <>
Date: Tue, 05 Nov 2013 14:18:49 +0100
From: Johannes Merkle <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Ralf Skyper Kaiser <>,
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Nov 2013 13:18:44.0917 (UTC) FILETIME=[8DE0FE50:01CEDA29]
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 13:19:04 -0000

Ralf Skyper Kaiser schrieb am 05.11.2013 03:03:
> 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.

I don't see the point. You are referring to a verification of the server's certificate by the client.
When a client identifies a server, what is the benefit for the server to ensure that the client performs the
identification in a proper way?

If the verification is not done properly by the client, the client may be susceptible to impersonation attacks on the
server side, i.e. may trust a malicious server pretending to be the honest server. If such a case occurs, i.e, if the
client has connected to a malicious server, what were the point in the honest server's checking the client's policy? In
such a case, the honest server is not even participating in the communication, and the malicious server, who is
participating in the communication, will certainly not insist on a strict client policy (not if he is a clever attacker,
at least).

So, what threat scenario is your requirement (of the server being able to verify the client's policy) addressing?