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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

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


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls