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

Arnaud Taddei <> Thu, 05 October 2017 09:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BCEEE13292A for <>; Thu, 5 Oct 2017 02:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5cnmOo8P2Qdk for <>; Thu, 5 Oct 2017 02:14:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1D3212ECEC for <>; Thu, 5 Oct 2017 02:14:27 -0700 (PDT)
Received: by with SMTP id i124so805982wmf.3 for <>; Thu, 05 Oct 2017 02:14:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id x133mr5358554wmf.145.1507194866092; Thu, 05 Oct 2017 02:14:26 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id n191sm248445wmd.7.2017. (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 <>
In-Reply-To: <>
Date: Thu, 5 Oct 2017 11:14:25 +0200
Cc: Russ Housley <>, IETF TLS <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <>; 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 <>;
>>> 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