Ivan Krstić wrote:
That can't happen until we make sure you can trust DNS, which in turn
can't happen until we get a concrete proposal that has clearly defined
goals and isn't braindead. As has been amply pointed out, it's not clear
that DNSSEC will cut it anytime soon.
A big part of the issue is the domain name certification authority has to trust
the domain name infrastructure as to the true owner of the domain name ... when
they are processing a domain name certificate application for certification
(i.e.
only the actual domain name owner on file with the domain name infrastructure
should
be able to apply for domain name certifications).
The catch-22 is that the original idea behind domain name certificates were
because of integrity issues with the domain name infrastructure. However, the
domain name certification industry is dependent on the integrity of the domain
name infrastructure in their domain name certification process.
As a result they need to improve the integrity of the domain name infrastructure
because their dependency on the domain name infrastructure in their process of
certification.
So one of the proposals (somewhat backed by the domain name certification
authority
industry) is that domain name owners place a public key on file when they
register
a domain name with the domain name infrastructure. They all future communication
with the domain name infrastructure can be digitally signed ... and the domain
name infrastructure verify the digital signature with the onfile public key.
This is intended to help improve the integrity of the domain name
infrastructure.
However, it could also offer benefits to the domain name certification authority
industry. The domain name certification authority industry could also then start
requiring that domain name certification applications also be digitally signed.
The the domain name certification authority industry can do a real-time
retrieval
of the on-file public key to verify the domain name certification application
digital
signatures. This provides for turning a time-consuming, error-prone, and
expensive
identification process into a much simpler, reliable, and less expensive
authentication
process (enormous benefits for the domain name certification authority
industry).
The issue is that if the domain name certification authority industry are
somewhat
two fold:
1) the original justification for domain name certification involved integrity
issues with the domain name infrastructure. improving the integrity of the
domain
name infrastructure would reduce the original justification for having domain
name certification
2) if the domain name certification authority industry could start relying
on real-time retrieval of public keys ... then possibly the rest of the world
could also ... eliminating the need for domain name infrastructure.
some collected "catch-22" posts
http://www.garlic.com/~lynn/subpubkey.html#catch22
long ago and far away, we had been called in to consult with this small
client/server
startup that wanted to do payment transactions and had this technology called
SSL. In addition to doing stuff about working out the payment transaction
operation
we also had to do a lot of stuff with end-to-end business process investigation
of
these new business operations called certification authorities. Since then,
this has frequently come to be referred to as electronic commerce. some old
posts
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
and collection of posts mentioning payment processing and payment gateway
http://www.garlic.com/~lynn/subnetworkhtml#gateway
Now, the original SSL infrastructure was to verify that the URL that the
user entered (into the browser) corresponded to the website that the
browser was talking to (i.e. the website that the user thought they
were talking to was the website they were actually talking to). However,
most electronic commerce sites fairly quickly found that SSL was costing
them something like 90percent of their thruput. The result was that most
websites transitioned to no longer using SSL for the initial user connection
but reserved just for the payment process (to hide the account number
information). Now the user clicks on a button (provided by the webserver)
which generates a URL (provided by the webserver). Now instead of checking
the URL provided by the user against the webserver ... most use of SSL
now checks the URL provided by the webserver against the webserver (invalidating
the original SSL security assumptions). lots of past posts about ssl
digital certificate infrastructure
http://www.garlic.com/~lynn/subpubkey.html#sslcert
so it could be claimed that the way that the currently deployed SSL for the
electronic commerce infrastructure doesn't really cut it either ... it is
somewhat
a case of the emperor's new clothes ... and the integrity of the domain
name infrastructure has to be improved in any case, since it is the trust
root for the whole domain name certification authority industry's
certification process (but fixing the integrity of the trust root could also
make additional domain name certification processes redundant and superfluous).
afterwards we did some work with the x9a10 financial standard working group
that in the mid-90s had been given the requirement to preserve the integrity of the
financial infrastructure for all retail payments (i.e. all, point-of-sale,
internet, credit, debit, ach, face-to-face, stored-value, aka ALL). The
result was the x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
In the security acronym "PAIN"
P ... privacy (or sometimes CAIN, confidential)
A ... authentication
I ... identification
N ... non-repudiation
now, we've claimed that possibly the largest use of SSL is in support of
electronic commerce (to hide account number information).
however, in X9A10, a detailed end-to-end vulnerability and threat analysis
was performed ... and divulging account information was identified as
major exploit (requiring SSL to hide transaction information). However
the majority of exploits had never been capturing information in transit
(before SSL, even before the internet) ... it had always been capturing
information at end-points and/or logs of previous transactions. As a result,
a primary objective of X9.59 financial standard was to eliminate havesting/skimming
of previous transactions as a (replay attack) vulnerability. The result was
that X9.59 effectively "armors" every transactions ... in effect replaces
"privacy/confidentiality" as a countermeasure with "authentication" and
"integrity".
X9.59 transactions no longer have to be hidden as a fraud countermeasure.
This eliminates the requirement to hide such transactions ... and therefor
eliminates the major use of SSL in the world today (related to electronic
commerce). X9.59 also eliminates the major threats and vulnerabilities
related to the data breaches and security breaches that have been in the
news recently. some related recent posts about naked transactions/payments
metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments
for some topic drift ... lots of the stuff being "hidden" with SSL
are really transaction oriented operations ... and if domain name
infrastructure could serve up public keys ... there could be significant
thruput improvements in such protocols. some recent posts in a
financial crypto blog
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardized Security
Protocols are Too Heavy
http://www.garlic.com/~lynn/aadsm27.htm#1 H6.2 Most Standardized Security
Protocols are Too Heavy
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]