Re: [TLS] a proposal for TLS 1.3

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 12 November 2013 10:51 UTC

Return-Path: <yaronf.ietf@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 1D58521E80A9 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 gJpAvQ+xHc4A for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 02:51:26 -0800 (PST)
Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 49CF821E80A8 for <tls@ietf.org>; Tue, 12 Nov 2013 02:51:26 -0800 (PST)
Received: by mail-bk0-f42.google.com with SMTP id w16so2164425bkz.15 for <tls@ietf.org>; Tue, 12 Nov 2013 02:51:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=B9k6+TjDqhYul9m1AKft4AI7zuIrT3Vu/tAffNdDO9s=; b=NOBOhgPh00Dk72HpXRhP3jAfHkCbcclrNMn1NWSjctd9iEJBQNx4IiBtAxHT4zWKt2 S4RlBWJrYwayzXldbZRx+X10x1EZO7qRghIw9pomJYxLLSI9Lns4F7VR5gg6YAsbbI86 Nj/F6+NVhXE1jr9xsNt+mq+ALfABqyjw6YMWyRoCW+vq8feNbnkxszHghwg3YrVTKY+1 Pw6toTUZM5u/nmPG3dIxlzoosAvxmC0/V/cVvN7czUxcgl51DtPuFX1yklsD38SVE9I4 NvzN0NUv9m48OCi6wJTLbcplD5o2sS6WBn+Jx1Me1c+vUk9rVMZKjI3h3grZHN2R4EWW xL2g==
X-Received: by 10.204.69.202 with SMTP id a10mr1156016bkj.36.1384253485307; Tue, 12 Nov 2013 02:51:25 -0800 (PST)
Received: from [10.0.0.8] (109-186-48-194.bb.netvision.net.il. [109.186.48.194]) by mx.google.com with ESMTPSA id on10sm17539964bkb.13.2013.11.12.02.51.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 02:51:24 -0800 (PST)
Message-ID: <5282082B.8060003@gmail.com>
Date: Tue, 12 Nov 2013 12:51:23 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>, Nikos Mavrogiannopoulos <nmav@gnutls.org>, "tls@ietf.org" <tls@ietf.org>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com>
In-Reply-To: <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] a proposal 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, 12 Nov 2013 10:51:27 -0000

What Nikos proposes is reminiscent of what happened with IKEv2. I wasn't 
following closely at the time (more than 10 years ago), but:

- This did bring in people from the research community. See for example, 
http://tools.ietf.org/html/draft-ietf-ipsec-jfk-03.
- It took WAY longer than 2 IETF cycles.
- As far as I know there was never a problem statement document.

So it's not a glowing example, but it proves this can be done.

Thanks,
	Yaron

On 11/12/2013 12:05 PM, Yoav Nir wrote:
> Hi Nikos. This is pretty much what httpbis did for HTTP/2. Only it did not take a year or two - only two IETF cycles.
>
> So a competition could be announced now, with proposals presented in London, and a decision reached before Toronto.
>
> While there are many research groups, they don't do protocol work so much.
>
> The real tricky thing here is not designing a "new TLS", but co-existence with SSLv3, TLS 1.0, 1.1, and 1.2 without resorting to the kind of fallback mechanism where you try with TLS 1.3 (or 2.0, or even better - 4.0) and if you get a reset, try again with TLS 1.2, and if that doesn't work, go straight to SSLv3.
>
> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nikos Mavrogiannopoulos
> Sent: Tuesday, November 12, 2013 11:55 AM
> To: tls@ietf.org
> Subject: [TLS] a proposal for TLS 1.3
>
> Hello,
>   Having seen the current discussion for TLS 1.3, I have some proposal.
> Since the changes requested are large, I'd suggest not to design TLS 1.3 in this working group. I'd suggest this working group to set the specs for the next TLS version (and better name it 2.0), and then announce a competition for the initial draft of the protocol. Then have the WG review the submitted proposals in a year or two, accept a winner, and the WG starts working on the winning draft.
>
> I'm pretty sure there are many research groups that will be honoured to join such a competition and their results may outperform the results of the limited number of participants in the working group.
>
> best regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>