At 5:09 PM -0400 10/20/03, [EMAIL PROTECTED] wrote:
On Mon, 20 Oct 2003 16:31:45 EDT, "Steven M. Bellovin" <[EMAIL PROTECTED]> said:
A number of people havce responded that they don't want to be forced to pay for a change that will benefit Verisign. That's a policy issue I'm trying to avoid here. I'm looking for pure technical answers -- how much lead time do you need to make such changes safely?
OK, since you asked....
At least from where I am, the answer will depend *heavily* on whether Verisign
deploys something that an end-user program can *reliably* detect if it's been
fed a wildcard it didn't expect. Note that making a second lookup for '*.foo'
and comparing the two answers is specifically *NOT* acceptable due to the added
lookup latency (and to some extent, the attendant race conditions and failure
modes as well).
Also note that it has to be done in a manner that can be tested by an application - there will be a *REAL* need for things like Sendmail to be able to test for wildcards *without the assistance* of a patched local DNS.
And yes, this means the minimum lead time to deploy is 'amount of time to write
a "Wildcard Reply Bit" I-D, advance through IETF to some reasonable point on
standards track, and then upgrade DNS, end host resolvers, and applications'.
You make an assumption here -- one with which I agree completely -- but that certainly wasn't followed during the Sitefinder debacle. The assumption is that the IETF provides a tested mechanism for disseminating information and making comments.
Verisign claims that they had tested their ideas with a Verisign-selected group of organizations, and made their commercial decisions based on the proprietary data it generated from those organizations.
