On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley <hous...@vigilsec.com> wrote: > Nick Sullivan summarized > four concerns with that approach. See > https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg > > draft-rhrd-... addresses all four of these concerns.
This isn't quite right. One of the goals Nick outlined was "Decryption service only gets session keys, not master secret". The current design causes them to gain the handshake secrets, from which it is trivial to derive the master secret and other secrets [1]. This includes the resumption master secret and exporter secret. So aside from enabling MitM, this also enables session resumption by the decryption service, something that the security considerations neglects to include in its list. What, if anything, can be done with the exporter secret will need more thought. [1] draft-rescorla-tls13-semistatic-dh-00 and its OPTLS-based insertion of another DH exchange would prevent the decryption service from working for anything other than the handshake and 0-RTT. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
