note when the router hughes references was 1st introduced in in IETF gateway committee meeting as VPN it caused lots of turmoil in the IPSEC camp as well as with the other router vendors. The other router vendors went into standards stall mode ... their problem was none of them had a product with processors capable of handling the crypto processing. A month after the IETF meeting one of the vendors announced what was supposedly an equivalent product ... but was actually their standard product (w/o crypto) packaged with hardware link encryptors (needed dedicated links instead of being able to tunnel thru the internet).
The IPSEC camp whined a lot but eventually settled for referring to it as "lightweight" IPSEC (possibly trying to imply it didn't have equivalent crypto). As to DNSSEC ... the simple scenario is requiring domain owners to register a public key and then all future communication is digitally signed and authenticated with the onfile, registered public key (as a countermeasure to domain name take-over which affects the integrity of the domain name infrastructure and propogates to SSL CA vendors if they can't trust who the true owner is). Then the SSL CA vendors can also start requiring that SSL certificate requests also be digitally signed ... which can also be authenticated by retrieving the onfile public key (turning an expensive, error-prone and time-consuming identification process into a reliable and simple authentication process). The catch22 is once public keys can be retrieved in realtime ... others can start doing it also ... going a long way towards eliminating need for SSL certificates. Have an option piggy-back public key in the same response with the ip-address. Then do SSL-lite ... XTP had reliable communication minim um 3-pack et exchange ... compared to TCP requiring minimum 7-packet exchange. In the key escrow meetings, I lobbied hard that divulging/sharing authentication keys was violation of fundamental security principles. Other parties at the key escrow meetings whined that people could cheat and use authentication keys for encryption. However, there was commercial "no single point of failure" business case for replicating keys used in encrypting data-at-rest corporate assets. One might hypothesis that some of the current DNSSEC complexity is FUD ... unable to kill it ... make it as unusable as possible. disclaimer: person responsible for original DNS worked at the science center in the early 70s when he was at MIT. -- virtualization experience starting Jan1968, online at home since Mar1970 _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
