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

Nico Williams <nico@cryptonector.com> Tue, 05 November 2013 03:19 UTC

Return-Path: <nico@cryptonector.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 EFB9E11E8232 for <tls@ietfa.amsl.com>; Mon, 4 Nov 2013 19:19:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.081
X-Spam-Level:
X-Spam-Status: No, score=-2.081 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 7CmL+kKS4rDo for <tls@ietfa.amsl.com>; Mon, 4 Nov 2013 19:19:12 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E7B9911E8105 for <tls@ietf.org>; Mon, 4 Nov 2013 19:19:11 -0800 (PST)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 80EDE9405C for <tls@ietf.org>; Mon, 4 Nov 2013 19:19:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=SHD1FkOLnUqCXZ3LBkVR aNA/Gvw=; b=Q0AKR/p34NnsV2PUgwVMlSLYW84vwBnwpG2CdLEvrSHhg2u/FBdh mLQ/Gm18aFvXzf8flr18xNm9BOQ8eDMAQOsHi/ZlXDtFj36nLQ4HDIn6TD8eOh4c U3+pBV8zOvxGFMf5i5cC3fji6D3fO1p5E1lk9WIEto7wMZecnRXOjYM=
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 360C794059 for <tls@ietf.org>; Mon, 4 Nov 2013 19:19:11 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id x55so2852730wes.8 for <tls@ietf.org>; Mon, 04 Nov 2013 19:19:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hsqpZ8wfuNWXYYYyk+iH/KUSC/0FdV/b7OrjM7mPGBQ=; b=Cv7ma0FM1JseBgfWlDqGegokrTkAH9HUrljTzzxaNebSH0BoJYJ2TJ4DVuipGuaieC lppB1gxF6c7idny86oloUlpEM2doMe+tFTnHRiPcu5vICHRBp+2SqeYWw8+CcFKLe9eQ n+K98IxtPK8nJ8Cp/LmYHSovBMgzf+lXOuWl6ejRr2ykFPdd6sfPIVTA4C/dHEc4VtWo V2pofjUReaQNY69ZmLLx+9WUibhHU8QMTZNeHsaX8M73DMk6QxFDJUdYN90cAJ54eRmm 5xgU/2wQH1CscKSoK2k9Q/bOVHdJHG/NAbhhEOq6azDQ43I5LynUzqmT8s5XhsDFLPZp rNkA==
MIME-Version: 1.0
X-Received: by 10.180.99.3 with SMTP id em3mr15168006wib.4.1383621549543; Mon, 04 Nov 2013 19:19:09 -0800 (PST)
Received: by 10.216.151.136 with HTTP; Mon, 4 Nov 2013 19:19:09 -0800 (PST)
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: Mon, 4 Nov 2013 21:19:09 -0600
Message-ID: <CAK3OfOh+mc-UzS62fx_oN1QUasjAu3NU72=9tkyQfk8yJw9T=A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Content-Type: text/plain; charset=UTF-8
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 03:19:17 -0000

On Mon, Nov 4, 2013 at 8:03 PM, Ralf Skyper Kaiser <skyper@thc.org> 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.

What are you talking about?  Of course the client and server (and CAs,
and...) can all cheat on *themselves*.  But the whole point of
verifying some other party's certificate is to protect yourself.  The
client (unless it's a dumb, dumb client) is going to do check the
server's cert.

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

Yes, it'd be nice if XMPP clients had a
leap-of-faith/trust-on-first-use option.  That has nothing to do with
this thread unless you're proposing a different method of
authenticating servers.

> A securely configured TLS client would verify the certificate chain.

I know right?  So that's a bug in the client.  Nothing wrong with TLS
itself.  (Well, the PKIX bits are not trivial, and that has to do with
why some clients get things wrong, but surely you're not proposing
replacing the PKIX bits.)

> The server has no way to check if the TLS client is configured securely. The

And vice-versa.  Of course.

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

Ah!  You want a secure bit.  Like RFC3514 (note the publication date).
 It doesn't work.

Nico
--