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

Hubert Kario <> Thu, 12 October 2017 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0F5C1344BF for <>; Thu, 12 Oct 2017 05:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id X9R1H2_TsRyn for <>; Thu, 12 Oct 2017 05:57:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 397AC13305F for <>; Thu, 12 Oct 2017 05:57:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3FC8C04AC46; Thu, 12 Oct 2017 12:57:38 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 D3FC8C04AC46
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=fail
Received: from (unknown []) by (Postfix) with ESMTPS id 50BAC62940; Thu, 12 Oct 2017 12:57:38 +0000 (UTC)
From: Hubert Kario <>
Date: Thu, 12 Oct 2017 14:57:28 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3026514.Y3xAIzhxBm"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Thu, 12 Oct 2017 12:57:40 +0000 (UTC)
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, 12 Oct 2017 12:57:42 -0000

On Thursday, 12 October 2017 00:24:36 CEST Ion Larranaga Azcue wrote:
> I'm a newcomer here, so I may be wrong in some aspects (I apologize in
> advance for that) but at least I'd like to give my opinion...
> I really don't feel confortable with the approach taken in this draft. Most
> of the proponents of these kind of "tapping" limit their scope to
> datacenters, but I agree with others in that it should be treated as if it
> will be used on the internet as a whole (as the specification does not
> prevent this kind of use, and we can't know how users and hosting companies
> will react to this functionality being available).
> It's true that with this approach the client has to opt-in but once it has
> opted-in, the client has no control over which third party the encryption
> keys are passed to. Imagine a client opts-in because he knows there is an
> IPS within the network and the company hosting the server asks him to (I
> know at least one of our clients would certainly consider this). But some
> time later a malicious third party manages to coerce the hosting company to
> provide the keys to them instead (or in addition to) the IPS. From the
> point of view of the client, he wouldn't notice anything different (only a
> change in the key identifier but could be due to key renewal)...
> I think a way to solve this would be involving the client more in the
> visibility negotiation. For me, the client not only has to opt-in to the
> tapping, but should also have the possibility to unambiguosly identify the
> tapping third-party and accept or reject the connection accordingly. I had
> some naive idea for this but I was unable to accomodate it in the handshake
> as it is currently defined (in fact, I don't think this kind of control for
> the client can be provided without major changes to the handhsake
> protocol).
> I also don't like the way security so greatly depends on SSWrapDH1 (as
> addressed in point 6 of Security Considerations). I expect many
> administrators will create long-lived keys in order to avoid the work to
> have to redistribute them, leaving connections open to attack during months
> after they take place (until SSWrapDH1 key renewal)...
> Anyway, I think key life length could be addressed in later drafts, but the
> inability of the client to identify (and possibly reject) the tapping third
> party is a "no go" for me...

yes, a three-way DH with two certificates (one IPS one EE server) does seem 
like a much better approach, especially if IPS certs need to have special 
flags that make them useless for anything else and cannot be set by CAs in 
public CA programs.

>    Ion
> ________________________________
> De: TLS <>; en nombre de Nick Sullivan
> <>; Enviado: lunes, 9 de octubre de 2017 22:49
> Para: Ralph Droms;
> Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
> Ralph and Russ,
> This draft addresses the two main concerns I had with draft-green:
> 1) Client opt-in
> 2) On-the wire visibility
> There are clearly some details missing from this draft (such as how Ke is
> used as a symmetric key), but generally I think this approach is more
> explicit and therefore less likely to unintentionally impact the broader
> internet if used in the datacenter setting.
> Nick
> On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms
> <<>> wrote: We are about
> to publish draft-rhrd-tls-tls13-visibility-00.  The TLS extension defined
> in this I-D takes into account what we heard from the discussion regarding
> TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague.
> Specifically, it provides an opt-in capability for both the TLS client and
> server and makes it clear on the wire that visibility will be enabled for
> the session.  The new mechanism does not depend on static handshake or
> session keys.
> - Ralph and Russ
> _______________________________________________
> TLS mailing list

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic