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

["Mark Brown" <[e-mail]>]

Martin,

I see some misunderstandings:

1) Application data is fully opaque to TLS Evidence.  This is a fundamental
principle we both agree on.

a) Application data is so opaque to TLS Evidence that it could just as well
be encrypted when hashed by TLS Evidence, and the resulting digital
signatures would serve users as I've proposed.  Although the digital
signatures would work fine, most users would want to know what the cleartext
app data was too, so draft -01 currently hashes cleartext app data.

a) TLS Evidence doesn't know or care if the application data contains a
button clicked event, be it recorded as "OK", or "0" or "0xff3456ab" or
"button 0x200".  It never looks inside at app data, it just hashes & signs.

c) Making sense of the app data, handshake messages and digital signatures
is a forensic task, not something TLS Evidence implementations worry about.
This forensic work will be done some time after the transaction occurred,
not inside the crypto protocol as the transaction occurs.  I hope to make
forensics easier simply by laying out a clear record of what bits actually
got sent by whom.  TLS Evidence has no idea "what it all means" but
designers can configure TLS Evidence systems so that the record is
reasonably clear (they likely won't get it perfect, and that's a limit that
TLS Evidence accepts).  

The kind of design work I propose for users of TLS Evidence is analogous to
writing intelligent debugging trace outputs -- the intelligence here is to
make the record clear so if the software unexpectedly goes belly up, you can
put together a good guess as to what happened.  I believe that people will
benefit from having the option/ability to "turn trace on" for their
important transactions.  Both parties MUST agree first, as the ID makes
clear at a number of points.  But that's what I think TLS Evidence should
do, a lot like setting up Ethereal for a TLS session and creating two
digital signatures over the tracefile.  Sure, I hold the opinion that people
can employ TLS Authorizations so the tracefile is more useful -- might even
help show intent.  But TLS Evidence doesn't propose any magic/legal tricks.

2) TLS Evidence is incompatible with the "Click-through" aspect of
click-wrap licenses, but it's not incompatible with existing laws.  TLS
Evidence requires client authentication, which doesn't just mean some PKC
but a PKC that the server knows (i.e. can authenticate).  You have to
install the right PKC first.  You can't just use any PKC you have on hand
and expect to get in to some server that's demanding client authentication.
Even if it did, and your TLS client accidentally authenticated to the
server(?!?), you will still need to configure "turn trace on" and choose
acceptable crypto before evidence happens.  TLS Evidence gives you two
out-of-band ways to confirm "Are you sure?  Are you really sure?"  This is
the opposite of a casual in-band click wrap.

I hope that puts us on the same page.

--mark


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