Subject: Re: [TLS] Please discuss: draft-housley-evidence-extns-00

From: Martin Rex <[email-masked]>
Date: Mon, 8 Jan 2007 19:39:54 +0100 (MET)

Mark Brown wrote:
> 
> Ephemeral RSA?  I hadn't thought about that.  In Rescorla's book it seems to
> be a tweak used to adapt to US export limits (512 bit RSA keys for export).

Almost all of the code is already present in existing implementations
in order to support the SSLv3 RSA_EXPORT key exchange methods with
server certs using >512 bit RSA keys.

The weakness in current SSL/TLS with the regular RSA ciphers is,
that when you get your hands on the private key of the Server, then
you can decrypt all archived encrypted sessions that were established
with that key as well as passively attack all new sessions that are
being established with that key.

With temporary/ephemeral RSA keypairs, recovery of previous session is
no longer possible after the server has replaced (and securely purged)
the temporary keypar, and simple passive attacks don't work, either.
An active MITM attack or access to the temporary keypair is required
to attack the communication at the network level.

When the servers longterm authentication keypair is also used directly
for setting up the session keying material, it becomes a much more
attractive target for brute force attacks, for key-stealing and for
secret or non-consensual key-escrow.

-Martin

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: "Mark Brown" <[email-masked]>
Date: Wed, 10 Jan 2007 20:21:10 -0600

Martin, David,

I think you already cleared this up for me.  Here's my recap:

> What is the difference between a "network trace"
> and a "wiretap"?  An application architecture that stores trace data 
> does not require modification (hooking) of the protocol.  And a 
> modification to the protocol to transmit digitally signed data changes 
> neither the confidentiality properties of the protocol nor the 
> existence of application architectures that store trace data.

When I spoke of a wiretap, I meant viewing only what an attacker can see
whenever a TLS session passes through the untrusted network -- the TLS
packets.  In TLS for RSA case, if you possess the server's private key you
should be able to revisit all of the handshake messages (recorded, for
example, as raw IP packets using a network trace or other "wiretap") and
repeat the key derivation and HMAC calculations etc. for that session; so
you can get cleartext from a wiretap if and only if you have access to the
server's private key.  We raised this in the security considerations, 6.2,
last paragraph:

   An alternative cryptographic mechanism is to save the TLS session
   itself.  The negotiated TLS ciphersuite was already used to protect
   the Application Data messages, and the Handshake Protocol messages
   contain the keying material necessary to decrypt them if the party
   retains the private keys and/or pre-shared secrets.

What I meant to say earlier is that this approach (above) works well to
preserve the TLS Evidence.  If you choose this approach (above), call it the
"wiretap" TLS persistence model, then the server application has no need to
interface with the TLS layer for the purpose of obtaining the TLS Evidence.
It can if it wants to.  

So there exists a scenario where the server application could use an
unchanged API (with the TLS layer) and yet TLS Evidence could still be
configured, generated and retained (here, by the server's organization).
This is a minimal server-app-impact scenario.

The point of the Security Considerations in 6.2 is to tell people, "Be
careful with your cleartext!"  TLS Evidence suggests ways for implementing
systems to avoid spoiling the confidentiality of the cleartext.  

--mark