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

[Richard Barnes <[e-mail]>]

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 (https://mctls.org/).  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.

--Richard



On Mon, Oct 2, 2017 at 4:31 PM, Ralph Droms <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>