Unfortunately, from my long experience with the DNS and ICANN travails, I must report that your trust in the contents of a DNS query response is unwarranted. We only trust it now because monetary transaction security considerations are not involved in DNS resolver code.
As soon as you load the DNS with some required monetary trustworthiness, it is subject to severe compromise. Note that in essence you are back to trusting VERISIGN without benefit of any contractual warranty of any kind regarding an ability to rely on the response delivered by the DNS Resolution service. I seriously doubt that you really want to go there!...\Stef At 3:55 PM -0700 12/20/02, [EMAIL PROTECTED] wrote: >somewhat total aside .... first time i ran into x.500/x.509 was at an acm >sigmod meeting. My wife and i were doing this high availability, no single >point of failure, high performance, high integrity, scalable database work >as part of the ha/cmp product: >http://www.garlic.com/~lynn/subtopic.html#hacmp > >any way the person at the sigmod meeting was explaining x.500 as a bunch of >network gurus busily re-imventing 1960s database technology. the work that >went along with it for x.509 was (extremely privacy invasive) identity >certificates (which represented some information supposedly contained in >this x.500 1960s-era database entries). > >There was some reference that these network gurus may have been the same >people that brought us OSI. Misc. references to OSI and what went wrong: >http://www.garlic.com/~lynn/subtopic.html#xtphsp > >so one of the distinction often cited about the different between ISO and >IETF (besides the difference between OSI and TCP/IP) is it is possible for >ISO to pass standards that may never, ever be implemented (and in fact >could be such that they aren't actually implementable in any practical >since). For some of the IETF standards process description go to: >http://www.garlic.com/~lynn/rfcietff.htm >and scroll down in the main frame to the description of the standards >process and the requirement for two interoperable implementations for >standards progress. > >So about the time we were doing the HA/CMP product stuff with were also >doing the hsdt project >http://www.garlic.com/~lynn/subtopic.html#hsdt >and internet stuff >http://www.garlic.com/~lynn/internet.htm > >and doing some stuff with high speed protocol. Part of the ISO issue of >passing standards that might not be implementable ... is that they can also >make rulings that additional standards work can't be done unless in >conforms to earlier standards activity (which might not be actually >implementable). Now ISO is somewhat schizo about this in the area of OSI >... and things like IEEE (ISO chartered group) and LAN standards. LAN >standards effectively collapse OSI levels 1, 2, and part of 3 into a single >layer .... quite definately violating OSI. So we were doing some stuff on >HSP (high speed protocol) which would go directly from level 4 (transport) >interfacing directly to the LAN/MAC layer. This would also violate OSI >since it jumped the interface betwen layer 3 & 4 ... and went directly to >the middle of layer 3 ...... which is where LAN interface sits. One of the >more schizo of the ISO organizations is US chartered X3S3.3 ... responsible >for network level 3&4 standards .... which had a strong ruling that it was >not possible to do HSP as defined .... going directly from transport to >LAN/MAC interface. Anothe example of little problems with ISO network >related standards activity. > >In any case, in the HSP work .... it also looked at reliable, >high-performance transactions. HTTP (& HTTPS) uses TCP. TCP has a minimum >of 7 packets to perform reliable session/transactions. There was some >looking at VMTP which accomplishes the same thing in 5 packets. >VMTP/RFC1045: >http://www.garlic.com/~lynn/rfcidx3.htm#1045 > >However, with a little more work, HSP came up with a reliable transaction >protocol that could be done in three packets. Slight thread drift (which >helps me remember VMTP being RFC1045) is that I had done the RFC1044 >implementation that shipped in mainframe TCP/IP product: >http://www.garlic.com/~lynn/rfcidx3.htm#1044 >which had the slight characteristic that the base implementation got about >44kbytes/sec thruput using >a full 3090 engine .... while the enhanced 1044 implementation got >1mbyte/sec thruput (hadware media >thruput) using about 1/50th as much processing (twenty times the thruput >using 1/50th the pathlength). > >So getting back to the discussion about SSL domain name certificates. In >the thread >http://www.garlic.com/~lynn/2002p.html#9 Cirtificate Authorities 'CAs', how >curruptable are they to >http://www.garlic.com/~lynn/2002p.html#10 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#11 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#12 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#17 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#18 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#19 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#20 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#21 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#22 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#26 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#50 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#52 Cirtificate Authorities 'CAs', >how curruptable are they to >http://www.garlic.com/~lynn/2002p.html#57 Cirtificate Authorities 'CAs', >how curruptable are they > >as well as several other SSL domain name ceritificate threads: >http://www.garlic.com/~lynn/subtopic.html#sslcerts > >I make the assertion that not only does fixing the integrity of the domain >name infrastructure (on behalf of the certification authorities) sows the >seads of eliminating the SSL domain name certificates ... but also opens >the opportunity for simplifying (KISS) the SSL protocol. > >So current process is somewhat: >1) contact domain name system to get the ip-address that corresponds to the >domain URL >2) minimum 7 packet for reliable TCP for HTTP/HTTPS >3) certificate transmittal >4) ssl protocol chatter >5) hypothetical trust hiearchy network chatter to obtain necessary signing >certificates to validate > certificate >6) hypothetical OSCP network chatter to check on the status of each of the >signing certificates >7) hypothetical OSCP network chatter to check on the status of the domain >name certificate >8) the misc. digital signature verifications with all the various public >keys >9) once the SSL session has been setup the client transmits the SSL >transaction request >10) the server finally gets the SSL transaction requests, does whats needed >11) replies to the SSL transaction request >12) client gets the rsponse and tears down the SSL/TCP session > >Now, part of improving the domain name infrastructure integrity ... >somewhat on behalf of the certification authority industry ... is that when >a domain name is registered, the entity also registers a public key. This >doesn't include a certificate ... it is just the registration authority >part of public key registration that is done at the sametime as registering >the domain name (this is akin to when somebody creates an account they >supply their mother's maiden name or some other supposed secret, it isn't >necessary to have identification ... it is just that the registering entity >is the one also providing the authentication material). > >So the domain name infrastructure already has the ability to serve up all >information registered with a domain name .... so the new scenario is > >1) contact domain name infrastructure and get ip-address, public key, and >whatever else may be registered (possibly including server's preferred SSL >parameters if they so desire). >2) client creates a piggybacked xtp transaction packet that has the >selected ssl parameters and the session key encrypted with the server's >public key, followed by the encrypted transaction session information >packet ... all in one transmission >3) server receives the piggybacked xtp transaction packet and unwinds it >all and performs the requested transaction >4) server responds with piggbacked xtp transaction containing the >(encrypted) response and the session tear-down >5) client response with tear-down acknowledgement > >So eliminating the SSL domain name certificate not only gets rid of the >whole certificate stuff ... but eliminates huge amount of network chatter >or nattering on as one reply to the following post suggested: >http://www.garlic.com/~lynn/2002p.html#30 Sci Fi again > >Basically single round trip to get the domain name information followed by >single round trip to do the SSL transaction.
