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

Sven Schäge <sven.schaege@rub.de> Sat, 19 March 2016 21:06 UTC

Return-Path: <sschaege@googlemail.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 AAAF612D53D for <tls@ietfa.amsl.com>; Sat, 19 Mar 2016 14:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 9MPXq4VKPGFp for <tls@ietfa.amsl.com>; Sat, 19 Mar 2016 14:06:32 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 A7B8312D50C for <tls@ietf.org>; Sat, 19 Mar 2016 14:06:32 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id d205so113933946oia.0 for <tls@ietf.org>; Sat, 19 Mar 2016 14:06:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=31K1yExy17eP7atc4EVPQ9USRzekA2jbCEnLuO4Acmk=; b=fU8eaeWs7o+R+Z9563YJ5YYy5eaKVBdGmggZBZnu1Q5Stp28yDkvBK3YzBeCgnwPxV k+RbrNklLZ84yLjMez7NSsKBGHxvC/QmR2I+f01SAU0jPzA/DSD/luZcsVlzEuSC/3Ed I5uAAWKzTW9Htkl1UYVJyb+cCJrg3S6OEBdrSTIoE6btACKLTOX95LMvdH83KT4yRovb R7+DHXytMiWzVo/EnsDtI7v1v6KqnYZSgoY4wI0G0PrRaYpK4RotUJzJ3/qxNRy2UnrW dGvHzQ0yxRmnStjcefDGxOoxxufW+wxkiCI/j32oN1JGx7nmiCu0e7synPZKmqHnFDny CN7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=31K1yExy17eP7atc4EVPQ9USRzekA2jbCEnLuO4Acmk=; b=TmdQdziO3OKDkLCnDb9Sk2+RMiwQApLvTldk8BPM9PmbsrrThvOCLTG8cbXFjzJTlp XBJcsAkHVNm8cVlGJkKoma/DbkaUr1bY1iG9Ko5EMcs23j2YM7+9vZQuTmWF+G+suUPi aoAI1KLTzWBgSdSEXLGkxl1ZCf0wBHVjxav1DSXLkCU6P1ydu9Y+mZ9xdr8Gw8aZq18K +IeBeOqR1h1Mwp3WCHUEzhVjNvd71HiKgDfhLYkWu6xtCXx2WiYYy0h4FBZmvSaX5Nus MOwAs9TV8HLWC+6IMAroZKE91nlMvGSaefEJX8aIgVN/CrmYr62tBGS4cdh5OJrtYcny k6ng==
X-Gm-Message-State: AD7BkJJnrNrn5FzoJ9yglqfWfmSdYDyckiH7xUlLPzDsQePLVhQ/RKh7MkXyr3j76QJCV3G6DH0m+Q1duLMVfw==
MIME-Version: 1.0
X-Received: by 10.202.221.87 with SMTP id u84mr13471977oig.93.1458421592065; Sat, 19 Mar 2016 14:06:32 -0700 (PDT)
Sender: sschaege@googlemail.com
Received: by 10.182.24.101 with HTTP; Sat, 19 Mar 2016 14:06:31 -0700 (PDT)
In-Reply-To: <D30F5F9C.66E8A%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> <CACsn0cn_MyJO3dSzq8gZDdWg5OjizRXZMn_B7YZyAVCBrE0W_g@mail.gmail.com> <D30F5F9C.66E8A%kenny.paterson@rhul.ac.uk>
Date: Sat, 19 Mar 2016 22:06:31 +0100
X-Google-Sender-Auth: isjKF5VammgHtzDQlbt2HBhsId0
Message-ID: <CAO9bm2=Ao7XyMwSXRjmnyRBX_ni2nrRke7Lk=b=c8bgtLcmNwQ@mail.gmail.com>
From: =?UTF-8?B?U3ZlbiBTY2jDpGdl?= <sven.schaege@rub.de>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
Content-Type: multipart/alternative; boundary=001a113d526ced8eed052e6d3cf7
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/blrdZDUCAk5uTZP0N-_ldExbyjM>
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: Sat, 19 Mar 2016 21:06:35 -0000

Dear Kenny,

thank you for clarifying the state of the cryptographic analysis of TLS 1.2
and 1.3! I also do not see TLS 1.3 being nearly as good understood from a
security standpoint as the previous version. This is only natural given
that it is so recent. I am also not quite happy with the existing results
and their meaning for the final version of the standard (although I really
am happy that the cryptographic community in general accompanies the
standard development process.)
I would expect the most valuable results to be published once there is an
entirely fixed candidate specification. As Hugo has mentioned several times
details really matter. Therefore I really like the idea of giving
cryptographers time to analyse the final candidate quite thoroughly before
acceptance.

And no, you guys are not the only ones reading this.

Many greetings,
Sven


2016-03-16 20:26 GMT+01:00 Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>;:

> Hi
>
> On 16/03/2016 18:44, "Watson Ladd" <watsonbladd@gmail.com>; wrote:
>
> >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:
> >>
> >> <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.
>
> Correct, but that does not make it irrelevant or valueless. Or are you
> actually saying that it does? Quite a sweeping presumption; see
> immediately below.
>
> >The first really
> >complete analysis was miTLS AFAIK.
>
> Yes, and even there the analysis was done step by step, spread out over a
> series of papers which gradually built up the complexity of the code-base
> being handled. And, in parallel, various other groups were doing hand
> proofs of abstractions of the core protocol. And I believe it's fair to
> say - from having discussed it extensively with the people involved - that
> the miTLS final analysis benefitted a lot from the experience gained by
> the teams doing the hand proofs, going right back to a paper in 2002 by
> Jonsson and Kaliski Jr.
>
> My point is that the TLS 1.2 "final" analysis represented by the miTLS
> work was the culmination of a long line of research involving many people
> and influenced by many sources.
>
> > Furthermore, a lot of the barriers
> >to analysis in TLS 1.2 got removed in TLS 1.3.
>
> Unfortunately, some of them may be coming back again. But again, this has
> nothing to do with the argument you were making.
>
> >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.
>
> The timing is entirely irrelevant to the argument you were making.
>
> I agree though that it's about the depth and reach of the analysis. And
> from this perspective, I'd say that TLS 1.3 is still way behind TLS 1.2,
> despite the very nice analyses done by Sam and Thyla (and their
> collaborators), by Hugo & Hoeteck, and by Felix & co.
>
> I could go further, but I expect that, by now, only you and I are actually
> reading this.
>
> >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.
>
> I didn't make that claim.
>
> Cheers
>
> Kenny
>
> >--
> >"Man is born free, but everywhere he is in chains".
> >--Rousseau.
>
> "If I have seen further it is by standing on the shoulders of Giants"
> -- Newton, in a letter to Robert Hooke
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>