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

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> My latest machine happens to have an Infineon TPM chip in 
> the motherboard, that "assists" the IE7/Vista perform the 
> "trusted path" feature of that OS (as described in an 
> earlier missive addressing UI Popups that control 
> interaction with rendered HTML pages). The TPM chip is 
> (amongst other roles) a motherboard-based RSA HSM. The 
> associated windows CSP helps https (in Windows OS) perform 
> the client auth operation in SSL.

The "secure trust path(es)" in Windows (Vista) might be sufficient
to apply digital restrictions management to "premium content"
but it is insufficient for "digital signatures" replacing traditional
end user signatures.

For that, you will need a secure trust path between the user(s intent)
and the digital signing device, means that it must include the
entire visualization device and the user input device(s) which
can add to that data pre-signature and which can trigger the
signature generation.  The visualization device is actually the
more important part, because it will provide
(application-specific) preformatted data that is to be signed.
Keep in mind that the entire visualization device must be
trusted, not just the path to it.


I've been asking several interesting questions about TLS Evidence
that have gone unanswered so far:

  - applications that receive communication with significant
    preprocessing by middleware have absolutely no chance
    to verify now or later whether a received application-level request
    matches the contents of a signed TLS Evidence blob.  Not when
    receiving it, at never in the future.

TLS Evidence applied to a traditional "notary" operation would look
like this:

 A surveillance video camera records you when you enter the building,
 it records your entire walk to the office, including all details of
 a potential "pit stop".  It records how you fill out the paperwork
 how you "apply the signature", and how the notary verifies your
 identity and counter-signs.
 Then that entire video-tape together with the paperwork is archived,
 however, it is impossible to verify whether the paperwork that is
 archived matches the paperwork that is captured on the video-tape.
 (TLS Evidence equals the video-tape here).

There really is no need to secure anything other that the
paperwork, the identification and the signing process.



The other serious issue with TLS Evidence is its interference with
middleware and application design.

Think about the "signed HTTP(S) FORM" idea that was mentioned.
Somehow the application must tell the TLS stack to start TLS Evidence
before sending the Form.  How is the app going to identify the communication
channel?  Actually, it can not.  It could guess and "tell" the TLS
stack to request TLS Evidence for the SSL session ID through which
the FORM was returned.

But as we know, an SSL session is not unique, Web Browsers duplicate SSL
sessions massively to speed up communication with the Server, and both
servers and clients will terminate HTTP/1.1 keep-alive sessions that are
idle for some amount of seconds (30-60 seconds is not uncommon) --
so a Form that isn't filled an POSTed within that timeout will be
sent on a different communication channel, although it might reuse
the same SSL session ID.

Basically all the web-shops, online-banking and online-brokerage and
ebay do not hold the user responsible for the data entered into the
forms for serveral reasons.  Instead, some amount of processing is
applied to the data and a preformatted page is presented to the
user for confirmation.  Reasons may be manyfold, like computing
a total or checking availability or consistency of an order,
but it is also a means to catch some amount of typing (or copy&paste)
errors by giving the user a chance to re-think his decision or
fix a typo, re-check terms&conditions, re-think warranty or shipping
options, what-have-you...

For brokerage-style operations, I consider it likely that the decision
to by a particular stock how many is determined _before_ either
the price/bid and/or the time when to issue, e.g. while watching
the ticker.  So a signature on the entire communication at the
TLS layer might span a significant amount of time and collect
large amounts or garbage in between due to how TLS session
caching/resumption/duplication is designed to work.



I'm wondering whether any one of those who thinks TLS Evidence is
useful for applications has ever seen an auditor check a system?
They expect to be able to browse through the audit trails and look
at (random) samples of their choice, like "show me all audit records
for this user during that day between this and that hour" and look
at the details.  For these auditors, TLS Evidence gobbledigoo blobs
will be pretty useless, as they can not programmatically verify whether
certain data as processed by the application maps to a particular
archived TLS Evidence record.
If app-level signed XML was used instead, it will be possible
at any time (before processing and during future audits) to verify
the signature and check whether the data which the application
actually processed really matches the signed audit trail.


-Martin

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