IETF Logo Mail Archive

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

Santosh Chokhani <SChokhani@cygnacom.com> Tue, 05 November 2013 18:00 UTC

Return-Path: <SChokhani@cygnacom.com>
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 BEE1C11E81F8 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 10:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Jczxbf4EHLnf for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 10:00:49 -0800 (PST)
Received: from ipedge1.cygnacom.com (ipedge1.cygnacom.com [216.191.252.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8152E11E816F for <tls@ietf.org>; Tue, 5 Nov 2013 09:59:38 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,640,1378872000"; d="scan'208";a="1031648"
Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge1.cygnacom.com with ESMTP; 05 Nov 2013 12:59:19 -0500
Received: from SCYGEXCH10.cygnacom.com ([::1]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Tue, 5 Nov 2013 12:59:19 -0500
From: Santosh Chokhani <SChokhani@cygnacom.com>
To: Dan Harkins <dharkins@lounge.org>, Ralf Skyper Kaiser <skyper@thc.org>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngQ/AIKIwgsCkqtqecwwW27CJoPssKAgAFPLoCAAxJEAIACEOsAgAAYNYCAAQjNAP//rdeA
Date: Tue, 05 Nov 2013 17:59:18 +0000
Message-ID: <4262AC0DB9856847A2D00EF817E811390B1D07@scygexch10.cygnacom.com>
References: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <20131105003652.5B7AF1AA54@ld9781.wdf.sap.corp> <CA+BZK2rG4L_+oMOQ3xBEogWNtrspeFM5cUJw9ciwtmEQpvgGjQ@mail.gmail.com> <866d3caa053aacb9be8a3ed19a61311e.squirrel@www.trepanning.net>
In-Reply-To: <866d3caa053aacb9be8a3ed19a61311e.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.24.90]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 18:00:54 -0000

I am failing to see the security benefit or threat the server verification of client's hygiene on certification path validation provides.

If the client ends up trusting the wrong key, it will go to a bad server.

If the client is connected to the good server, certification path validation does not matter since it is already at the right place no matter how it got there.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Dan Harkins
Sent: Tuesday, November 05, 2013 12:51 PM
To: Ralf Skyper Kaiser
Cc: tls@ietf.org
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3


  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.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email