On Tue, Jul 11, 2017 at 05:16:31PM -0400, Ted Lemon wrote:
> On Jul 11, 2017, at 4:58 PM, Ted Lemon <mel...@fugue.com> wrote:
> > On Jul 11, 2017, at 4:31 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie
> > <mailto:stephen.farr...@cs.tcd.ie>> wrote:
> >> I'd bet folks would invent proprietary
> >> ways of avoiding detection, that deviate from the "standard"
> >> and that perhaps make crypto worse all around. Say by deriving
> >> secrets from some function f(exfiltrated-secret, time, count)
> >> for a small counter or some such and having the decryptor of
> >> the wiretapped packets hunt a bit for the right key.
> >
> > Hm, well, but that would be catnip for security researchers,
> > particularly if it weakened the key. But yeah, you're right, that
> > does make detecting the attack possibly impractical aside from as a
> > large research project.
>
> On second thought, this suffers from the same problem as the
> many-static-keys problem: there are too many moving parts. This
> requires all clocks on all servers and interceptors to be in perfect
> sync, not just close, or else potentially halves the performance
> during clock skew overlap periods. It requires every server and
> interceptor to implement the same algorithm. And you still have to
> distribute the information from which the key is derived.
If TLS 1.3 still has server nonces (does it?) then those could be used
to provide enough information to reconstruct the server's ECDH key given
access to a base secret (per-host secret, say)... Alternatively could
one use some extension to signal such information? After all, if one
wishes to decrypt past sessions, presumably one is recording them, so if
the transcript gives you the bits you need...
Or one could also just construct a protocol by which to quickly log
{transcript_hash, session_key} encrypted to the log sink.
Or {transcript_hash, counter/nonce for ECDH keygen} -- this doesn't need
to be encrypted, which simplifies key management for the escrow system,
though it also makes past sessions vulnerable to host compromises.
If synchronous, reliable escrow is not required then one could
immediately send a UDP datagram to the sink and use background
retransmission as needed if one wants reliable escrow. One could even
just syslog the darned thing. If reliable escrow is required then hold
the connection until the sink ACKs the escrow message.
This is a very simple design for session key escrow. It requires a sink
and storage, granted, but that's pretty cheap nowadays, you almost
certainly have such sinks, and, besides, if you're interested in
decrypting sessions after the fact then you're recording entire sessions
anyways, so storage-wise a session key escrow system is no big deal.
Note that such a system would be completely undetectable from a client's
point of view. It's a server-side CALEA-like "port" enabling
eavesdropping by authorized parties. One could not prove that the
server does not do this without access to the server.
Such an escrow-via-logging approach works no matter what TLS 1.3 looks
like on the wire. More than that, it works for all client-server
protocols for that matter: SSHv2, Kerberos, SCRAM, whatever. All you
have to do is specify what goes into the transcript hash for each
protocol, and what bits to include for key escrow. Universal session
key escrow. What's an intranet not to like, right?
The best thing about such a scheme is that it completely sidesteps all
this entire "it's wiretapping" "no it's not" "yes it is" "nuh uh" ...
thread. One might want to standardize a key escrow logging protocol --
why not? Maybe not at the IETF, or maybe in a WG just for that purpose.
I don't have a problem with that.
I also don't have a problem with draft-green-tls-static-dh-in-tls13
provided that it be published as an Informational RFC. After all, it
documents a method that a) doesn't change TLS on the wire, and which b)
clients have a hard time deciding when to refuse to talk to a server
that appears to implement it. Sure, it breaks the spirit of TLS 1.3,
but that was always possible, with or without an RFC.
I might not even have a problem with draft-green-tls-static-dh-in-tls13
as a Standards-Track RFC. Not publishing doesn't prevent implementation
reuse of ECDH keys, and publishing doesn't cause reuse of ECDH keys to
be required. My only objection to publishing on the Standards-Track is
that Informational seems much more appropriate given that the
contents... is purely informative, lacking even a reference to RFC2119,
much less normative RFC2119 keywords.
Too much ado about nothing. The best solution here is for the authors
to acknowledge the informative/non-normative nature of their I-D and
take it to the ISE as an FYI. Done.
Nico
--
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
