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

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

Martin, Eric,

Below is an illustration of how to use TLS Evidence for a brokerage
transaction.  I hope with this illustration I can address both of your
concerns about what data needs to be signed and retained, and using what
amount of automation.  In this example I am not using the start1, start2,
etc. alerts, since I suggested this earlier as a possible simplification of
the current draft. 

Eric Rescorla said:
> >> I think "not great" is quite an understatement here. You've just
> >> required that every TLS record write requires *two* signatures,
> >> one from the sender and one from the receiver. This includes
> >> record read/writes which the application doesn't even care
> >> about having evidence for. Your typical brokerage transaction
> >> requires 10s if not hundreds of separate HTTP fetches, each
> >> of which requires one or more record in each direction. Doing
> >> 25 digital signatures for every transaction is an enormous
> >> load on the server.

I suggested:
> > Turn on TLS Evidence only for one POST, skip the GETs.  There's
> typically
> > one important POST per transaction, the one before the
> > print-this-page-for-your-records response.  That's the page the user
> > typically prints for evidence of the transaction, despite its failings.
> 
> Yes, but *now* you're in the business of having the application
> require tight control of when signatures are created and when
> they're available, which brings us back to the situation I
> was complaining about in my initial review, where this isn't
> just automatic, it requires esxtensively modifying the
> app, plus the race condition/lockstep issues I raised in my
> original review.

So, Eric is concerned about situations where the creation of the signature
"isn't just automatic, it requires esxtensively modifying the app..." and
Martin is concerned about the situations where embedded within an
(automatically-created?) signature there exists "personal data" that is
captured without consent or is not necessary to the business purpose of the
transaction (and needs to be expunged later).  Can an application-data-blind
protocol extension like TLS Evidence address both concerns?  (Here I want
"blind" to mean that TLS Evidence doesn't peek into the application_data.)

Let me retrace Eric's line of thought first, using his broker illustration:

1) 100's of fetches to accomplish a trade:  In HTTP the TCP/IP session gets
torn down after every fetch.  So what is going on in Eric's scenario are
"hundreds" of TLS resumes, after an initial full TLS handshake.  

2) I'm proposing to do a full handshake using the TLS Evidence extension
only for the last POST, not the 100's of fetches prior to the POST.  That
is, not doing a TLS resume for the last POST but discarding the existing TLS
session and forming a new one.  Note that the HTTP app data is what actually
creates the user's sense of a session that persists over the hundreds of
fetches (and a few other POSTs).  That app data doesn't care if you resume
every time, do a full handshake every time, or any combination.

3) So I propose a minimum of two full-handshake TLS sessions, one that uses
TLS Evidence and one that doesn't.  In the brokerage scenarion, the TLS
session that does not employ TLS Evidence will be used for much more data
than the TLS Evidence session.  TLS Evidence will only be captured for a
typical brokerage transaction containing the client's POSTDATA and the
server's HTTP Response. (This HTTP Response will only contain
browser-readable HTML and cookies and not contain GIFs, JPEGs, CSS,
Javascript, ActiveX, etc., although it could contain references to any of
these.  All such references will need to be fetched by the client's user
agent, likely using TLS resumes on a TLS session that was used for the 100s
or previous fetches.)  

I believe this is normal user agent operation today, provided the normal TLS
session connects to a different domain name than the TLS Evidence session.
So in this illustration, I'll use a different DN for the "evidence" TLS
server than for the "secure" TLS server.  Using a different DN for a TLS
Evidence TLS instance than the DN used by the "normal" TLS instance is not
the only way to accomplish the required distinction between plain TLS and
TLS Evidence sessions, but I think it is the most backwards compatible
approach.  

Here's a proposed illustration for a simple use of TLS Evidence, for the
case of "Your typical brokerage transaction". 

A) Client may start at http://www.broker.com, without TLS.
B) Client logs into https://secure.broker.com, using some URL path (PKC 1 is
for secure.broker.com) and fires up a normal TLS session to host
"secure.broker.com".  In this illustration, authentication at this host is
done using user name and password at the application level, not at TLS
level.
C) Client interacts -- 100s of fetches, etc. -- using the normal TLS session
D) Web App designer has already changed the URL on the FORM SUBMIT action of
the one important POST so that it targets https://evidence.broker.com
instead of the "secure" server.  This obviously forces a full handshake
regardless of the TLS Evidence extension -- the old TLS session won't work
here because of the DN change.  Server must use PKC 2 for
evidence.broker.com.
E) client MUST have already been configured at TLS level in this way:
(Target) evidence.broker.com:443 = (PKC) clientEvidence3

This TLS client configuration line identifies one DNS name and port number
for which the client will always ClientHello using TLS Evidence.  Further,
for sessions with this DNS host the specified client PKC will be used for
signing the TLS Evidence.

To one of Martin's concerns, the TLS client is free to add or remove
Target=PKC TLS Evidence configuration lines at any time, or simply let his
PKC expire, or review servers for which he has configured Evidence, etc.
Client configuration could also record (in a third column) a URL at which
the client could request destruction of TLS Evidence.  Stronger
implementations could use a full URL/URI as the (Target).  I propose only DN
here because the current client API suggested by the OpenSSL s_client
command line interface is just a hostname, or hostname plus port.  This
configuration is on par with the configuration of trusted CA's, the
specification of the client's private key file and password, etc. in the
OpenSSL s_client.  So at this level of the existing API, the configurations
given to s_client are "trusted".  So the level of consent in the proposed
configuration is equivalent to the level of consent for which CA's to trust.

F) After connection, a TLS session using TLS Evidence exists.  Over the
course of time, between this client and the server with domain name
evidence.broker.com, you might see:

ClientHello1 (full handshake, TLS Evidence)
C: <a1.1> + Rq1.1 |                        | Rs1.2 
S:                | Rs1.1 + <a1.2> + Rq1.2 |

WHERE:
C = client
S = server
	The following are numbered by ClientHello then app_data sequence:
<a#.#> = application data
Rq#.#  = EvidenceRequest 
Rs#.#  = EvidenceResponse

So, this evidence session created Rs1.1 and Rs1.2 as evidence, and Rs1.2 has
the hash of <a1.1> in the app_data_received_hash (because TLS server
initiated this EvidenceRequest) and the hash of <a1.2> in the
app_data_sent_hash, and the hash of "ClientHello1 (full handshake, TLS
Evidence)" with evidence.broker.com in the handshake_protocol_hash.  Rs1.1
is pretty much obsolete now that Rs1.2 exists.

What if the app designers couldn't identify just one HTTP POST to capture
TLS Evidence for?  What if 100s more fetches were performed and the user
initiated a second brokerage transaction?  Then the following uses of the
evidence session might occur:

ClientHello2 (resume, TLS Evidence)
C: <a2.1> + Rq2.1 |                        | Rs2.2
S:                | Rs2.1 + <a2.2> + Rq2.2 |

ClientHello3 (resume, TLS Evidence)
C: <a3.1> + Rq3.1 |                        | Rs3.2
S:                | Rs3.1 + <a3.2> + Rq3.2 |

To one of Eric's concerns, in this illustration there really is no change
required for either the TLS client or the TLS server APIs (i.e. how the
application interacts programmatically with the TLS layer).  In this
illustration the client is configured via command line as described above.
Server may implement TLS Evidence using a command-line, config-file or
compiled-in option.  Whenever client interacts with
https://evidence.broker.com, TLS Evidence will be requested and created, and
if there's any problem the TLS session will get torn down, browser will say
page unavailable, and the back button will be used.  Resumes will still work
on the "normal" TLS session, which will be used independently of the
"evidence" session.

>From the perspective of the application deployment at the web server, they
may choose to host two web sites on the same machine (or not).  They may
develop the "evidence" page, i.e. the web application that accepts the
POSTDATA, using "normal" TLS.  They may choose to copy that web application
(CGI, JSP, ASP, servlet, etc.) from the "normal" TLS site to the "evidence"
TLS site.  They may even choose to allow users to select whether the user
would prefer to send their POSTDATA to the "evidence" or the "normal" site.
This would probably be a good idea in case any of their clients will ever
have difficulty with their PKCs.

To one of Martin's concerns, what data is actually preserved in this
example?  The TLS handshake, the POSTDATA sent by the TLS client, and the
HTTP Response "web page" (before any referenced documents like images, CSS,
scripts, etc. are fetched).  These three cases may only run afoul of laws
governing the retention of personal data in the data preserved in the
following streams:

1) the POSTDATA (i.e. form fields "filled in" by the user within the user
agent using the TLS session) may contain extraneous data fields that are
really not 
2) the HTTP Response data (i.e. the "web page" returned by the server)
3) The TLS Handshake data for this particular TLS Evidence Session

In the first case, the POSTDATA is fully determined by the server side,
which created the HTTP page and HTTP form which is being posted.  Of course,
the only data being posted are HTML HIDDEN fields, any relevant cookies (by
domain name, etc.), the fields within the HTML FORM tag which have been
further tagged as FORM fields and further, have been filled in by the user.
In this illustration, the broker created the blank FORM which the user fills
in.  This is simply a more widely used method of identifying the fields to
be used for evidence than the new tags Martin mentioned earlier as a
preferred solution:

Martin Rex said:
> Instead of having to redesign and rewrite the entire application protocol
> stack for every use case in order to accomodate what data will and
> will not become part of the TLS Evidence, one can make it a configuration
> option for the customer in the application.  So all of the attributes
> that the backend wants to get signed will be tagged as such in
> the request from the backend to the frontend.  Auxiliary information
> will go untagged and not be included in the signature.  Because
> the app knows what it wants signed, it can actually verify that it
> receives what it is looking for.

>From the customer's standpoint, the HTML FORM approach is nearly WYSIWYG,
except for the cookies and hidden fields.  From a legal standpoint, the form
designer at the brokerage will need to ensure that none of these fields
violate applicable laws when persisted.  

In the second case all of the HTML and cookies returned to the user are 100%
under the brokerage's control, as in the first case.  If the brokerage is in
the habit of returning transaction receipts to their users that are illegal
for some entities to persist then it makes more sense to change the HTML &
cookies returned than to continue to risk breaking the law.  This is a
matter of correctly implementing the business requirements into the
application, and really isn't the concern of the TLS layer.  It is,
arguably, fairly easy for the broker to change the dubiously-legal HTML
application, and it is clearly the broker's responsibility.

In the third case, a normal SSL/TLS handshake already has the capability to
authenticate a PKC, and it already performs HMAC over the application data.
I would be surprised if any nation has passed or will pass laws that made
TLS records illegal to store / audit.  However, even where such laws are in
force, TLS Evidence can still be used simply by truncating any of the
application data records and/or TLS handshake records as described below.

Finally, all three of these audit streams -- app data sent, app data
received and TLS handshake -- are severable.  If the app data sent by the
client needed to be destroyed upon request by the user, then it could be
destroyed without ruining the digital signature set.  Same for the other
streams.  In fact, if an entity only persisted the TLS Evidence
EvidenceResponse structure and none of the streams, it would still hold a
fairly strong method of falsifying any fraudulent claims.  For if a
frivolous opponent chose to claim that a specific set of app data sent, app
data received and TLS handshake took place, the brokerage could simply
challenge that assertion and say, "Prove it: we've retained evidence over
every transaction we've authorized; let's see if your claim matches any
transmissions we've processed for your PKC."  This approach may even reduce
the overall burden of data retention on the brokerage, since the
EvidenceResponse structures are relatively small.

In summary, TLS Evidence can be used to falsify frivolous / fraudulent
claims without storing any application data or handshake streams.  TLS
Evidence can be "turned on" and "turned off" by using a DNS domain name, and
this approach follows not only the traditional SSL/TLS API but also the
Berkeley sockets API, so it is legacy compatible.  TLS Evidence, used as
described, requires the TLS Client to maintain a trusted configuration store
that matches client certificates to the domain names at which those
certificates should be used, and this whitelist follows the same conventions
as the existing trusted CA configuration process.  Martin points out a good
legal motivation for only generating TLS Evidence when you REALLY need it,
and storage considerations also encourage this approach; I strongly agree
that TLS Evidence should be "turned on" only when a core-to-the-business
transaction needs to be recorded.  I expect these three motivations -- which
I summarize as relevant legal constraints, business needs and security goals
-- will work together to help TLS Evidence users make the right decisions.

--mark


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