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

[Eric Rescorla <[e-mail]>]

"Mark Brown" <[e-mail]> writes:
> 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.

This makes some problems worse but some better. To the extent to which
one side's behavior is conditioned on the other's (E.g., I require a
signature before taking an action) then having the signature only at
the end causes problems. Plus, in Web contexts TLS connection
closure behavior can be quite complicated due to persistent connections
and bad TLS closure implementation.


> 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.  

But the problem is that doing it at the TLS layer entails not
really getting it right for most apps, for the reasons that
people have indicated so far--which is why signatures like
this traditionally go in the application layer.


> 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

I don't agree with this claim. The app needs to be cognizant
of many of these properties.


> 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. 

But this isn't about key management or key agreement. It's about
3rd party proof, which is something that TLS does not at all.


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

That's not what I suggested.


>> >> 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.

Yes, I'm quite aware of this point, but it's not relevant to what I
was saying, which is that it's not necessary to parse the handshake
in order to recover the plaintext: you just store copies of the
traffic keys and then you don't need to parse the handshake.


> 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, nobody is doubting tha it's attractive to be able to provide
third party evidence of what happened in a given transaction. That's
why so much work has been put into digitally signing application
layer traffic. The question at hand is where in the stack this
functionality should go.

-Ekr

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