Re: X.509 and ssh

Ken Johanson wrote:
You are implying that a cert must be attached for message. That is not true. SSL establishes sessions, where in the cert / keys are exchanged only at the beginning of the session. There is no "KB's worth of superfluous bytes" as you claim below, and certainly none of those are wasted in the case where identity must be assured.

there tends to be a broad range of different applications. supposedly one of the big drivers for certificate business in the mid-90s was in conjunction with financial transactions. the example was a financial transaction that is typically requiring 60-80 bytes ... and a large contingent of the PKI industry behind appending certificates to such transactions (as part of financial institutions paying $100 for digital certificates for everybody in the country that might do a financial transactions).

it was possible to trivially show

1) that if the financial institution already had all the information, then it was redundant and superfluous to attach a digital certificate to such financial transactions

2) that the typical financial transaction was 60-80 bytes and the payload overhead of having redundant and superfluous certificates was on the order of 4k-12k bytes (representing a payload bloat of a two orders of magnitude increase).

So in SSL, the overhead is theoritically front load for a session.
However, when we originally helping to patch together the actual business process use of SSL
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

a lot of the SSL HTTP transactions were individual transactions (not KB transactions).

the original business justification for SSL digital certificates were related to e-commerce ... and mentioned in the above references. The process was that the merchant got their domain name in a certificate. As part of the TCP/HTTP/SSL session setup, the person had typed in the URL/domain name into the browser, the browser had contacted DNS to map that domain name to IP-address, the browser contacted the webserver, the webserver responded with certificate, the browser validated the certificate and then check the typed in domain name against the domain name in the certificate.

however, the majority of the merchants operating webservers discovered that the SSL overhead increased overhead by a factor of five times compared to running straight HTTP. As a result ... you saw almost all merchants dropping back to using SSL for purely the payment/checkout phase of electronic commerce. The problem is that the URL/domainname that is typed in by the user is no longer checked against an SSL certificate. What now happens is that the user clicks on a button supplied by the webserver that generates the URL and domain name ... which is then used to check against the domain name in the certificate also supplied by the same webserver. The issue now is that the majority of the ecommerce use in the world now violates fundamental kindergarten security principles ... since the webserver provides both the URL and the certificate that are checked against each other. It would take a really dumb crook to not have a completely valid certificate that corresponds to the domain that they provide in the button.

So the other issue was that HTTP (which SSL was a subset) had other these truelly trivial transaction payloads ... and was using TCP protocol for doing it. Now TCP has a minimum of seven packet exchange for session setup (ignoring any added HTTP and/or additional SSL overhead). One of the characteristics in these early days was that most TCP implementations assumed few, long running sessions .... as opposed to a very large number of extremely short transaction like operations. One of the places that this appeared was in the linear list operation supporting FINWAIT. There was a crises period as HTTP (& SSL) caught on where numerous major webservers found that they were spending 99percent of total cpu managing the FINWAIT list.

lots and lots of posts about SSL and certificates from the period
http://www.garlic.com/~lynn/subpubkey.html#sslcert

there is another issue somewhat involving the weak binding between
domain name and domain name owner. the issue is that many of the
certification authorities aren't the authoritative agency for the
(SSL domain name server certificate) information they are certifying. much of the original justification for SSL related to mitm attacks was various integrity issues in the domain name infrastructure.

the process tends to be that a domain name owner registers some amount
of identification information for their domain name ownership with the
domain name infrastructure. the certification authorities then require
that SSL domain name certificate applicants also provide some amount
of identification information. then the certification authorities
attempt to do the expensive, time-consuming, and error-prone process
of matching the supplied identification information for the SSL domain
name certificate with the identificaiton information on file with the
domain name infrastructure for the domain name.

as part of various integrity issues related to that process, there has
been a proposal, somewhat backed by the ssl domain name certification
authority industry that domain name owners also register a public key
with the domain name infrastructure (in addition to identificaiton
information). then future communcation can be digitally signed and
verified with the onfile public key. also the ssl domain name
certification authority industry can require that ssl domain name
certificate applications be digitally signed. then the certification
authority can replace the expensive, time-consuming, and error-prone
identification matching process with a much less-expensive and
efficient authentication process by doing a real-time retrieval of the
on-file publickey from the domain name infrastructure for verifying
the digital signature (in lieu of doing a real-time retrieval of the
on-file identificaiton information for the expensive, time-consuming
and error-prone identification matching).

the two catch22 issues here are

1) improving the overall integrity issues of the domain name
infrastructure lessons the original justification for ssl domain name
certificates

2) if the certification authority industry can rely on real-time
retrieval of publickeys from the domain name infrastructure as the
base, TRUST ROOT for all of their operations ... it is possible that
other people in the world might also be able to do real-time retrieval
of publickeys as a substitute to relying on SSL domain name
certificates

so there one could imagine a real transaction oriented SSL ... where the browser takes the URL domain name and requests the domain name to ip-address mapping. In the same transaction the domain name infrastructure also piggybacks in the same transaction, any registered public key for that webserver.

Now you can imagine that in the initial communication, the browser includes the actual request, encrypted with a randomly generated secret key, which is, in-turn encrypted with the onfile public key obtained from the domain name infrastructure. This is all packaged in single transmission set of to the webserver. If it becomes an issue, the various SSL options can also be registered with the domain name infrastructure (as part of registering the public key). This can be a true SSL transaction and eliminates all the existing SSL protocol chatter back and forth (and no digital certificate required)

so, if you start considering transaction efficiency ... there is the issue of 7packet minimum for TCP sessions. VMTP specified a 5-packet minimum exchange for reliable communication.

From my RFC index.
http://www.garlic.com/~lynn/rfcietff.htm

http://www.garlic.com/~lynn/rfcidx3.htm#1045

1045 E
VMTP: Versatile Message Transaction Protocol: Protocol
specification, Cheriton D., 1988/02/01 (123pp) (.txt=264928)
(VMTP)

as usual in my RFC index summary entries, clicking on the ".txt=nnn" field retrieves the actual RFC.

However, when we were doing XTP protocol specification ... we actually came up with a minimum 3-packet exchange for reliable transaction
http://www.garlic.com/~lynn/subnetwork.html#xtphsp

lots of other posts mentioning the catch-22 issue for the SSL domain name certification authority industry moving to higher integrity domain name infrastructure operation
http://www.garlic.com/~lynn/aadsmore.htm#client3 Client-side revocation checking capability
http://www.garlic.com/~lynn/aadsmore.htm#pkiart2 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#5 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm8.htm#softpki6 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop

http://www.garlic.com/~lynn/aadsm13.htm#26 How effective is open source crypto?
http://www.garlic.com/~lynn/aadsm13.htm#32 How effective is open source crypto? (bad form)
http://www.garlic.com/~lynn/aadsm14.htm#39 An attack on paypal
http://www.garlic.com/~lynn/aadsm15.htm#25 WYTM?
http://www.garlic.com/~lynn/aadsm15.htm#28 SSL, client certs, and MITM (was WYTM?)
http://www.garlic.com/~lynn/aadsm17.htm#18 PKI International Consortium
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#43 SSL/TLS passive sniffing
http://www.garlic.com/~lynn/aadsm19.htm#13 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#42 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#31 The summer of PKI love
http://www.garlic.com/~lynn/aadsm20.htm#43 Another entry in the internet security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#39 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#0 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/aadsm22.htm#19 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/2000e.html#40 Why trust root CAs ?
http://www.garlic.com/~lynn/2001l.html#22 Web of Trust
http://www.garlic.com/~lynn/2001m.html#37 CA Certificate Built Into Browser Confuse Me
http://www.garlic.com/~lynn/2002d.html#47 SSL MITM Attacks
http://www.garlic.com/~lynn/2002j.html#59 SSL integrity guarantees in abscense of client certificates
http://www.garlic.com/~lynn/2002m.html#30 Root certificate definition
http://www.garlic.com/~lynn/2002m.html#64 SSL certificate modification
http://www.garlic.com/~lynn/2002m.html#65 SSL certificate modification
http://www.garlic.com/~lynn/2002n.html#2 SRP authentication for web app
http://www.garlic.com/~lynn/2002o.html#10 Are ssl certificates all equally secure?
http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how curruptable are they to
http://www.garlic.com/~lynn/2003.html#63 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003.html#66 SSL & Man In the Middle Attack
http://www.garlic.com/~lynn/2003d.html#29 SSL questions
http://www.garlic.com/~lynn/2003d.html#40 Authentification vs Encryption in a system to system interface
http://www.garlic.com/~lynn/2003f.html#25 New RFC 3514 addresses malicious network traffic
http://www.garlic.com/~lynn/2003l.html#36 Proposal for a new PKI model (At least I hope it's new)
http://www.garlic.com/~lynn/2003p.html#20 Dumb anti-MITM hacks / CAPTCHA application
http://www.garlic.com/~lynn/2004b.html#41 SSL certificates
http://www.garlic.com/~lynn/2004g.html#6 Adding Certificates
http://www.garlic.com/~lynn/2004h.html#58 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005.html#35 Do I need a certificat?
http://www.garlic.com/~lynn/2005e.html#22 PKI: the end
http://www.garlic.com/~lynn/2005e.html#45 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005e.html#51 TLS-certificates and interoperability-issues sendmail/Exchange/postfix
http://www.garlic.com/~lynn/2005g.html#0 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#1 What is a Certificate?
http://www.garlic.com/~lynn/2005g.html#9 What is a Certificate?
http://www.garlic.com/~lynn/2005h.html#27 How do you get the chain of certificates & public keys securely
http://www.garlic.com/~lynn/2005i.html#0 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005i.html#3 General PKI Question
http://www.garlic.com/~lynn/2005i.html#7 Improving Authentication on the Internet
http://www.garlic.com/~lynn/2005k.html#60 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#0 simple question about certificate chains
http://www.garlic.com/~lynn/2005m.html#18 S/MIME Certificates from External CA
http://www.garlic.com/~lynn/2005o.html#41 Certificate Authority of a secured P2P network
http://www.garlic.com/~lynn/2005t.html#34 RSA SecurID product
http://www.garlic.com/~lynn/2005u.html#9 PGP Lame question
http://www.garlic.com/~lynn/2006c.html#10 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#38 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#29 Caller ID "spoofing"
.