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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Happy New Year, all.  I'm responding to Eric's initial questions, and I will
avoid topics not relevant to TLS and this group.

Eric,

I think you're right about the problems with the start1, start2, end1, end2
alerts.  They could cause deadlocks, seem to require and multiply
application-level interactions, and chew up alert space.  I'd be open to
abandoning them.  Removing these from the drafts would require some other
changes, perhaps removing any kind of reset over the application data sent &
received hashes, etc.  But removing these alerts would simplify several
things, which seems good.

Also, I think the alerts issue and some other unclear parts of the -00 and
-01 drafts led to some misunderstandings about how TLS Evidence works.  Let
me get back to this in a later email.

Most important, why should TLS WG do this?  Overall, it would be
advantageous to some users to use TLS's crypto to preserve a record of
communications, that is, the bits and bytes that were actually sent and
received.  More specifically, Why should TLS be chosen as a good place in
the 7 layer stack to create this record / evidence of what was actually
sent/received?  

1) Do it once at TLS, and get it right for lots of apps, don't reinvent the
same idea in many standards / apps.  The basic issue of creating a
mirror-image / forgery-resistant record may be useful to most Internet app
protocols.  
2) The TLS layer is the better place to manage keypairs, put crypto
algorithms (TLS vs. the O/S, not app layer, is an equally good question),
verify PKCs within an Internet communications context, and assure crypto
correctness vs. the app layer
3) The TLS handshake guards against replay attacks.  Now that TLS Evidence
and Supplemental Data exist it may contain other relevant and useful TLS
Extensions in it, and you don't get access to this data at the app layer
4) It's better to provide a wide variety of crypto options (using TLS) than
to use just one or two algorithms.  TLS offers one of the best selections of
cipher suites available.  If evidence is implemented at the app layer, each
app will face cost issues that promote their selection of "just the best
crypto algorithm" leading to brittle reliance on that algorithm and
incompatibilities between apps.  Moreover, key agreement and key management
is what TLS does very well and is hard to do well. 

Certainly a choice exists here: should we try to record what the app and the
user "thinks" or "intends" or should we try to record what was, objectively,
sent and received.  TLS Evidence aims at the latter.  Given this choice to
focus, objectively, on the app data that was sent / received then the way
that data looked just before it was encrypted (and HMAC'd) is a good place
to "watch" the data.  The TLS location is a good place to try to avoid "he
said / she said" arguments -- the TLS HMAC ensures that what was sent was
what was received, if anything was received at all.  But, as I point out
below, just storing the TLS packets including their HMAC isn't too durable
against forgery attempts (on the basis of TLS crypto alone). 

More generally, why is -evidence useful?  Here's my mission statement for
TLS Evidence: There are times when parties would like to have a record where
crypto was used so that the objective record of what was sent/received
resists forgery.  

Here's an example to motivate why someone might want an un-forgeable record.
Say you're buying tickets to a popular concert/movie/etc. online (i.e.,
limited inventory situation).  In this case you (buyer) might care even more
about getting a ticket than its price.  So when you show up at the venue you
want your electronic tickets / records of sale sustain a fair verification
effort that they are not forgeries.  You do not want the venue manager to
say, "Sorry, we don't have records of this transaction..."

Simply printing out records from a browser that bear a "https://"; prefix in
the URL (etc.) does not preclude forgery.  Also, if either or both parties
retain the full TLS session data, that doesn't preclude forgeries either
(even in the case of TLS mutual authentication; more on this below).
However, the design of TLS Evidence is that if one or both parties retain
the full TLS session data then verification is quick and easy.  A user
should be able to download the TLS session data to his/her handheld/mobile
computer and take that record instead of tickets, in the example above, and
sustain a fair verification by the doorkeepers to the venue.  (If the
doorkeeper has lost the record, then the user can either use software that
is accessible to the handheld and that passes muster, e.g. a well-known
website, or the user may share the TLS session data for the doorkeeper to
verify using the doorkeeper's software, e.g. email it.)  Here, the crypto
properties of the record make it so that anyone's copy is a good copy and is
sufficient to stand up to scrutiny.  The crypto properties make great
records/evidence relatively cheap to create, and you don't need to keep the
records on secure hardware or in a vault.  Again, it's the crypto not the
storage practices that make it a good record.

It was suggested earlier that just storing the traffic keys is useful
evidence in some cases.

> >> Why not just store the traffic keys?

I don't think this helps very much against claims of forgery.  That's
because the symmetric secrets derived from the TLS Pre-master Secret
(including client MAC, server MAC, client write, server write, client IV,
and server IV) are available to _both_ parties.  Both parties may write data
as if they were the other.  So it is easy for both parties to change the
record at any time after the fact.  Either can attack the TLS record between
the handshake and the first packet of application data.  First cut the
packet record between the last FINISHED message and the first application
data record and throw away the old application data (or set it aside to use
as a template).  Now, take the handshake and splice onto it any application
data you want -- making sure to use both TLS client's and server's MAC,
write and IV secrets as proscribed by the specification.  To add realism,
the attacker has the old record of what was actually sent & received so the
attacker can reuse any bits of that record to make the forgery look more
realistic.  My point here is that the cryptography used by SSL/TLS doesn't
preclude forgeries made by client OR server, it only deters third parties
from making forgeries.

I will respond to your detailed comments in another email (this one is long
enough).  I will also supply an example of the TLS Evidence protocol for
this "Sure you can verify my tickets" use case.  

-mark


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