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

Russ Housley <> Thu, 12 October 2017 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CBF513208E for <>; Thu, 12 Oct 2017 13:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RrfZ5u290S2m for <>; Thu, 12 Oct 2017 13:21:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 60B35126B6E for <>; Thu, 12 Oct 2017 13:21:21 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB9C3005A6 for <>; Thu, 12 Oct 2017 16:21:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10026) with ESMTP id He_Z-bo8ld5E for <>; Thu, 12 Oct 2017 16:21:19 -0400 (EDT)
Received: from a860b60074bd.home ( []) by (Postfix) with ESMTPSA id 4A0DC30050A for <>; Thu, 12 Oct 2017 16:21:19 -0400 (EDT)
From: Russ Housley <>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 12 Oct 2017 16:21:18 -0400
References: <> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3273)
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 20:21:23 -0000


> Thanks for the update here.  I agree that this is an improvement over draft-green-tls-static-dh-in-tls13, in particular because (1) it has a mechanism for mutual consent and (2) it only touches the outputs of the handshake, not the inputs.


>  A couple of points to consider: 
> Like sftcd, I would like to see some modeling to verify that this has the expected properties.  (Unlike sftcd, I'm not sure this needs to be done at the start vs. before it's finished.)  It seems straightforward enough that I don't expect major issues, but it would be good to check.

I agree.  I'd like to confirm that the extension has the expected properties, but I'm more willing to do that work if the TLS WG adopts the draft.  This is the order that was done for the TLS 1.3 specification.

> It's worth noting that the approach here is all-or-nothing, in contrast to designs like mcTLS (  The entity to whom the keys are exfiltrated can make modifications to the session in addition to reading it.  I think this is probably the right trade-off of simplicity vs. solving the problem, but maybe it's worth considering, say, a cipher suite with AEAD plus an additional integrity check, so that you could exfil the AEAD key and not the integrity key.  That's pretty much what we've done in the PERC WG with draft-ietf-perc-double to allow middleboxes to make some changes to an SRTP packet.

I watched the video of the presentation, and the granularity comes at a pretty high cost.  In fact, mcTLS was designed with TLS 1.2, and the cost would be higher for TLS 1.3 because of the AEAD.  The current extension targets a more simple approach, where after client opt-in the session secrets are shared with other parties that are in the same administrative domain as the server.

> I don't think the spec is quite interoperably implementable in its current state, since it's missing important details on how the wrapping is done (what AEAD algorithm? how do you make an IV?).  This is obviously something that can get worked out in WG, should we decide to adopt this draft.

I am willing to work on adding those important details.