Subject: Not sure if this is the right place for this

From: John Rudd <[email-masked]>
Date: Sun, 9 May 2004 11:37:03 -0700

I've noticed a trend with the adoption of SSL/TLS that I'm not sure is 
really in the best long term interests of the community.

It seems that early on an "alternate port" strategy is/was adopted, 
such as having an SSL only version of POP on port 995, IMAP on 993, and 
SMTP on 465.  These ports start p with an SSL session before any data 
is sent, so only SSL enabled clients are able to attach. (I will refer 
to this as the "alternate port strategy")

Then, as time has marched on, and the "STARTTLS" command was 
implimented, SSL/TLS has been integrated into the "primary port".  So, 
now, SSL/TLS is handled on ports 110, 143, and 25 (respectively), with 
SSL/TLS being initiated (by the client sending the "STARTTLS" command) 
after the plain-text session has started.  When this shows up in the 
RFC for extensions to the protocol, the alternate port method is 
usually then mentioned as "deprecated".  (I will refer to this as the 
"STARTTLS strategy").

The problem with the STARTTLS strategy is: you can't guarantee at the 
network level that a client will use SSL/TLS.  The service provider 
might be able to do that (ex: CommuniGate Pro, a mail server from 
stalker.com, has an option to require "secure logins", meaning that 
they must be happening within an SSL/TLS protected session), but the 
network provider cannot.  In large organizations, or situations with 
outsourced services, those two groups may not be the same.  This leads 
to a situation where a networking service may be trying to enforce a 
mandate of "secure protocols only", but cannot do so under the STARTTLS 
strategy.

This is our current issue at UCSC with the deployment of wireless 
access points.  I, the email administrator, can't currently require 
"secure logins" because of some legacy issues.  As dangerous as it may 
be, I can't disallow plain text sessions yet.  Yet, the wireless group 
doesn't trust WEP (for good reasons), and has decided that wireless 
privacy must come from SSL/TLS enabled protocols ... so they're 
blocking the non-SSL/TLS ports.  You can't get to POP via 110, IMAP via 
143, nor SMTP via 25.  If you want to check your email, you have to it 
via the Alternate Port strategy.

Personally, I'm quite happy with their agenda.  But I have a concern: 
clients which are aiming at RFC compliance now see that the RFCs which 
cover them consider the Alternate Port strategy to be deprecated.  So, 
we cannot depend upon current clients to "do the smart thing" and have 
the Alternate Port strategy available.  Yet, the Alternate Port 
strategy is the only way to, at the network level, enforce SSL/TLS*.  
So, the Alternate Port strategy still has some very real, very lasting 
value.  If the Alternate Port strategy were to be considered "current", 
then it might encourage authors to embrace both strategies (the best 
path).

(* Yes, someone could merely start a standard STARTTLS based server on 
ports 993, 995, etc. and circumvent the network agenda, but we're not 
so concerned about that type of blatant action, we're concerned with 
typical software in typical configurations being able to be pigeonholed 
into only having the option of entering in to SSL/TLS sessions.)

So, what I would like to see, as a general agenda for the RFC's is:

1) The Alternate Port strategy should no longer be deprecated for any 
protocol
2) Those services (such as the Message Submission Protocol) that were 
created with an assumed dependance upon STARTTLS should be extented to 
also have an Alternate Port for SSL/TLS only.
3) Standard Compliance (of the software) should depend upon 
implementing both strategies, not one or the other (but it would be 
acceptable if the systems administrator were to not activate both 
strategies, which is why I inserted "of the software").

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: grenville armitage <[email-masked]>
Date: Mon, 10 May 2004 09:29:56 +1000

John Rudd wrote:
	[..]
> might be able to do that [...] but the

Your problem lies within this paragraph. If one _has_ decoupled the network
service and end-user service provision then the network service provider has
no place mandating the behaviours (and port usages) of the end-user service
providers (such as email server administrators).

Or in your particular case, the wireless network group should get out of _your_
space (as the email system administrator) and just let you get on with enforcing
your email access security policy with STARTTLS on regular ports.

There's no need to change the RFCs in the way you've suggested.

cheers,
gja
-- 
Grenville Armitage
http://caia.swin.edu.au
I come from a LAN downunder.

---

From: grenville armitage <[email-masked]>
Date: Mon, 10 May 2004 09:29:56 +1000

John Rudd wrote:
	[..]

cheers,
gja

---

From: Dean Anderson <[email-masked]>
Date: Sun, 9 May 2004 19:42:19 -0400 (EDT)

This is not an IETF problem, but a general problem with upgrading legacy
services and software. Everyone has this same problem, and has to choose
their own approach to the problem.  You cannot move faster than your
client software base.  It means that you may have to either adjust your
security policy to accomodate those legacy clients, or exclude legacy
clients altogether.  Some people must do the former. Some other people can
do the latter.

Since you are in a limited internal academic environment, you probably
have more lattitude to specify that all of your users use a given set of
software products that meets your security and software protocol goals.  
However, if for some reason this is unsuitable, then you have to adjust
your security policy. Those are your choices.

One thing: You should pay close attention to the fact that some of the
protocols you have mentioned are experimental, and probably should not be
used for production environments.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 9 May 2004 19:42:19 -0400 (EDT)

--Dean

---

From: John Rudd <[email-masked]>
Date: Sun, 9 May 2004 20:08:41 -0700

On May 9, 2004, at 7:33 PM, [email-masked] wrote:

> I believe there's a strong consensus that this trend _is_ in the best 
> long
> interests of the community.

[snip]
>> (I will refer
> This strategy suffers from several serious flaws, especially in 
> situations
> where SSL/TLS is only used some of the time.

[snip]
> Offering alternate port support is no longer a "smart thing" to do.

So, you given this conclusion 3 times (that it's not in the best long 
term interest, that it's flawed, and that it's not the smart thing to 
do).  Would you care to elaborate at all on that?

What are the flaws?  How is it not good for the community?

---

From: John Rudd <[email-masked]>
Date: Sun, 9 May 2004 20:08:41 -0700

[snip]

[snip]

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 10 May 2004 01:02:21 -0700 (PDT)

John:

There is actually a list for discussion of this topic,
[email-masked], though it hasn't seen much traffic for quite a
while.

Your note is a reminder that this issue, while much-debated on the various
apps-protocol lists a few years ago when the decisions to invent and
promote STARTTLS were made, is not well-described (so far as I know) in
any RFC.  An informational (or maybe BCP) RFC presenting the reasons why
the separate-port approach is a poor choice, and promoting some good
practices for clients and servers using STARTTLS, would be a good thing
(he said, not quite volunteering).

In a nutshell, the reason STARTTLS is a better approach is that, rather
than treating the use of SSL/TLS as entirely different than other session
characteristics, it permits the use of TLS to be negotiated by client and
server, just as other protocol features are negotiated.  The most
important practical benefit of this is that clients can be designed with
their default behavior to try STARTTLS (perhaps based on a server's
announcing it as a capability), thus giving the generic user the benefits
of TLS-protected connections without having to configure anything.  With
the separate-port approach, the user (in any client I have ever seen) has
to configure the use of the separate port, which in many deployment
scenarios means it doesn't get used at all (since every required obscure
user config step is another $NN of support cost).  (There are lots of
other reasons I won't go into now since I'm up too late already.)

Promoting long-term the use of both STARTTLS and separate ports is also a
bad thing, since having two ways to do the same thing is guaranteed to be
confusing, and security stuff is already confusing enough.
Unfortunately, the separate-port meme has been drilled into people's heads
very effectively by http/https, so it's likely that clients will support
it for a long time to come, but there is no way that this will be anything
other than legacy-compatibility behavior (ie, it won't be specified in
standards RFCs).

Your network administrators are well-meaning, I'm sure, but their policy
is just foolish.  They might reflect on the fact that there are lots of
non-TLS ways to avoid reusable-passwords-in-the-clear with common app
implementations (on the plain old port), including Kerberos, CRAM-MD5,
DIGEST, SRP, and others.  They might reflect on the fact that filtering
out ports just makes people send their traffic over the ports that remain
open, which almost universally includes port 80.  So a "secure ports only"
policy has very little to do with security and very much to do with
organizational power relationships, and making your computing environment
dysfunctional.  Try a "secure servers only" initiative.  It worked much
better for us at my university.

 - RL "Bob"

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 May 2004 09:38:40 -0500

On 5/10/2004 3:02 AM, RL 'Bob' Morgan wrote:

> So a "secure ports only" policy has very little to do with security and
> very much to do with organizational power relationships, and making
> your computing environment dysfunctional.

Somebody check my math on this please, but it seems to me that the whole
STARTTLS approach is succeptible to a specific attack which the secure
socket model is not.

Specifically, a man-in-the-middle can "blank out" the STARTTLS feature
advertisement, and thus make the client believe that TLS is not available.
For example:

      server-A                MitM                  client-C
         |      250-DSN         |     250-DSN
         +-->   250-AUTH        +->   250-AUTH
                250-STARTTLS          250 ok [...pad...]
                250 ok

The client, seeing that TLS is not available, dumbs down to cleartext.
Most clients would probably do that invisibly without even barking at the
user, or not doing so in a way that most of them would appreciate.

Using an encrypted port just means an attack can only produce failure,
rather than inducing fallback.

Unless that's wrong for some reason, I'd say that a "secure ports policy"
actually is more secure.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 10 May 2004 09:38:40 -0500

server-A                MitM                  client-C
         |      250-DSN         |     250-DSN

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 May 2004 08:31:29 -0700

>Unless that's wrong for some reason, I'd say that a "secure ports policy"

In many cases, a client for a "secure ports policy" protocol will 
fall back to the insecure port instead of telling the user "you can't 
communicate". That's not true for HTTPS, but it is true for secure 
POP, secure SMTP, and so on.

A man-in-the-middle can more easily block the secure port than he/she 
can elide the STARTTLS messing in the client's start-up. STARTTLS is 
harder to mount than blocking a "secure port". Thus, the "secure 
ports policy" makes the MITM's job easier.

BTW, sometimes the MITM in the "secure ports only" scenario is a 
clueless firewall admin at any point in the transit. The STARTTLS 
method is not susceptible to this unintentional-but-still-deadly 
downgrade attack.

Any client that is willing to back down to non-secure mode is 
susceptible to a MITM attack, regardless of the protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 10 May 2004 08:31:29 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: John Stracke <[email-masked]>
Date: Mon, 10 May 2004 12:19:39 -0400

John Rudd wrote:

> network level that a client will use SSL/TLS.

Guaranteeing that the client will use TLS is worthless anyway, since TLS 
includes the "None" encryption option.

-- 
/==========================================\
|John Stracke      [email-masked]   |
|Principal Engineer|http://www.centive.com |
|Centive           |My opinions are my own.|
|==========================================|
|Guide us, oh holy Lemming Herder!         |
\==========================================/

---

From: John Stracke <[email-masked]>
Date: Mon, 10 May 2004 12:19:39 -0400

---

From: Anthony DeRobertis <[email-masked]>
Date: Mon, 10 May 2004 14:20:02 -0400

> rather than inducing fallback.

Clients generally default to using the unencrypted port.

Clients generally default to accepting non-STARTTLS connections.

Both require configuration changes to be fully secure. At least with 
starttls you are secure against a passive attacker (because clients use 
starttls if they can).

---

From: Anthony DeRobertis <[email-masked]>
Date: Mon, 10 May 2004 14:20:02 -0400

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 May 2004 02:18:31 -0500

>> Using an encrypted port just means an attack can only produce 
>> failure, rather than inducing fallback.
>> 
>> Unless that's wrong for some reason, I'd say that a "secure ports 
>> policy" actually is more secure.
> 
> In many cases, a client for a "secure ports policy" protocol will fall 
> back to the insecure port instead of telling the user "you can't 
> communicate". That's not true for HTTPS, but it is true for secure POP,
>  secure SMTP, and so on.

This is a fair enough point, and I should have accounted for it, but I
don't think its absence weakens the merits of the first point any.

I'm not even sure they are similar arguments. I mean, the argument against
SSL is that *if* an SSL connection is blocked, and *if* an alternative
clear channel exists, and *if* that channel accepts clear-text logins, and
*if* the client fallsback through all of that, then the session will be
exposed. I'll grant that it's easy enough to interfere with somebody
establishing a session, and that there's a measurable percentage of
services that maintain clear channel alternatives, and that PLAIN/LOGIN
are still the only things that work everywhere, and that there are
probably clients which fallback invisibly. I can also argue some of those
points to some degree -- that people who have setup SSL versions are
likely to have eliminated access to the clear channel, for example -- so
instead of any of those things being certainties, we should agree that
this is a question of overlapping probabilities.

On the other hand, STARTTLS *requires* a clear channel that the client
MUST *already* be using. So whereas the attack on SSL *might* succeed in
putting the client in touch with an unencrypted service, TLS is
*guaranteed* to be using such a service already anyway. The only question
is whether or not a decipherable login can be used, which is a probability
mask that also applies to the SSL scenario.

Given the collection of probabilities, therefore, starting with an SSL
channel and refusing connections to a backup clear channel eliminates most
of the probability from the MitM attack model. Conversely, those
attributes are prerequisites to the very existence of TLS. Ergo, TLS is
weaker against this particular vector, by design.

I don't think it really matters given the other problems (see below).

> can elide the STARTTLS messing in the client's start-up.

That's true.

On the other hand, channeling clients through a proxy is easy, especially
if they are on a foreign network. The client can be tricked into using a
different host via DNS attacks, or can simply be routed through proxies,
NATs, firewalls, or any number of 'transparent' proxies that can be easily
deployed. STARTTLS can be disabled by any of these, using a two-bit attack
(literally: borrow one bit from the T and hand it to the S, causing the
service to be advertised as "TSARTTLS" -- I've seen worse than that from
unintentional bugs and intentional features alike).

> susceptible to a MITM attack, regardless of the protocol.

agreed on that

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 11 May 2004 02:18:31 -0500

That's true.

agreed on that

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 11 May 2004 07:53:16 -0700

>this is a question of overlapping probabilities.

Not only can you argue that, it is the default setting for most 
SSL-using applications today (other than web browsers). As we were 
discussing this years ago, most application developers thought that 
this arrangement is exactly what the users wanted.

>mask that also applies to the SSL scenario.

Exactly right. This is the strongest argument in favor of protected 
ports over STARTTLS.

>of the probability from the MitM attack model.

Right. And this is rejected by most people as unreasonable for the 
application users, unfortunately. What we are battling here is not 
how to do the protocols securely, but how to get the users to use the 
applications securely. If they say "if I can't get a secure 
connection I still want to communicate", all our lovely design is 
lost.

>I don't think it really matters given the other problems (see below).

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Tue, 11 May 2004 07:53:16 -0700

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Mon, 10 May 2004 08:20:44 -0700 (PDT)

> STARTTLS approach is succeptible to a specific attack which the secure

Your "math" is incorrect in that both STARTTLS and the separate port approach
are vulnerable to this attack. In the separate port case an attacker has only
to block the separate port completely, forcing a fallback to the regular port.
(Not providing fallback in such cases is rarely a viable option.) It is also
possible to interfere with the TLS negotiation itself, causing negotiation of
unacceptably weak security.

All of these attacks can be twarted by requiring (on either the client or
server or both) a certain level of security. We've been providing the necessary
knobs to enforce this for quite a few years now; I'm fairly sure other vendors
have similar knobs.

> Unless that's wrong for some reason, I'd say that a "secure ports policy"

It isn't. See above.

				Ned

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 10 May 2004 08:50:08 -0700 (PDT)

> STARTTLS approach is succeptible to a specific attack which the secure

A man-in-the-middle can just as easily (more easily, in fact, since it
doesn't require datastream modification) send back a port-unreachable to
the client's attempt to contact the foo-over-ssl port.  It is true, as you
imply, that if either the client or the server has a SSL/TLS-required
policy, then a non-SSL/TLS connection won't get made.  This policy can be
configured into endpoints using STARTTLS if that's desired.  If clients
and servers both permit the use of cleartext reusable passwords to be
negotiated, then a MITM will be able to force them into it in either case.

At a theoretical level there isn't much difference between the two
security-wise.  Arguments about which is better in practice depend on
assumptions about what implementors and deployers and users might or might
not do.  The underlying reason why the separate-port approach loses,
though, is that it makes simplistic assumptions about the relationships
between services on different ports.  Do imap://example.com/ and
imaps://example.com/ provide access to the same resource?  There's no
reason to believe that they do in the general case.  The separate-port
approach wires-in assumptions about "what's on a port" that are easily
circumvented later, both by bad guys and good guys (as we tend toward a
world where everything runs over port 80).

 - RL "Bob"

---

From: [email-masked]
Date: Tue, 11 May 2004 09:37:34 -0700 (PDT)

> Exactly right. This is the strongest argument in favor of protected

Another argument in favor of separate ports is an implementation issue: It is
fairly common in large scale deployments to have specialized hardware to
perform SSL/TLS stuff, and that hardware often is not resident on the same
machines that offer POP/SMTP/IMAP services. This means that proxy that delves a
bit into the underlying protocol is needed to do STARTTLS. Unfortunately
proxies are in practice responsible for far more bugs you'd expect and the
proxy has to dig into the protocol the worse things get. Separate ports, on the
other hand, are much easier to implement on a front end.

The counter argument to this is the separation of the SSL/TLS layer from the
protocol layer is actually a bad thing security-wise. More specifically, when
it is done as a separate layer information about the SSL/TLS negotiation tends
to remain at that layer. Not making this information available to the
application protocol makes implementation of some security schemes, including
but not limited to SASL external, problematic.

So, while STARTTLS is in some senses more complex, it is useful complexity.

IMO this counterargument is fairly compelling. Add in the other issues that
come up with separate ports (RL Bob" Morgan has already summarized them nicely
so I see no reason to repeat them here) leads me to conclude that STARTTLS is
the way to go.

				Ned

---

From: [email-masked]
Date: Mon, 10 May 2004 08:20:44 -0700 (PDT)

It isn't. See above.

				Ned

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 10 May 2004 08:50:08 -0700 (PDT)

- RL "Bob"

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 18 May 2004 15:20:00 -0600

Configure your client so it *requires* start-tls, and it will error out 
if this attack is attempted.  The same attack is possible against SASL, 
if you remove DIGEST-MD5 and add PLAIN.  The defense is to configure 
your client to only allow non-plaintext SASL mechanisms.

-- 
Joe Hildebrand
Denver, CO, USA