On 07/17/2017 11:35 AM, Benjamin Kaduk wrote: > > So, in order to have something that is verifiably opt-in by both > parties, it seems like it would have to be a ClientHello/ServerHello > extension (included in the transcript for the generated traffic keys) > where both sides commit that they are willing to exfiltrate keys to a > given named entity(ies) (whether that's by raw public key, certificate > name, etc., is quite flexible). Because of the key schedule (the > traffic keys are produced after that point in the handshake), it seems > like such a scheme would require encrypting DH private values to the > third party (and potentially a PSK as well).
Whoops, a little too hand-wavy, since only one DH private value is needed to generate the shared secret. But it's "easy" to have some crypto that requires both contributions, especially if you are willing to modify the key schedule for the traffic keys. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
