Re: [TLS] TLS 1.2 Long-term Support Profile draft posted

Watson Ladd <watsonbladd@gmail.com> Wed, 16 March 2016 18:53 UTC

Return-Path: <watsonbladd@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 DB0E312DA02 for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 11:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ypTon9oAi1QO for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 11:53:45 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1154112D561 for <tls@ietf.org>; Wed, 16 Mar 2016 11:44:03 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id e185so73496731vkb.1 for <tls@ietf.org>; Wed, 16 Mar 2016 11:44:03 -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; bh=xxX+WOYz/P9n2wn8NwzM+h6GzsrCHDNBgw0Gk9OrDCY=; b=J85xL54qvKa5Hn9AW1lrfAcdm1NeBVM/lb+/kzAJF289lAioXqreCdx+b4q+XFLy0q giTDt7cj7P4kGoRy1nepkRSKyHw6k3f9bTBmTJaM2KOw5+wjPdBxUzkgigtDcXtdInuE OjfFr/Wm3vVZj9NqMZ0hmBVHprBmUoZKwbAhWRcKy9cEVwRXtgR2oP8VkfgbFvvsDXFX OGZyxb1lMsLGDh+dEKvKcSfcRK8Wmsk9EEpL6p5l/GM+FYHb+pR9+jhiYPFCM6qWTID/ q4gyT1cCbpw0ZuLFoFUm5iWqd4MyxKv8Z+vP5x6Ju9rqW4ikk6JmaUmbkSUIRuzlov27 3BEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xxX+WOYz/P9n2wn8NwzM+h6GzsrCHDNBgw0Gk9OrDCY=; b=LvcuHL8JTYyTHJJg9lqqiiJKoX/ai7k3hXn9Y7kxU93Pxzoce+tJ2r3+889NEmmoIu lZmzjo4jmDY/PBOW8wkoyA9J1YoOvr8nABVaksImUO4OW2PZPmYN32JXQhboKy5uFwLv BocUDmEEvBCuyZ/K+VDQEJoJEUwp9j/jiXAeqqCsAyfMRz4X99LwKXag6qNvu4NaESoB RLtjK1IMAarrziCnfkO+ens+4qD+QOQymTT1TC6tTYkJ/nMw8xyLJx1NtaB8WEdSb0JA xdbGPkzQpMLDyWtR6JpUkjJq9wErzkbngrqgHy26RE7X9IM4vd5wnSb4tzwNIwWNcbwr g2GA==
X-Gm-Message-State: AD7BkJI4y3DeShD9OVuRsUUROiu7RxIyjQA6F9PJm2XdHRPL++AoTVqTeTzaANQkYM65UHSHHOJDc65ffujAXQ==
MIME-Version: 1.0
X-Received: by 10.31.54.134 with SMTP id d128mr5997747vka.26.1458153842101; Wed, 16 Mar 2016 11:44:02 -0700 (PDT)
Received: by 10.176.1.183 with HTTP; Wed, 16 Mar 2016 11:44:02 -0700 (PDT)
In-Reply-To: <D30F5342.66E5C%kenny.paterson@rhul.ac.uk>
References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <CACsn0cks1tvdcYkVRj9r3TZe1GEcNA5f2x14PQntk3j1Ws+rPg@mail.gmail.com> <D30F5342.66E5C%kenny.paterson@rhul.ac.uk>
Date: Wed, 16 Mar 2016 11:44:02 -0700
Message-ID: <CACsn0cn_MyJO3dSzq8gZDdWg5OjizRXZMn_B7YZyAVCBrE0W_g@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WHfVJTjRbtopDyY0kfcimkt6rVM>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 16 Mar 2016 18:53:53 -0000

On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
<Kenny.Paterson@rhul.ac.uk> wrote:
> Hi
>
> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" <tls-bounces@ietf.org
> on behalf of watsonbladd@gmail.com> wrote:
>
>>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann
>><pgut001@cs.auckland.ac.nz> wrote:
>>> After a number of, uh, gentle reminders from people who have been
>>>waiting for
>>> this, I've finally got around to posting the TLS-LTS draft I mentioned
>>>a while
>>> back.  It's now available as:
>>>
>>> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt
>>>
>>> Abstract:
>>>
>>>    This document specifies a profile of TLS 1.2 for long-term support,
>>>    one that represents what's already deployed for TLS 1.2 but with the
>>>    security holes and bugs fixed.  This represents a stable, known-good
>>>    profile that can be deployed now to systems that can't can't roll out
>>>    patches every month or two when the next attack on TLS is published.
>>>
>>> Several people have already commented on it off-list while it was being
>>> written, it's now open for general comments...
>>
>>Several comments:
>
> <snip>
>
>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more
>>extensively analyzed then TLS 1.2. It's almost like you don't believe
>>cryptography exists: that is a body of knowledge that can demonstrate
>>that protocols are secure, and which has been applied to the draft.
>
> This is patently untrue. There is a vast body of research analysing TLS
> 1.2 and earlier. A good survey article is here:
>
> https://eprint.iacr.org/2013/049

There's a vast literature, but much of it makes simplifying
assumptions or doesn't address the complete protocol. The first really
complete analysis was miTLS AFAIK. Furthermore, a lot of the barriers
to analysis in TLS 1.2 got removed in TLS 1.3. The question is not how
many papers are written, but how much the papers can say about the
protocol as implemented. And from that perspective TLS 1.3's Tamarin
model is a fairly important step, where the equivalent steps in TLS
1.2 got reached only much later.

It's true 0-RTT isn't included: so don't do it. But I think if we
subset (not add additional implementation requirements) TLS 1.3
appropriately we end up with a long-term profile that's more useable
than if we subset TLS 1.2, and definitely more than adding to the set
of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely
to have crypto weaknesses due to newness are vastly overstated.

>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.