Subject: [yam] draft-daboo-srv-email: POP3S/IMAPS?

From: Sabahattin Gucukoglu <[email-masked]>
Date: Sun, 17 Jan 2010 04:10:51 +0000

Hi all,

Just had a look at draft-daboo-srv-email, all very pleasant.  I think service weights have been discussed already but:

Why does the spec provision for IMAPS and POP3S?  Shouldn't we be seriously discouraging that usage?  Is there some reason to keep them, even if "deprecated"/discouraged?  Right now the only reason I know of is IMAP clients which send out LOGIN complete with password before they can be stopped; for that we have the LOGINDISABLED capability.

Cheers,
Sabahattin

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 17 Jan 2010 16:55:54 +0100

Sabahattin Gucukoglu writes:
> Why does the spec provision for IMAPS and POP3S? Shouldn't we be 
> seriously discouraging that usage?

I'd like draft-daboo-srv-email to be the smallest reasonable change 
necessary in order to add srv autoconfiguration in clients.

Trying to accomplish two things is one too much.

Feel free to suggest wording for an informational section discouraging 
imaps/pop3s/smtps.

Arnt

---

From: Ned Freed <[email-masked]>
Date: Sun, 17 Jan 2010 09:35:47 -0800 (PST)

> Why does the spec provision for IMAPS and POP3S?

Because a provisioning mechanism that fails to deal with the needs ot
real-world deployments - and there's plenty of this secure port stuff deployed
out there - makes itself far less likely to deploy.

> Shouldn't we be seriously discouraging that usage?

Perhaps. But a provisioning mechanism specification isn't the place to do it.

If you want to promote or discourage a particular approach to deploying network
services, you need to do it directly. Write a "IMAPS/POPS considered harmful"
draft and get it published.

We have buckets full of past experience informing us that trying to shift
existing deployments away from approaches we don't like through registration
policy resrictions not only doesn't work, it often backfires and causes far
more harm than good.

> Is there some reason to keep them, even if "deprecated"/discouraged?

Yes. See above.

> Right now the only reason I know of is IMAP clients which send out LOGIN
> complete with password before they can be stopped; for that we have the
> LOGINDISABLED capability.

The abscence of a technical justification doesn't mean no other sort of
justification exists.

				Ned

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 17 Jan 2010 15:34:20 -0700 (MST)

> Feel free to suggest wording for an informational section discouraging 

I would argue that since neither of imaps and pops are internet standards, 
normative text about them is out of scope for a standards track document, 
therefore all references to them should be deleted.

--lyndon

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Mon, 18 Jan 2010 02:42:09 +0000

> Perhaps. But a provisioning mechanism specification isn't the place to do it.
The specification, if it describes the method of "Wrapped SSL", must explain what's wrong with it, and we know too well what's wrong with it (implementation specific behaviours, IANA problems, negotiation problems, although the latter is addressed in part by this very specification).  If it doesn't describe a specification that the IETF wrote or vouches for, then that specification needs to be written.  Otherwise, it shouldn't specify its usage at all.

Happily, this specification *does* explain the procedure for wrapping POP/IMAP/SMTP inside a directly-negotiated SSL stream, so all that's required now is to explain why, in all this time, we haven't documented it before now.  Perhaps we can even kill two birds with one stone. :-)

> draft and get it published.
See above; I have no problem with propitiating those who choose to do it wrong, but only so long as they don't do it very wrong, and hurt lots of innocent bystanders who obey well-written rules as a consequence of their own desires.  The deployment or not of broken vs correct behaviour will speak for itself, and I have no problem with that.  But neither should we simply allow for the specification of broken behaviour without a cautionary note.

Cheers,
Sabahattin

---

From: Ned Freed <[email-masked]>
Date: Sun, 17 Jan 2010 18:55:16 -0800 (PST)

> The specification, if it describes the method of "Wrapped SSL",

If by "description" you mean a single sentence, I guess this specification
qualifies. But by that measure, RFC 2595 would probably qualify as well.

> must explain what's wrong with it, and we know too well what's wrong with it
> (implementation specific behaviours, IANA problems, negotiation problems,
> although the latter is addressed in part by this very specification).  If it
> doesn't describe a specification that the IETF wrote or vouches for, then that
> specification needs to be written.  Otherwise, it shouldn't specify its usage
> at all.

The consequences of that will be to make the mechanism unusable for a
nonnegligable number of deployments. Deployment of this is going to be
difficult enough without such well-meaning but strategically foolish
exclusions.

> Happily, this specification *does* explain the procedure for wrapping
> POP/IMAP/SMTP inside a directly-negotiated SSL stream, so all that's required
> now is to explain why, in all this time, we haven't documented it before now. 
> Perhaps we can even kill two birds with one stone. :-)

But we have documented this at this level of detail before now - in RFC 2595
section 7.

Now, I have no objection to adding a sentence to the security considerations
section saying that use of imaps/pops are discouraged and pointing to the
previous text on this issue. But I see little if any value in repeating the
explanation here. And I'll again repeat that if your goal really is to change
existing deployment practices, the only chance you have of doing that is with a
separate document specifically on this point and this point alone.

> See above; I have no problem with propitiating those who choose to do it
> wrong, but only so long as they don't do it very wrong, and hurt lots of
> innocent bystanders who obey well-written rules as a consequence of their own
> desires.  The deployment or not of broken vs correct behaviour will speak for
> itself, and I have no problem with that.  But neither should we simply allow
> for the specification of broken behaviour without a cautionary note.

The relevant cautionary note has been part of our specifications for other 10
years now.

				Ned

---

From: Julien ÉLIE <[email-masked]>
Date: Mon, 18 Jan 2010 08:17:59 +0100

Hi Ned,

> separate document specifically on this point and this point alone.

For what it's worth, RFC 4642 for the STARTTLS command with NNTP
mentions in its introduction:

   In some existing implementations, TCP port 563 has been dedicated to
   NNTP over TLS.  These implementations begin the TLS negotiation
   immediately upon connection and then continue with the initial steps
   of an NNTP session.  This use of TLS on a separate port is
   discouraged for the reasons documented in Section 7 of "Using TLS
   with IMAP, POP3 and ACAP" [TLS-IMAPPOP].

   This specification formalizes the STARTTLS command already in
   occasional use by the installed base.  The STARTTLS command rectifies
   a number of the problems with using a separate port for a "secure"
   protocol variant; it is the preferred way of using TLS with NNTP.

   [TLS-IMAPPOP] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
                 2595, June 1999.

Same problem.  That behaviour was never documented, but unfortunately
is what is currently usually implemented :-/

-- 
Julien ÉLIE

« The most effective way to remember your wife's birthday
  is to forget it once... » (Nash)

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Jan 2010 10:40:48 +0100

Lyndon Nerenberg writes:
>> Feel free to suggest wording for an informational section 
>> discouraging imaps/pop3s/smtps.
>
> I would argue that since neither of imaps and pops are internet 
> standards, normative text about them is out of scope for a standards 
> track document, therefore all references to them should be deleted.

Standards-track document talk about such things quite often. As long as 
it's informational, anything goes.

I grepped for (informational) references to experimental RFCs in RFCs 
5000-present, and found several hundred.

993 is a nuisance, but it's real enough.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Jan 2010 12:22:50 +0100

Ned Freed writes:
> The abscence of a technical justification doesn't mean no other sort 
> of justification exists.

I asked three admins about that in 2007, all said "we want all access to 
be encrypted and imaps/pop3s/smtps is the practical way to get that". 
Statistics isn't my field, three identical answers was enough for me, 
and I concluded that SSL wrapping will remain in use until mail servers 
offer configuration settings to allow/prevent plaintext access to mail.

Arnt

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2010 13:12:45 +0000

> out there - makes itself far less likely to deploy.

In that case shouldn't it also document smtps?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Jan 2010 14:26:36 +0100

Timo Sirainen writes:
> Such setting doesn't help.

Such a setting is cecessary, not sufficient.

> Dovecot has had one since the beginning and people still configure it 
> to give only imaps/pop3s access. I think there are two big reasons 
> for this:
>
> 1) Clients are stupid and issue plaintext LOGIN command even if 
> LOGINDISABLED is advertised. So with such clients it's easy to 
> accidentally expose username and password.

Good point.

> 2) It's easier to enforce "SSL-only" traffic in firewall rules based 
> on ports. For example they'll keep both imap and imaps enabled, but 
> only imaps is allowed outside intranet.

Yeah. But I can't remember talking to anyone who really cared about 
allowing cleartext imap inside the firewall.

> (And yeah, then there's probably the biggest reason that people just 
> don't understand that imap/pop3 port supports SSL/TLS.)

Which I think would change if servers generally would support
      encrypted-only = true
As it is, people aren't used to looking for such a setting, and if they 
call their clueful pal to ask how blah, he'll say "enable imaps", not 
"enable encrypted-only".

Arnt

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2010 13:48:42 +0000

On Mon, 18 Jan 2010, Arnt Gulbrandsen wrote:

> Timo Sirainen writes:
>
> > 2) It's easier to enforce "SSL-only" traffic in firewall rules based on
> > ports. For example they'll keep both imap and imaps enabled, but only imaps
> > is allowed outside intranet.
>
> Yeah. But I can't remember talking to anyone who really cared about allowing
> cleartext imap inside the firewall.

I'm not sure exactly what you mean here, but I have counter examples for
two possible interpretations.

If you mean that no one in your experience is worried by unencrypted
access from local IP addresses, then we certainly are especially for
wireless users.

If you mean that no one in your experience enables unencrypted access from
local IP addresses, then I believe it's fairly common for universities to
do so to avoid having to reconfigure thousands of desktop clients. It
took us about a year to completely disable unencrypted access - we wanted
to avoid huge spikes in support load.

With the right software it's fairly easy to restrict unencrypted logins to
local wired networks.

Tony.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Jan 2010 15:11:06 +0100

Tony Finch writes:
> I'm not sure exactly what you mean here, but I have counter examples 
> for two possible interpretations.

I meant that I can't remember speaking to anyone who REALLY WANTED to 
allow unencrypted IMAP inside the firewall. Sorry about the lack of 
clarity.

> access from local IP addresses, then we certainly are especially for 

Yes. I have also heard mutterings about ethernet jacks and ARP attacks, 
although that may be more paranoia than realism.

> If you mean that no one in your experience enables unencrypted access 
> from local IP addresses,

(On the contrary, people do, and I think it makes sense. A low-value 
feature is worth using if it's also low-cost, right?)

> then I believe it's fairly common for universities to do so to avoid 
> having to reconfigure thousands of desktop clients. It took us about 
> a year to completely disable unencrypted access - we wanted to avoid 
> huge spikes in support load.

Yes.

> With the right software it's fairly easy to restrict unencrypted 
> logins to local wired networks.

Timo's mail made me think of a different approach: Immediately expire a 
password if a server receives that password in clear text. Bang bang. 
(Let me guess: The words "support spike" entered your mind now.)

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Mon, 18 Jan 2010 15:14:10 +0200

On 18.1.2010, at 13.22, Arnt Gulbrandsen wrote:

> Ned Freed writes:
>> The abscence of a technical justification doesn't mean no other sort of justification exists.
> 
> I asked three admins about that in 2007, all said "we want all access to be encrypted and imaps/pop3s/smtps is the practical way to get that". Statistics isn't my field, three identical answers was enough for me, and I concluded that SSL wrapping will remain in use until mail servers offer configuration settings to allow/prevent plaintext access to mail.

Such setting doesn't help. Dovecot has had one since the beginning and people still configure it to give only imaps/pop3s access. I think there are two big reasons for this:

1) Clients are stupid and issue plaintext LOGIN command even if LOGINDISABLED is advertised. So with such clients it's easy to accidentally expose username and password.

2) It's easier to enforce "SSL-only" traffic in firewall rules based on ports. For example they'll keep both imap and imaps enabled, but only imaps is allowed outside intranet.

(And yeah, then there's probably the biggest reason that people just don't understand that imap/pop3 port supports SSL/TLS.)

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2010 15:04:00 +0000

On Mon, 18 Jan 2010, Arnt Gulbrandsen wrote:
> password if a server receives that password in clear text. Bang bang. (Let me
> guess: The words "support spike" entered your mind now.)

:-)

One advantage of POP's separate USER and PASS commands relative to IMAP's
unified LOGIN command or SASL PLAIN is that the server can reject the USER
command on unencrypted connections and with any luck the client will give
up without blurting out the password. At least in theory :-)

In practice I'm not too worried about idiot client software revealing
passwords because it'll only happen during the user's first attempts at
configuration, so the exposure is pretty small. I might revise that
opinion if a college decides to go all-wireless for network access in
student bedrooms, and if against all past experience students start using
MUAs en masse instead of webmail...

Tony.

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 Jan 2010 08:53:48 -0800 (PST)

> In that case shouldn't it also document smtps?

Is smtps as widely deployed as pops or imaps? If it is then yes, it should be
in there. But if it isn't - and my experience has been that it isn't - then
there's no need.

This all goes back to when the various different protocols added and deployed
extension mechanisms as compared with when SSL/TLS support was added and
deployed. The SMTP extension mechansim came first in terms of definition and
deployment, so that when SSL/TLS came along the path of least resistance was to
use STARTTLS inside the protocol. POP3 extensibility came much later, so pops
was the past of least resistance there. And IMAP is somewhere in the middle.
(I actually don't know if in terms of deployment imaps is worth having in
there, but pops sure is.)

				Ned

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2010 17:17:02 +0000

> in there. But if it isn't - and my experience has been that it isn't - then

Any sites that want to support secure message submission for versions of
Outlook older than the 2007 have to support smtps. Older Outlook will only
do SMTP+STARTTLS on port 25, and will only do smtps on other ports.
Outlook Express / Windows Live Mail / etc. has the same problem though I
don't know which version fixed it.

Tony.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 18 Jan 2010 18:17:16 +0100

Ned Freed writes:
> Is smtps as widely deployed as pops or imaps? If it is then yes, it 
> should be in there. But if it isn't - and my experience has been that 
> it isn't - then there's no need.

Outlook likes to use smtps. To me that's wide enough deployment. (Or was 
it OE? Doesn't matter, both are widely used.)

Arnt

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 Jan 2010 09:44:27 -0800 (PST)

> allowing cleartext imap inside the firewall.

Sites are all over the map on this. Some have no problem with cleartext
everything inside the firewall while others have mandates that require
a security layer on literally every protocol and every connection.

Then there's the whole wireless thing - sites often have very different
policies for wired versus wireless and all sorts of different arrangements are
used.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 18 Jan 2010 10:48:20 -0800 (PST)

> don't know which version fixed it.

If the only way to get a security layer in some relatively recent version of
Lookout was through smtps, that would be a very clear reason to include
smtps. But that's not what's happening.

The tradeoff here is much more subtle - it's question of which is more
problematic, requiring submission stay on port 25 where it's conflated with
relay operations, or accepting the use of smtps to get it to move someewhere
else.

My personal opinion is that smtps is somewhat more problematic, but I freelly
admit that's colored by the flexibility of our products in this area and the
seeming willingness of our customers to deal with this sort of configuration
complexity. I could easily see someone else making the call differently.

But again, this is more about what people actually do than it is about
theoretical tradeoffs. So do others think there's sufficient deployment of
smtps to warrant it's inclusion?

				Ned

---

From: Tony Finch <[email-masked]>
Date: Mon, 18 Jan 2010 19:16:54 +0000

> relay operations, or accepting the use of smtps to get it to move someewhere

You also have to consider port 25 blocks. Roaming users in particular need
to avoid configuring their MUA to use port 25. Hence RFC 5068.

Tony.