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

Stephen Farrell <> Mon, 02 October 2017 22:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C37F1342AD for <>; Mon, 2 Oct 2017 15:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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] 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 qyEph0Ii9U_1 for <>; Mon, 2 Oct 2017 15:48:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 25CE4132D51 for <>; Mon, 2 Oct 2017 15:48:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDEDFBF66; Mon, 2 Oct 2017 23:48:43 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 927Hr-Y1v-uJ; Mon, 2 Oct 2017 23:48:42 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id B5437BF65; Mon, 2 Oct 2017 23:48:42 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1506984522; bh=xvlhPlzomEsB7oxb05Hqpt47ANVgex14sP73mMxMloA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pMF/6wfad6mNC/lgH575b4a5MT6RuBk505nJBq5pYckjuFYWf0Pv+nCsJGINI3olI De3KKRrlQKsyfEWaAVwDfFmAgsZVx1r8VREtcnXSPjeMiLwdFtpBJ1UmpRexk0fzSx Yoom7L8rV0xJ14x2oSCDQgURXqPV1mvcHG1cLbrM=
To: Russ Housley <>
References: <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Mon, 2 Oct 2017 23:48:41 +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="KW7JQK7o1oAcLh84GivLmDp39N2nQRRBF"
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: Mon, 02 Oct 2017 22:48:48 -0000


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.


> Russ