On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon <mel...@fugue.com> wrote:
> It’s also true that you can just exfiltrate every key as it’s generated,
> but that’s not what’s being proposed and would not, I think, suit the needs
> of the operators who are making this proposal.
>
> I don’t see how you could mitigate against deliberate key exfiltration.
> At some point you really are relying on the security of the endpoint.
> But being able to detect repeated keys is useful for preventing pervasive
> monitoring: it requires the monitored either to have access to the key
> generation stream in realtime, or to request the key for a particular
> conversation.
>
Much of this conversation seems to conflate wiretapping with collaboration.
2804 has a clear definition of wiretapping:
q( Wiretapping is what occurs when information passed across the
Internet from one party to one or more other parties is delivered to
a third party:
1. Without the sending party knowing about the third party
2. Without any of the recipient parties knowing about the delivery to
the third party
3. When the normal expectation of the sender is that the transmitted
information will only be seen by the recipient parties or parties
obliged to keep the information in confidence
4. When the third party acts deliberately to target the transmission
of the first party, either because he is of interest, or because
the second party's reception is of interest. )
This proposal (and related proposals involving encrypting session keys to
inspection boxes, either in-band or OOB) violates condition 2 because one
endpoint would have to intentionally take action to deliver the session key
or private DH share to the third party. If one endpoint is feeding
cryptographic material to a third party (the only way that information gets
out to the third party, vulnerabilities notwithstanding), they are
collaborating, not enabling wiretapping.
(I'd argue the inspection box also fails to be a third party, as it is part
of the infrastructure of one endpoint, but that's largely irrelevant to the
question of whether this is wiretapping once we've determined the delivery
of keys is not a secret.)
I think this issue of static DH being an attack (maybe; not taking a
position) is something of a red herring, because shipping individual
session keys to a third party like a government doesn't add any substantive
hurdle beyond shipping them a single static DH share. That said, I agree
that an infrastructure for detecting the loss of forward secrecy, perhaps
in a CT-like manner, may make sense to protect against unintentional key
compromise or compromise of one endpoint: the problems that forward secrecy
is intended to address, which specifically do *not* include collaboration.
Kyle
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
