On Sat, Jul 8, 2017 at 12:11 PM, Tony Arcieri <basc...@gmail.com> wrote:
> On Fri, Jul 7, 2017 at 6:02 AM, Richard Barnes <r...@ipv.sx> wrote: > >> You could avoid changing how the DH works altogether by simply exporting >> the DH private key, encrypted with a key shared with the monitoring device, >> in a server extension. (Not in EncryptedExtensions, obviously.) This >> would also have the benefit of explicitly signaling when such monitoring is >> in use. The only real challenge here is that the client would have to >> offer the extension in order for the server to be able to send it, which I >> expect things like browsers would be unlikely to do. However, given that >> the target of this draft seems to be intra-data-center TLS, perhaps this is >> a workable requirement? >> > > I very much like the property that by using an extension, the client must > consent to being MitMed. > > But in this case, why not just keywrap the session master secret with a > preshared KEK as opposed to exfiltrating the DH private key? > Actually, now that you mention it, something like that is probably necessary -- I expect that there are unstated requirements here to support for resumption (without having to find the previous session) and probably 0xRTT, and those modes use in a shared secret in addition to the DH secret. So you would need to exfiltrate the PSK as well. Looking at the key schedule [1], it looks like it would not be sufficient to send the master secret, since that wouldn't get you early data or handshake messages, but it would be enough to exfiltrate the DH and PSK secrets. Nonetheless, I don't think this significantly changes the proposed design. The interesting question is still whether opt-in is an acceptable requirement for the folks looking for a mechanism here. --Richard [1] https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.7.1
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
