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

"Dan Harkins" <dharkins@lounge.org> Tue, 05 November 2013 17:53 UTC

Return-Path: <dharkins@lounge.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 4753321F9E91 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 09:53:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.005
X-Spam-Level:
X-Spam-Status: No, score=-6.005 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 pHorJQGVuF8U for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 09:53:07 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1F121F9D98 for <tls@ietf.org>; Tue, 5 Nov 2013 09:51:29 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9400A10224008; Tue, 5 Nov 2013 09:51:15 -0800 (PST)
Received: from 31.133.166.166 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 5 Nov 2013 09:51:16 -0800 (PST)
Message-ID: <866d3caa053aacb9be8a3ed19a61311e.squirrel@www.trepanning.net>
In-Reply-To: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
Date: Tue, 5 Nov 2013 09:51:16 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Ralf Skyper Kaiser" <skyper@thc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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 17:53:19 -0000

  Hello,

On Mon, November 4, 2013 6: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.

  Doesn't RFC 3514 solve this problem for you? If not, then maybe it's
time for a 3514-bis.

  regards,

  Dan.