307 digit number factored

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com