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

Stephen Farrell <> Wed, 25 October 2017 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D11913F48A for <>; Wed, 25 Oct 2017 16:10:54 -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 pYLoB0DhufXE for <>; Wed, 25 Oct 2017 16:10:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40E3D13F46A for <>; Wed, 25 Oct 2017 16:10:50 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE9DBBE5B; Thu, 26 Oct 2017 00:10:48 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9-4Tv4XP0l0M; Thu, 26 Oct 2017 00:10:47 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 077E7BE58; Thu, 26 Oct 2017 00:10:47 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1508973047; bh=/xCBq2pvd5eC4jZStIWfE6ZemNpt4tsBGqbdhOwiNuQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NKDgs5EAtMRk3RgIcq/8NkLqC5mxU8KG9sI8nf+siu+8nAxN9ArqiP4CKe8tmbaIF aZTw2bvmTAGwHWr4hCZUWuf0AUlhTzJwt6np9qctxPv0ujElFAvOzG+2/OeJUk9XMh EmVQLECM5e65QjPsEbRMMfa6NIt+mtL0UgvSF+YA=
To: Peter Bowen <>
Cc: Richard Barnes <>, "<>" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Thu, 26 Oct 2017 00:10:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6SNdfdgoubO8QEE9JgVT33erjQ3khGIhb"
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: Wed, 25 Oct 2017 23:10:54 -0000

On 25/10/17 23:58, Peter Bowen wrote:
> So, to be completely clear, no one is arguing that Nick's three
> options (quoted below) are wrong or do not work.  The objection is
> that the IETF should not be publishing a RFC that documents them, is
> that right?

No, it's not that simple.

For myself, I disagree with some aspect's of Nick's analysis, which
we can go into as needed. I don't think that's needed in this mail.

On your second point...

The IETF has a range of policies (BCPs etc) that call for use of
strong and not-weakened cryptography in protocols. Some of that
is mentioned in places at [1] but I'm sure a more complete job
could be done. There are sound technical reasons why the IETF has
consensus on a bunch of those positions. For some of those, it
is also true that the consensus has always been rough, e.g. I
think it's true there have always been IETFers who would actually
like to MitM security protocols for what they consider good
reasons. (That doesn't make those people either bad or correct.)

One particular relevant RFC (2804) does explicitly envisage that
people who want to do snooping might document their ways of doing
that in independent stream RFCs (which are not IETF RFCs despite
almost no RFC-readers grokking any difference there;-). But in
this case the authors say they want standards-track. And in the
previous case, from talking with Russ, he didn't see any benefit
in the independent stream route (which I didn't understand at the
time tbh).

So the situation is actually sort-of clear, but not simple. It's
true that appreciating the clarity requires quite a bit of IETF
lore ;-)