Richard: > 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.
Thanks. > 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 (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 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. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
