Re: [TLS] a proposal for TLS 1.3

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 12 November 2013 11:38 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 94FC611E8125 for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:38:07 -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=[AWL=0.000, 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 vvnuVhqEtmyl for <tls@ietfa.amsl.com>; Tue, 12 Nov 2013 03:37:47 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 56F6B11E8132 for <tls@ietf.org>; Tue, 12 Nov 2013 03:37:45 -0800 (PST)
Received: from Masham-MAC.local ([91.179.213.128]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M7ojs-1VTBiQ2DRY-00vPre for <tls@ietf.org>; Tue, 12 Nov 2013 12:37:42 +0100
Message-ID: <52821305.6070104@gmx.net>
Date: Tue, 12 Nov 2013 12:37:41 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <CAJU7zaJrMKP03qnYJ5FdrAxZNf6g6bRycXzOY4cUgmF_HvbJVg@mail.gmail.com> <4613980CFC78314ABFD7F85CC302772121AD5B17@DAG-EX10.ad.checkpoint.com> <5282082B.8060003@gmail.com>
In-Reply-To: <5282082B.8060003@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:SKrMNkQg4r4V/7XJBIHZUxRHsbi9CZpAGsPKuOmsh9hHEjW5WmQ X+/CebfcZYv12Z+3DRBfE2xNBKkwSjoyodCdvEB2ghrKc4U0HwNR27h8+HkpcY5y3N0Uv3p rjas7bkxHkH+zeR14N8b45n41N5e8d3HCBdzbY1VOIYM/DbsHdQxGo944wMRAAVSmac1A7a HEN+KvTnd/oZ8BaETYXBg==
Cc: "tls@ietf.org" <tls@ietf.org>
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 11:38:07 -0000

The story in IKEv2 was different. There were a few guys (already active 
in the IETF for a long time) proposing designs and there wasn't really 
an outreach to the research  outside the IETF, as far as I recall.

There was some work on documenting the design decisions (which also 
explains the problem being solved and captures the requirements) but 
that did not go anywhere. Here is the document: 
http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-tutorial-01

Of course it takes longer than 2 IETF when it comes to such a complex task.

Am 12.11.13 11:51, schrieb Yaron Sheffer:
> 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
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls