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 <rdroms.i...@gmail.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
