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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 03 November 2013 17:46 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 2879F21E809F for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 09:46:19 -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 SDdaQRPtzSJT for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 09:46:18 -0800 (PST)
Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1CA21E80C4 for <tls@ietf.org>; Sun, 3 Nov 2013 09:46:14 -0800 (PST)
Received: by mail-ee0-f43.google.com with SMTP id b47so673654eek.2 for <tls@ietf.org>; Sun, 03 Nov 2013 09:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=0hAvS4Gdr0te3GozBkOOt2nEb4cqmZSew2rixxHgtXU=; b=K65wRCJi+kPzS8+K5TomzWb1M3YElpcccP5ML4UayVhCRwYfLqdBrZOzWn9litqvWp GXgsxkZv1OHeekXT8QXVX0k63OjLkLSAUKPBHHE5r/SIysH02yDU9CWVQjd5T1lJfeJp fSFCf6HW0DTs+H4zWotggdz4y884TLYdHoONoC930v2/2abdoUG//GQhVqp9gPRYeW+B 7cyPmYWV7iBntahFR80M9L0KmFDjo78MnQjAtKAF2ZdM9QVNPjPcsImOvD1IWpRYJwVs GQBZLs3BF0no4ZCyONJQldIf4qr3ngptrWHZvCPsOQN/LM08uJa0vaV25z3s44Tp8GFh RUHQ==
X-Received: by 10.14.201.9 with SMTP id a9mr14360283eeo.28.1383500774137; Sun, 03 Nov 2013 09:46:14 -0800 (PST)
Received: from [10.100.2.17] (ip-62-245-100-42.net.upcbroadband.cz. [62.245.100.42]) by mx.google.com with ESMTPSA id i47sm12640372eem.5.2013.11.03.09.46.13 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 09:46:13 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <52768BE0.3000602@gnutls.org>
Date: Sun, 03 Nov 2013 18:46:08 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
MIME-Version: 1.0
To: tls@ietf.org
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
In-Reply-To: <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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: Sun, 03 Nov 2013 17:46:19 -0000

On 11/03/2013 06:18 PM, Ralf Skyper Kaiser wrote:

>     * A TLS connection can be established by a fully trusted device which
>     knows a password or other application-layer authorization credential,
>     authorized to perform some operations using messages within the TLS
>     connection, and then transferred with the help of renegotiation to a
>     less trusted device to actually perform those operations.  This is
>     similar to the preceding use, but to provide 'sideways secrecy' rather
>     than forward secrecy.
> Renegotiation comes at a huge cost of complexity (not just from a
> development point of view but also from a security audit point of view).
> All features of re-negotiation can be achieved by re-connecting.
> Re-connecting is well understood, easily tested and audited.

The fact that renegotiation is available in almost all implementations,
says that the cost is not as huge as you mention. You also seem to imply
that renegotiation is as secure as terminating a connection and
re-establishing another one. It is not.

regards,
Nikos