Subject: [ietf-tls] Re: London

From: "Joseph Hui" <[email-masked]>
Date: Fri, 13 Jul 2001 14:02:55 -0700

>From: Bodo Moeller [mailto:[email-masked]]
>
>On Fri, Jul 13, 2001 at 09:40:49AM -0700, Joseph Hui wrote:
>>> From: Bodo Moeller [mailto:[email-masked]]
>>>> Maybe now it's a good time to bring up an issue of compatibility
>>>> that may cause grief during the dns_name roll-out:
>>>>
>>>>    dsn_name-server     : dns_name-browser,     works;
>>>>    dns_name-server     : non-dns_name-browser, doesn't work;
>>>>    non-dns_name-server : dns_name-browser,     doesn't work;
>>>>    non-dns_name-server : non-dns_name-browser, doesn't work.
>
>>> This is misleading.  SSL 3.0 and TLS 1.0 servers are required to
>>> ignore extra data at the end of the ClientHello message, and
obviously
>>> non-dns_name servers would only be used in situations where the
>>> dns_name extension is not needed (i.e., no name-based virtual
>>> hosting).  Thus the only configuration that is problematic is when a
>>> server requires dns_name, but the client does not support it.  This
is
>>> similar to the HTTP "Host" header situation some time ago.
>
>> The context of discussion was about dns_name only.
>> I.e. the tabulation was only meant for dns_name deployment.
>> (What else was the thread about?)
>
>It is obvious that dns_name can be *used* only if it is supported both
>by the client and the server.  Since the server implementation should
>be selected depending on the needs of the specific site, why is it a
>"compatibility" problem that non-dns_name servers would have to ignore
>the dns_name extension?

First of all, I think the quoted text was taken out of context.
For starter, the sentence where I made my point had been omitted.
(The quoted part was only the preamble.)  My point was to appeal to
vendors to do the best they can to mitigate the migration pain,
as migrate we must, having established dns_name is worth doing. 
I might be guilty of overstating the obvious.
But hey, traffic signs too are obvious, yet accidents abound.
Look where we're at now with this thread, where not everything was
made perfectly clear.

Why a problem?  Suffice to say, as long as the
dns_name-server:dns_name-browsers state hasn't been achieved, we have
a problem, practicing secured virtual hosting.  I'm comfortable in
characterizing the problem as compatibility related, especially
during the roll-out stage, taking into consideration of what best to
inform the end users during the transition period, e.g. on an http
page, say "You need a xyz compatible browser to login.  Click here
to get the https page, click there to download the xyz patch.
blah blah blah ..."  This may not be the same characterization
of "compatibility" you had in mind.  Yours might be more intrinsic
to the TLS semantics, I guess.

>But TLS extensions can cause compatibility problems even for
>connections where they are not needed at all (see my previous
>message).  When connecting to an HTTPS server, a browser does not know
>whether dns_name is required for this specific connection or not.
>Thus the dns_name extension would have to appear in *all* connection
>attempts (ruling out use of the SSL 2.0 client hello format), and
>*this* is a possible source of compatibility nightmares.

This is yet another compatibility issue that merits to be addressed
in a separate thread.  It raises a good point, because we should cover
all corners, bending backwards to be backward-compatibility-friendly.
Having said that, I should also say, going out on a limp, even
contortionists have limits.
Extrapolating from the success of the 128-bit roll-out, we may
not have to lose sleep over this.  E.g. there're more than few
128-bit commercial sites that tell users to upgrade or get lost.
So far I've heard no complaints, not to make light of the situation.

Now, I think I've gotten enough mileage out of this thread, which has
served the purpose of granting dns_name the attention it deserves from
vendors/implementers.  

To continue the discourse on compatibility issues, which appear to
be many. I suggest a new thread be created for each of them, for
the sake of clarity and posterity.

Cheers,

Joe Hui
Digital Island

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]