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

Yoav Nir <ynir@checkpoint.com> Sun, 03 November 2013 23:42 UTC

Return-Path: <ynir@checkpoint.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 7A5D411E8258 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 15:42:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.503
X-Spam-Level:
X-Spam-Status: No, score=-10.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 tOa2-MQq1DRu for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 15:42:37 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F331811E8255 for <tls@ietf.org>; Sun, 3 Nov 2013 15:42:24 -0800 (PST)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id rA3Nfxlf023208; Mon, 4 Nov 2013 01:41:59 +0200
X-CheckPoint: {5276DDFE-0-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.106]) by DAG-EX10.ad.checkpoint.com ([169.254.3.213]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 01:41:59 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Watson Ladd <watsonbladd@gmail.com>
Thread-Topic: [TLS] What would make TLS cryptographically better for TLS 1.3
Thread-Index: AQHO1ngUoMjfWHp8eUeJG+rmdHIlV5oPTiyAgAFPL4CAAwGAAIAAJYkAgABEdgCAAAFqAIAAA9YA
Date: Sun, 3 Nov 2013 23:41:58 +0000
Message-ID: <4F215492-A376-45BD-A310-913B6BE97A36@checkpoint.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com> <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com> <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
In-Reply-To: <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.21.122]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1FE081322174E741AA90763B9CB95162@ad.checkpoint.com>
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: Sun, 03 Nov 2013 23:42:43 -0000

On Nov 3, 2013, at 3:28 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Sun, Nov 3, 2013 at 3:23 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>> Hi Yoav,
>> 
>> i agree with the UI issue. That's the only use that I can see where
>> renegotiation is useful.
>> 
>> I would guess here that 99% of all TLS users (if not 99.99%) do not need
>> this feature.
>> 
>> The 99.99% of all users would have to carry the risk of complexity to
>> satisfy the need of the 0.01% of users.
>> 
>> There are hopefully other ways to satisfy the need of the 0.01% without the
>> 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas are
>> welcome...).
> Kick it into the application layer.

Do you mean HTTP or the actual application?

Neither of them has all the cruft that is involved in accepting certificates (ASN.1, revocation validation, etc). So do we reduce complexity a little for TLS, at the expense of a huge increase in complexity for higher layers?

The security of the system depends in part on the complexity, but that's the complexity of the whole system, not of a particular component. Kicking the complexity around from one component to another only helps if that makes for a more logical separation. Moving client authentication into another layer doesn't do that.

Yoav