[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] Please discuss: draft-housley-evidence-extns-00<
Omirjan Batyrbaev wrote:
>
> ... Majority of the banks found
> ways to manage the risk. If the issue was raised 10 or more years ago it may
> have been different. BTW, when I used wells fargo (wellsfargo.com) in 2003 I
> was able to transfer money between accounts with a simple user name /
> password authentication. But I did hear about other solutions employed by
> non-US banks - but they look at them as a satisfactory solutions.
I don't think that Online Banking (customer<->bank) is an area
that is in desperate need of (TLS) Evidence. In many if not most
scenarios that I know, the customer has to deal with / pay for
the majority of fraud, making it an "externality" for the bank,
which is why e.g. there are lots of el'cheapo ATM cards
in use (at least here in Germany), i.e. simple magnetic strip cards
that can be copied, and only its use protected by a 4-digit Number/PIN.
Online Banking (at least here in Germany) often involves an
OTP-style authentication (TAN) to authorize each individual
transaction. Personally, I'm fine with that (although I will NOT do
Online Banking in an Internet Cafe or from arbitrary people's PCs).
As you mentioned, there are consumer protection acts that shield
customers from some of the bad things around online shopping
(at least in Germany, consumer protection curiously does not cover
many aspects online and offline banking), and so a signing scheme
like TLS Evidence scheme might not help businesses, and due to
the data protection standards in the EU, such a TLS approach
may even be illegal in a lot of scenarios or impose a lot of
additional duties or non-obvious responsibilities on businesses.
Businesses must provide accurate information about stored/archived
data that can be linked to a subject. The permission to store that
data can be revoked by the subject at any time. If revoked, the
business is required to completely delete all records.
Not complying with the deletion request is a "federal offense".
Tough luck if TLS Evidence was blindly streamed to write-once
media...
Those requirements don't apply to wire-taps of federal agencies,
of course. And when/where they apply (after a secret wire-tap
that resulted in no legal action), they "sometimes forget" to tell
the subject and delete the records...
In one of his Emails, Mark wrote "Your typical brokerage transaction",
maybe he was thinking of inter-business, or more specifically
inter-banking, broker<->bank, bank<->bank, broker<->broker
transactions in the financial area.
I consider it somewhat strange to design an "evidence" scheme
that will be difficult to process/interpret automatically or
programmatically because of a lack of standardization of
how to perform the verification and how to make sense of
the gobbledigoo that travels at the lowest level of the
communication.
By using standardized contents it will be much easier to process
the data programmatically, and you could use even 3 signers:
both peers and a timestamping authority.
TLS Evidence requires interactive online communication, an
application-level signing approach can easily work without
transport, accross arbitrary hops/links, with queueing or
batch-processing, via Email, and on and on, i.e. entirely
independent of the nature and persistence of the communication (link).
If one would design the "transaction evidence" from the communication
link with clear&explicit application-defined semantics, then it would
be possible to programmatically check the archived "evidence" against
the app transaction logs on the backend on a regular basis in order
to detect differences (du to bugs or system manipulation in the
backend) early on. With a raw dump of the communication data this
is going to be quite difficult and context-sensitive to changes
of the application (data stream), and less likely to be done.
-Martin
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls