Re: [TLS] TLS 1.3 process

Watson Ladd <watsonbladd@gmail.com> Fri, 28 March 2014 15:01 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735C01A06C6 for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 08:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q72aNs7Z7uxk for <tls@ietfa.amsl.com>; Fri, 28 Mar 2014 08:01:54 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA921A065A for <tls@ietf.org>; Fri, 28 Mar 2014 08:01:53 -0700 (PDT)
Received: by mail-yk0-f182.google.com with SMTP id 142so826956ykq.41 for <tls@ietf.org>; Fri, 28 Mar 2014 08:01:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nhn4LqOTD0qMLok8E2B5T6nDqgIoFBrPZYV6hG1w/Cg=; b=CNRnKXJsNaq9VN6lSmWQ+IafIbY5uX4j7JjvdYFjfW9NMQtwtLctJDiACBN8l8XUr+ KwkT7ezrjSKcjb8zu2h9DMsW0cpdP0GMQKIxaDcAEgvyj/+RC/U1Smi3tRDWo/laA2LN qoWa/cIN1p4iccWWiBFFvH5A7cuwhSPMYx/Toj2ME4orfiwkYs/l1xHD8uoTF5cdeAcG wNFUjDigNj3ITVPTPjOqdgGah1o1VxzdLTQfDIdhwSDT8o/Oh9AgwwypPacdNLJZBT1q g5dR8J4AugmSyN6G3X+qqENd7EbHV1HdD8PjWFOnS9Kzp7Fw2E5M+K513l1wGk29d4qN rdUA==
MIME-Version: 1.0
X-Received: by 10.236.179.162 with SMTP id h22mr3854577yhm.107.1396018911792; Fri, 28 Mar 2014 08:01:51 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Fri, 28 Mar 2014 08:01:51 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com>
References: <AF370E26-CA97-4CE3-9CC7-2F0939FE2B71@ieca.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE833@USMBX1.msg.corp.akamai.com>
Date: Fri, 28 Mar 2014 11:01:51 -0400
Message-ID: <CACsn0cnaihH74TxpfXr3wTP-9czt3ThRBGvfYxKKY5qspWhkAg@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_idErTKTFJCtTSz0a0YEWwuHQa4
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 process
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 28 Mar 2014 15:01:55 -0000

On Fri, Mar 28, 2014 at 10:12 AM, Salz, Rich <rsalz@akamai.com> wrote:
>> The TLS WG charter is pretty clear that the intention isn't to design a completely new protocol but rather to revise TLS,
>> and specifically to "place a priority in minimizing gratuitous changes to TLS."
>
> +1.
>
> It seems to me that there are almost three viewpoints within this WG.  With the hope that I'm equally unfair to everyone, I'd summarize them like this:
>         - Update to modern crypto knowledge to fix bugs, and some modern features and be done
>         - Make big changes to fix serious problems
>         - Start over from a clean sheet; "I don't know what it will be, but we'll call it TLS."
>
> I put myself in the first group (except for SNI encryption, which will get a separate post :), could be convinced to support something from the second once it's written down, and am probably not qualified to evaluate anything from the third group (few people are). Interestingly, barring divine intervention, the above list is probably in order of length of time needed, as well. That would seem to indicate that there's room for all three efforts here.

I think the first issue should be our biggest priority: leave the
handshake largely alone, focus on fixing insecure resumption and the
record layer, removing compression, mandate secure renegotiation,
document 1/N-1 record splitting. All of this needs to be done in TLS
1.2, and there are drafts for most of it already.

Once that's done, we can turn to things like zero-round handshakes and
caching and encryption of handshakes.

As much as I like 3, I don't think it will ever happen. Maybe IoT will
be looking for something much more lightweight? There are alternatives
like MinimalLT and CurveCP, but takeup is understandably slow.

Sincerely,
Watson Ladd

>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin