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

Ralf Skyper Kaiser <skyper@thc.org> Tue, 05 November 2013 02:03 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 76C3D21E819D for <tls@ietfa.amsl.com>; Mon, 4 Nov 2013 18:03:37 -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 u+ORuxk5-JD2 for <tls@ietfa.amsl.com>; Mon, 4 Nov 2013 18:03:33 -0800 (PST)
Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id B919411E8269 for <tls@ietf.org>; Mon, 4 Nov 2013 18:03:31 -0800 (PST)
Received: by mail-ie0-f181.google.com with SMTP id ar20so13546824iec.26 for <tls@ietf.org>; Mon, 04 Nov 2013 18:03: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=hcNqyMFTdZESF6O2UlTdt1WsT/h5sMT/TLNYjTUqbLc=; b=OVOIf1MP61KDUztofTj+/7H+KEkPdNwLV/bae/80+M7NMjOpjtMJuORF20vUSoy51D kJI+33ElHd2ilVvllFTPdHNYud2kTUDiZ8FGTh2JW/tD+eW32Nvnv/ncabfIC5h5Zt+7 xWURQHVot3Mou5wH4Qm8kZ48/3MPEF8YXwCw0=
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=hcNqyMFTdZESF6O2UlTdt1WsT/h5sMT/TLNYjTUqbLc=; b=LHblBOCU4IW3Opvs9sxveZEW0HRrtT+wDUrrN679o65WyPRSFvQGxsNuavqJYPWq7t dwSj8yWGv3bf1P4+b8NaapC9eEDp/zVgsOSKQbgYWMDUTOzWBKnvlbwvAxUbEDrI/p8U eoerTYjZiLa64eFEIDp/WrTUhqWHaXf26ldYenIeZKqNrAQ4oxgZFzGRQUK7+3c7RKzM bWtDYdLhzq+UILYv6ClowxROgQYzMeNl5GymO0Tk1X906ge8F1Dd3F85IXLsPUOask7K jFAQlf50V8dmKMT0csE9jqOQcE0UvqU9Z0mosOpVkl0bjMbDl1DGZKDbrp4broz5iYXw xXwg==
X-Gm-Message-State: ALoCoQnpiucPUrkDLChxtxyH+fKEsK0C7wSF/+wCIPlOvNB6SS1mTpO1j697GDnQBBu4/YpkMxLw
MIME-Version: 1.0
X-Received: by 10.42.190.142 with SMTP id di14mr3018866icb.45.1383617011249; Mon, 04 Nov 2013 18:03:31 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Mon, 4 Nov 2013 18:03:31 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp>
Date: Tue, 5 Nov 2013 02:03:31 +0000
Message-ID: <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=20cf303ea4b876145904ea6470e3
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 02:03:37 -0000

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
>