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

Stephen Farrell <> Thu, 05 October 2017 09:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 285FE1332F2 for <>; Thu, 5 Oct 2017 02:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MKW7QKtuCkJm for <>; Thu, 5 Oct 2017 02:12:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A7E6D134557 for <>; Thu, 5 Oct 2017 02:12:19 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A01A1BDD8; Thu, 5 Oct 2017 10:12:15 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TvxwGJDWYwnW; Thu, 5 Oct 2017 10:12:15 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 5ADB4BDCC; Thu, 5 Oct 2017 10:12:15 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1507194735; bh=/+m2N5I5MMOfQuuC4kamNFRxBtzqBgxPvi8RMUVBT+w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BTAK9hhogpOB2yHSt+/xHH4DzyUKyhXvFEp6rxSatoGSIYTD6WXrOHjCxyKFWbLVi Dl6O2QGSvN+gUOIUgB+wj/6tROPhghe+gDhUJqeuVzd5Qc51F5XR611uFTV0W10ogX l+8NePLlqo4lfBvJZYjv+RASgL3sVQmXPAO49xAg=
To: Arnaud Taddei <>
Cc: Russ Housley <>, IETF TLS <>
References: <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 5 Oct 2017 10:12:04 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9DOK8IvOW2aHvLgoX5U7ncRdhwrKjwBEo"
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:12:30 -0000

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.


> 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