Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Arnaud Taddei <arnaud.taddei@gmail.com> Thu, 05 October 2017 09:14 UTC

Return-Path: <arnaud.taddei@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 BCEEE13292A for <tls@ietfa.amsl.com>; Thu, 5 Oct 2017 02:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham 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 5cnmOo8P2Qdk for <tls@ietfa.amsl.com>; Thu, 5 Oct 2017 02:14:28 -0700 (PDT)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::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 A1D3212ECEC for <tls@ietf.org>; Thu, 5 Oct 2017 02:14:27 -0700 (PDT)
Received: by mail-wm0-x235.google.com with SMTP id i124so805982wmf.3 for <tls@ietf.org>; Thu, 05 Oct 2017 02:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N67+A+qcpFxCbbu3qOl6+YWFfUKao28YopVeEmlJW5U=; b=ebYkCR4u+oSvdJS75JxgwLgD4dxG74O4D98ALLH6Ky09ZRbvFXC22nAXoPYYHPzgPN k7ny4xANQ/GH99Xk/LKcnVYIaIThDwDr4oGEcZRQGc2PR+geCOS9DeNYqypGxnHQD7cS 6wbye/NlTXEP9tyCka3w/rESpG8anzyHHlR20M4jpHenFwnCZAbYNf+GNOGW/eAW3Y9k CUWR8ZbVVqoUdRiaIx6QeCvzHIZqbiAqugsGxwPK6eeURK5vDWQy21nxGdBnhJXvcYJL 3iN1F8Jn/TixLgsSrd/Lm7wInjXC+SvuIE9gAb//1/G0QA3pdQDbwTDBFFEr4zUpZK/q 0w2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=N67+A+qcpFxCbbu3qOl6+YWFfUKao28YopVeEmlJW5U=; b=n3+zUWDXnqRA1SCrU9Ksty/8p1y9bd0/6gOUIUE9nhYw66MMYPr6xVwVn0BDK4f7uc zfDHFlMAXINL9cZYU0q79OkIpVOfhYNQb8YkyVJA+VFsqEk9Yesg5A/a9w8j0HQcWeKW /jvp6HnHxMC7fK0Ye1+6vPbiGbBTwDbNdVvBqNQvVOWqCejuOGYd+ywRhdJJ3EMW2W/L 8swE7xueXgUi2SM6O37q25kk8PBQGkDE1vsow5DOJ3EB4XSF1cok0A+lhhpWH1lNvbJL LQdegaLiL/PpwAsd7p5lDrrQYk1a246KLNmjDZk5zAXScUcEaWDRatQChGd1DwL7pRL5 GoPw==
X-Gm-Message-State: AMCzsaXrU8chvyXRhHqqjSNwRz8truVdqBL1w+lXyDttKLTJEJLK4E5j 4F0DHJewygJ8ZcKIzCrPXM8=
X-Google-Smtp-Source: AOwi7QBBdD+3WtTiNi05YZy4wJJ452ullTLVQ21L4lPVR92150wrQYkvzvInwuuZPuh+gso5yOLIgg==
X-Received: by 10.28.199.139 with SMTP id x133mr5358554wmf.145.1507194866092; Thu, 05 Oct 2017 02:14:26 -0700 (PDT)
Received: from [192.168.0.23] (81-67-195-114.rev.numericable.fr. [81.67.195.114]) by smtp.gmail.com with ESMTPSA id n191sm248445wmd.7.2017.10.05.02.14.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2017 02:14:25 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Arnaud Taddei <arnaud.taddei@gmail.com>
In-Reply-To: <fce2567d-7a01-1d30-609a-20e7561bca5c@cs.tcd.ie>
Date: Thu, 5 Oct 2017 11:14:25 +0200
Cc: Russ Housley <housley@vigilsec.com>, IETF TLS <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <90C8C6CB-3F08-4966-A6BB-656167D9C863@gmail.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <49d914cf-7b33-9379-5659-30ffb18244da@cs.tcd.ie> <6E5D81C8-694E-4098-BF38-561637529AA9@vigilsec.com> <2f8c1e4e-5997-de8a-c10e-c409dff3fc13@cs.tcd.ie> <DEB495A4-7638-40A8-9137-3E3C82C38BEC@gmail.com> <fce2567d-7a01-1d30-609a-20e7561bca5c@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IRAP0-z9EvBxOG7uVs8fn3CwZaY>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 05 Oct 2017 09:14:30 -0000

I see, thank you, it seems that there is a lot of archeological work to be done. 

Ok at least I can organize my work as perhaps a good first step home work before being in a position to comment further


> Le 5 oct. 2017 à 11:12, Stephen Farrell <stephen.farrell@cs.tcd.ie>; a écrit :
> 
> 
> 
> On 05/10/17 09:54, Arnaud Taddei wrote:
>> Being new to this community, can I actually ask for the analysis of
>> the ‘hundred’s of applications’ which lead to the evolution of TLS
>> 1.3 the way it is today? Was it captured somewhere or shall I
>> reconstruct this history from all the discussions in the mailing
>> lists?
> 
> It's more the latter. But, and it's a big but, tls1.3
> is almost entirely (0rtt aside) aiming to provide the
> same services as earlier versions, just to do it better,
> so the need for that kind of broad survey of uses of
> tls is far less. WRT 0rtt, people did, and are doing,
> a bunch of work to figure out when it's (un)safe to
> use that.
> 
> When it comes to breaking tls (as in this proposal),
> since that'd change the security model (from an
> essentially two party security protocol to an N-party
> model), a lot more work would need to be done, and
> has never been done, by any of the people proposing
> to break tls, at least afaik.
> 
> S.
> 
> 
>> 
>> Thank you in advance
>> 
>>> Le 3 oct. 2017 à 00:48, Stephen Farrell <stephen.farrell@cs.tcd.ie>;
>>> a écrit :
>>> 
>>> 
>>> Russ,
>>> 
>>> On 02/10/17 22:43, Russ Housley wrote:
>>>>> For starters, though, I'd be interested answers from the
>>>>> authors to two quick questions, though I suspect I can guess
>>>>> 'em:
>>>>> 
>>>>> 1. TLS1.3 has had significant formal analysis. Did the authors
>>>>> or other proponents here do any such work and if so can you
>>>>> send a pointer to your results? If not, then I believe the onus
>>>>> is on the folks who want to break TLS to do that work
>>>>> themselves if they want to make a serious proposal and it is
>>>>> not ok IMO to try put that work onto the community who have
>>>>> been working hard for years to make TLS stronger.
>>>> 
>>>> I would be willing to work with the people that did the formal 
>>>> analysis to show the impact of including the extension, and
>>>> making changes to the extension that are indicated by that
>>>> analysis.
>>>> 
>>> 
>>> IMO, that's not a good answer. When improving the security 
>>> properties of the protocol it may suffice. When weakening the
>>> protocol, I strongly believe the onus is on you to have done that
>>> work ahead of time, so that the damage you are proposing the
>>> Internet suffers is clear and known and not discovered years
>>> later.
>>> 
>>>>> 2. Which of the hundreds of applications making use of TLS did
>>>>> you analyse before proposing this? If only a handful, then same
>>>>> comment wrt where the onus ought lie.
>>>> 
>>>> Just like TLS 1.3 has been implemented and tested with many 
>>>> applications during its development, I would expect the same to 
>>>> happen in those environments where there is interest in making
>>>> use of this extension.
>>> 
>>> The TLS WG has spent an awful lot of effort on (I think) every
>>> single semantic difference between TLS1.2 and TLS1.3. (Ortt for
>>> example.) You are now asking that everyone else do work to figure
>>> out how your proposal damages their uses of TLS so that this
>>> supposed use case is dealt with. I think you and other proponents
>>> of breaking TLS need to spend that effort yourselves. (This is
>>> because as you know there is no way to limit the damage of your
>>> proposal to only the use-cases that are the claimed targets for
>>> this bad idea.)
>>> 
>>> So yes, those answers are as I expected and are just as 
>>> unsurprisingly, utterly unsatisfactory.
>>> 
>>> S.
>>> 
>>>> 
>>>> Russ
>>>> 
>>>> 
>>> 
>>> _______________________________________________ TLS mailing list 
>>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>> 
>> 
>