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 

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

Reply via email to