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

Richard Barnes <> Fri, 06 October 2017 12:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E37EB1349A5 for <>; Fri, 6 Oct 2017 05:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zYy8MCs9hU0H for <>; Fri, 6 Oct 2017 05:43:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A61ED132D18 for <>; Fri, 6 Oct 2017 05:43:27 -0700 (PDT)
Received: by with SMTP id k7so1957500wre.2 for <>; Fri, 06 Oct 2017 05:43:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Yp1RIJVak+Tq85LPq5BSylAoHWBc7OM9aPza80odD3g=; b=FkSmNLTUwgNAaG00Ks7exljAJazf5QchUGW+avTxmpAeEZhhn+72BdYFlptuowgo8r Th45/jND+JOKwduHcKlzTZfOZW/kfTJXwcy3XQyD1iL7y7XJHzvfA5N57RAVqZ46K419 kCh8wOQh7CeosqzZXtLSs49HNCWtZ2JbPyb+xcbW41IQYKNoy5oWdcCjkQGcab41Fm/W lP1EDIXtndFzk5QF1CuqIQTRo0Jzzlg2U90wyH30sQwBa0AhTQ9WRLBUlYFZ+jawQw8d F47JRRdcLKIIvjhikUrV5630L/gvz4OZ+/fMxlGDEjU133vOfq4rcIS32wPdxgBO9Ujl QG0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Yp1RIJVak+Tq85LPq5BSylAoHWBc7OM9aPza80odD3g=; b=YtHQDgJltRNZlSURtEJAZYRYdmqJGsE3+Su5ZZ1v7/vxHI93ixlkdr/6wUSYZWHDrn GStUm6DSmb6O7mb3WWBvjE7omSKTy6wr4e6C4f5wJxud1iAuxMHui7g0URaBH3/UuQ3a NZ9d6V4tNz363Lhe2KMlHq9GyLcv3nqGS7cck5GH/9WWPci7VrtGuixuogCIoWqmxYrB Pv/eL/u7corYciyLl2NMqri0C6zh5vcFoe4q8qENubxMhyKy5kL0dZTWFo4H+MQHoAnP du/eLQTMoD+LrZQqO5cGHHg3yj6b6xmY0NNucnZ29IqBSnV5wr8wF6jwHqrEGpIq62C7 sQ1Q==
X-Gm-Message-State: AMCzsaVk4+mERYS/ns35/Amoxhrfwj/H8RwQbY3Ki2zUvEX2DhFgzXNs Kogo9fmAxV8g3yy7xR2Sf1V7tqzRO3eHtRjqfVq7YA==
X-Google-Smtp-Source: AOwi7QD1zIQaUc2AoTKNND73f9Ru/AyEaCpdvqOqsIGg/v4PwyNFJ+r1OXJ8O5SJXzKeLhkcFQFTX8jJeNmy8bF/US0=
X-Received: by with SMTP id i28mr1932142wra.45.1507293806000; Fri, 06 Oct 2017 05:43:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 6 Oct 2017 05:43:25 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Richard Barnes <>
Date: Fri, 6 Oct 2017 08:43:25 -0400
Message-ID: <>
To: Ralph Droms <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="001a1141af52e10fce055ae02f61"
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: Fri, 06 Oct 2017 12:43:30 -0000

Hi Ralph, Russ,

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.

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 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.


On Mon, Oct 2, 2017 at 4: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