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

["Mark Brown" <mark@xxxxxxxxxxxxxxxxxxxx>]

Martin,

I think you're concerned about the HTTP GET side of my illustration, whereas
TLS Evidence here would be concerned about the POST.  I'm Ok to assume HTTP
is the app as you do:

> Browsers traditionally use up to 4 independent connections to retrieve
> parts of what composes a Web page as seen by the user, and that results
> in several parallel independent TLS-protected communcation channels.

I also agree with you that what is "seen by the user" may be the assembly of
multi connections' GETs within the browser (etc.).  But TLS Evidence doesn't
worry about that; what is "seen by the user" is simply out of scope.   TLS
Evidence only creates a factual record of what sent and received if and only
if both parties digitally sign the same hash values (hashes over the sent
and received data).

The POST is the target for TLS Evidence in this illustration.  And instead
of generating a lot of useless evidence like "user fetched another JPEG"
(app designer's choice here; I'm just making a suggestion), it would be more
efficient to only capture TLS Evidence over something like the last step of
a "checkout" sequence.  Specifically, app designers should use/require TLS
Evidence for precisely those outputs/pages of the app where the app server
generates and returns to the client the "ticket" in response to the client's
input.  In HTTP usage, that's when the buyer (controlling the stack from
user agent down, including TLS) creates a new HTTPS/TLS/TCP/IP session,
specifies the use of TLS Evidence in the ClientHello, and then uses HTTP to
send all of the current page's cookies, visible field data, hidden field
data, etc. to the web server as POSTDATA, and then receives the web server's
response.  Typically that HTTP session would be immediately torn down at
this point.

The TLS Evidence generated in this illustration would show what the client
sent in POSTDATA and how the web server responded to the POST, i.e., the
HTTP application data that the app server gave back in response to the
POSTDATA.  Within this illustration's parameters, that reply app data will
either contain the "ticket" or some sort of an error message.  That's due to
the app designer's choice of when to require use of TLS Evidence.  

The point of TLS Evidence's use within this illustration is that anyone,
even a third party, can easily show that a particular web server gave some
app data to a particular client (to the extent the PKCs can show
authenticity), and that app data is not a forgery (unless the digital
signature crypto was cracked).  The goal here is not perfection, but to
still be helpful.

--mark


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