Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101

Stephen Farrell <> Tue, 13 March 2018 22:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C6F1126E64 for <>; Tue, 13 Mar 2018 15:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Status: No, score=-4.31 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, T_RP_MATCHES_RCVD=-0.01, 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 bwZ1lJ73-c0b for <>; Tue, 13 Mar 2018 15:53:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B34FE126DFB for <>; Tue, 13 Mar 2018 15:53:58 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97145BE2F; Tue, 13 Mar 2018 22:53:56 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M0FSxRfYzXDM; Tue, 13 Mar 2018 22:53:55 +0000 (GMT)
Received: from [] ( []) by (Postfix) with ESMTPSA id EF7AFBE47; Tue, 13 Mar 2018 22:53:54 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1520981635; bh=FsCsRTcvU9wr3DaMp8tQoc7QR3OYCWXMwN4j3oaRWdY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=0HIH22u/AgY5FZneTkBO2D8XWcEjT57P7kyIkep2ELSmyZJMC8wScn0+UUcMfwIzY Ttubl+LTbiRUCRx67pqhMxaqP0toSPN84dxufJ+HiWEBHKZH/1vixHPvLxqiawmP08 +pe31Defw7Px3nah83eDzl2vAtnF/okjs4nd0ABY=
To: Russ Housley <>, IETF TLS <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Stephen Farrell <>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Message-ID: <>
Date: Tue, 13 Mar 2018 22:53:54 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sLydEpaJz4BAcEL4Aa01jkH1tRK9D2mG5"
Archived-At: <>
Subject: Re: [TLS] draft-rhrd-tls-tls13-visibility at IETF101
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: Tue, 13 Mar 2018 22:54:01 -0000

Hi Russ,

On 13/03/18 21:49, Russ Housley wrote:
> The Prague discussion was about draft-green-...

Much more was discussed than just that one dead draft. In particular
see the minutes for the more general question posed by the chairs.

> Nick Sullivan summarized four concerns with that approach.  See 
> draft-rhrd-... addresses all four of these concerns.  We had some 
> discussion on the mail list, which lead to -01 being posted.

The problem you have however is that you're trying to square a
circle, so picking any set of N objections to try to address will
still leave you ending up with something unacceptable, for at
least one of a bunch of reasons. Partly, that's because you need
there to be a boundary between a data centre and the rest of the
Internet that's meaningful to TLS, and no such boundary exists.

(So the answer to Nalini's problems is: for applications causing
you this particular pain within a data centre don't use TLS,
find another way and while that might be painful for Nalini's
consortium, it's the right answer, given the overall costs of
anything else.)

> I do not know if the TLS WG will want to adopt this approach.  I 
> would like to find out.

Did you read the list traffic from Oct/Nov? I have no idea how
you can be in doubt if you did. It's readily apparent that your
draft has not caused a lot of people to change their minds. Do
you agree? If so, then the conclusion is obvious, isn't it?