A real example, with names

[Harald Tveit Alvestrand]

--On torsdag, mai 08, 2003 15:26:50 +0300 john.loughney at nokia.com wrote:

> Hi Keith,
>
>> do you think writing up 30 pages of detailed explanation is
>> constructive?
>
> In some cases a 2 or 5 page document would be enough, at least for
> me.  Many times, I am just looking for documentation why I should
> or should not do 'x'.  Here is a good example, actually involving
> you.
>
> When I took over the editorship of the Diameter Base spec, I
> was given a comment by the IESG that using different ports
> for TLS & non-TLS traffic violated a long-held IESG policy.  Of course,
> this policy is not written down.  As I have certain job responsibilities,
> folks at home were asking me what problems are caused by this,
> for which I had no answer.  After some pestering, someone, Bert W.
> I think, pointed me to an SMTP RFC with some discussion about port
> usage ... it didn't really provide me with convincing material,
> but I was motivated to get the doc done, so I made the fix.
>
> A bit later, in another WG, the same issue came up again.  The WG
> Security advisor, when asked about this mentioned - 'Oh, that was
> Keith's big thing ... mumble, mumble.'  Further mail exchanges with
> him & the responsible AD did not produce any insight or conclusions,
> so I'm left with little insight or understanding if it is allowed
> to use multiple ports or not.  Currently, the WG is leaning towards
> a 2-port model; does this mean we'll suffer a gotcha during IESG
> review?

actually there's a little text around.... but I think this is what you were 
referring to....

RFC 2595 ("Using TLS with IMAP, POP3 and ACAP") says this:

7. imaps and pop3s ports

   Separate "imaps" and "pop3s" ports were registered for use with SSL.
   Use of these ports is discouraged in favor of the STARTTLS or STLS
   commands.

   A number of problems have been observed with separate ports for
   "secure" variants of protocols.  This is an attempt to enumerate some
   of those problems.

   - Separate ports lead to a separate URL scheme which intrudes into
     the user interface in inappropriate ways.  For example, many web
     pages use language like "click here if your browser supports SSL."
     This is a decision the browser is often more capable of making than
     the user.

   - Separate ports imply a model of either "secure" or "not secure."
     This can be misleading in a number of ways.  First, the "secure"
     port may not in fact be acceptably secure as an export-crippled
     cipher suite might be in use.  This can mislead users into a false
     sense of security.  Second, the normal port might in fact be
     secured by using a SASL mechanism which includes a security layer.
     Thus the separate port distinction makes the complex topic of
     security policy even more confusing.  One common result of this
     confusion is that firewall administrators are often misled into
     permitting the "secure" port and blocking the standard port.  This
     could be a poor choice given the common use of SSL with a 40-bit
     key encryption layer and plain-text password authentication is less
     secure than strong SASL mechanisms such as GSSAPI with Kerberos 5.

   - Use of separate ports for SSL has caused clients to implement only
     two security policies: use SSL or don't use SSL.  The desirable
     security policy "use TLS when available" would be cumbersome with
     the separate port model, but is simple with STARTTLS.

   - Port numbers are a limited resource.  While they are not yet in
     short supply, it is unwise to set a precedent that could double (or
     worse) the speed of their consumption.

There are also a few lines in the sec-cons draft dealing with a specific 
problem (virtual hosts) that is at the moment VERY painful for the folks 
hosting secure Web servers....

I think this is a typical case of:

- someone thinks through a problem, coming to a conclusion. In this case 
that separate ports for different versions of the same application protocol 
is a thoroughly bad idea.

- that someone explains this multiple times, convincing at least the people 
in a position to enforce policy at the time. But does not write down 
explicitly the full justification for it.

- the person leaves, and the policy remains in force. The quality of the 
explanations tends to deteriorate.

(FWIW, I personally think separate ports are just plain stupid, because 
they are a totally inappropriate granularity of security policy control, 
and their existence forms a slow, error-prone and eminently attackable form 
of security negotiation, but I've generally not had the energy to dive into 
those discussions, having other fish to fry so to speak, so you can't find 
many quotes from me on the subject....)

                    Harald